Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Windows has an advanced function built-in that lets a user manually initiate a BSOD. It is a debugging tool used to halt the system in the event of (though not necessarily limited to) a hang or freeze.

When used, it causes a BSOD with the string MANUALLY_INITIATED_CRASH1 and whimsical code 0xDEADDEAD.

The point to this crash is that it is purposely done by the user, so it is not (or at least should not) be an unpredictable event caused by hardware errors or bad drivers (at least not necessarily bad drivers).

The question then is whether performing a manual crash properly flushes the disk caches and such so that the drive is in a valid state when rebooting and thus forgoing the need to have chkdsk run.

share|improve this question
A bugcheck is a bugcheck; the system stops dead, no flushing caches. It wouldn't be sensible, IMO, for MS to treat this one bugcheck as a special case, and I suspect it would be architecturally difficult to do so anyway. (What if the bugcheck is triggered early in the boot process, or during shutdown, and the disk caching system isn't actually in working order?) – Harry Johnston Dec 17 '12 at 20:02
up vote 2 down vote accepted

Not having access to the Windows sources, I cannot give a definitive, technical answer, however I can report my test results.

After performing a manual crash a few times, under different circumstances (at least as different as I can create), I have found that a manual BSOD seems to behave much like a regular BSOD. That is, it usually causes chkdsk to run on the next boot (though perhaps not surprisingly, I have yet to see any actual errors found during the scan), however occasionally, it does not (just like how some real BSODs occasionally do not cause chkdsk to run).

It looks like whether or not chkdsk runs is dependent on the disk usage prior to the crash regardless of the cause of the BSOD and that a manual one is not special in any way.

(It is odd since it could easily have been designed to at least attempt a quick flush first; the worst that could happen is that it fails. Of course it is probably due to due the nature of the underlying architecture and how the function is performed.)

share|improve this answer
I had always figured that this feature was for testing purposes, and in that vein I would expect it to behave exactly as any other BSOD, including leaving the disk cache unflushed. It may not be an inherently unpredictable event, but it's simulating an unpredictable event. – Darth Android Dec 13 '12 at 17:32
So basically the answer to this question is "it depends" super. Its likely it would be entirely based what disk operations were being done when the manual crash was forced. I am sure there are also ways to tell the file system to do maintenance right before the crash is forced. – Ramhound Dec 13 '12 at 17:33
It may not be an inherently unpredictable event, but it's simulating an unpredictable event. But how would you accomplish that? There is no way that they can truly reproduce a crash since there are so many ways it can happen; how do you pick which method? The main purpose of bugcheck is to simulate a freeze, so I don’t see any harm in trying to flush the disk. So basically the answer to this question is "it depends" Like most things in computer-science, yes, more or less. The long answer is that a manual BSOD is essentially the same as a real one with respect to disk state. – Synetech Dec 14 '12 at 17:55

I'd imagine so. NTFS is a journaled file system and if the system is stopped abruptly by a BSOD then pending journal entries will need to be brought up into the main filesystem. A (manual) BSOD during a disk write could also have implications on the structure of the filesystem, so it'd seem prudent to check it.

share|improve this answer
I use FAT32 for almost all of my volumes, so it’s not an NTFS-specific behavior. – Synetech May 22 '13 at 16:31

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .