How to handle and interpret BSODs on Windows

How to handle and interpret BSODs on Windows.

Today I read a post
by Susan in which she makes some good recommendations on how to get a
dump when a system crashes. I found a few of her points could be
expanded upon and slightly modified, and started to comment on her
blog. Then I realized it might be useful to others in the community,
and decided to post it here.

There are a couple of things to consider when dealing with a kernel crash dump. You should read Susan's article first in order to understand her recommendations on setting up kernel dumps on Windows.

1. Turn OFF the “Automatically restart” checkbox.
   When the system BSODs you will then be able to SEE the crashdump on
   screen. This is important as you can typically SEE the offending driver
   that is causing the fault. More importantly is that it allows you to
   see the TYPE of fault. If you don't do this, the system will
   automatically restart and you will miss this vital information. NOTE:
   If this is a headless server hosted somewhere, you may not wish to do
   this… your system will not reboot until told to.. which means it will
   hang forever.
2. Turn OFF the “Overwrite an existing file” checkbox.
   Otherwise, if you have multiple faults you will never know about them
   since you would overwrite the previous crash dump. In some cases where
   “Paged Pool” is corrupted due to an offending driver, you may trigger a
   secondary fault that is harder to track down if you try to rectify it
   before it can be pushed to OCA. If you overwrite the file, you will be
   out of luck in comparing the dumps.
3. In a pinch a minidump is fine. 9 times out of 10 having the
   complete dump of memory is useless unless the debug team require to
   debug virtual memory issues (like BAD_PAGED_POOL_HEADER faults). A
   little known fact is that the data Microsoft fires off to OCA is
   actually a bastardization of the minidump, which is then sent to code
   on the OCA server which goes through a filtering algorithm to determine
   the true cause of the failure, and is then placed into the buckets for
   each vendor. If they need more information (like the full dump) you get
   routed to a special web page, and are then asked to upload it.

If you want to get geeky and LOOK at the fault (in case you skipped
point one and the system rebooted), it is possible. To do this you will
need to download Microsoft's kernel debugger called WinDbg. Then take the following steps:

1. Start WinDbg
2. Create a directory in the root of C: and call it “symbols” (mkdir c:\symbols)
3. Click on File, Symbol File Path. Here you will enter
   the symbols path, which is needed to effectively read debug
   information. Since Microsoft makes its public symbol server available
   to us, lets use it.

   The path will be: SRV*c:\symbols*http://msdl.microsoft.com/download/symbols

4. Once you apply the symbol path, select the “Reload” checkbox and then hit Ok.
5. Now go File, Open Crash Dump and load the file you wish to view. The minidump will typically be located in %systemroot%\minidump (in my case C:\windows\minidump).
6. When you hit Ok, the debugger will contact the symbol server,
   sync the data and load the debug screen with the data that it can read.
7. Now at the cmd prompt type !analyze -v

You
now have a full debug of what has faulted, with all the information you
need. At this point you can check information on the stack, look at the
last instructions before fault and do all the magic a kernel guy does.
Chances are, most of the information will be foreign to you. Don't
fret. That's what people like me are for. Just look for something that
says:

Probably caused by : foodriver.sys  ( foodriver+4f20 )

Chances are, THAT is your offending driver (and the offset is the
location, so if you let the vendor know they will know right down to
the line number).

What do you do now? Well remove it. If the driver loads on demand,
not a problem, you can simply remove the offending software. But what
if the driver loads at boot time? You will never be able to do that,
since the system will constantly crash on startup!

That is why the “Recovery Console” exists. Stick in your W2K3 or XP
CD and boot from it. When asked, hit “R” for Recovery Console. When
prompted type in your Adminstrator's password. Once logged into the
console type net stop . This will set the driver to NOT load on boot. You should then be able to boot up, and remove the offending driver.

Susan, tell your friend there is no need to reformat and
reinstall. Just use the tools available to you to remove the offending
driver!  [Dana Epp's ramblings at the Sanctuary]