How to debug a Blue Screen of Death (BSOD)- Part 2 ~ Ask The Admin

Friday, September 21, 2007

How to debug a Blue Screen of Death (BSOD)- Part 2

In Part 1 we've seen what can cause a BSOD and what information we can collect after it happens, so we could investigate the problem.

Well, Microsoft gives us the Debugging Tools for Windows toolkit.

Go to the link, and download the latest version that is appropriate to your system (i.e. x86/64bit).

This toolkit allows us to diagnose the memory dump files that Windows saved during the BSOD and hopefully pinpoint the root cause of the problem.

While debugging the dump files, the tools compare the drivers' and operating files' information from the memory collected in the dump file, to a database of "symbols" from Microsoft. the Symbols database will most likely be used from the internet using Microsoft Symbols server, but can also be downloaded and used offline (it's a huge file- only download if you must...).

Let The Debugging Begin!
  1. At first we run the WinDbg utility from the Debugging Tools for Windows we just installed.
  2. In the File menu - "Open Crash Dump" - Choose you Minidump or Memory.dmp file.
  3. Let the debugger do its work...
Now we should see a long and detailed text file filled with memory addresses, driver names and much more.
what we're interested to find are (you're welcome to use the "Find" function from the Edit menu):
  • BugCheck = equals to the BSOD error code. In case we didn't see the error message and still don't know which error we got.
  • "Probably caused by" = this line is followed by the debugger suggestion of what caused the BSOD that happened while this dump file was created.

Examples from my experience:

"SYMEVENT.SYS" > damn Norton AV... (suggestion: uninstall and replace with NOD32 :))

"nv4_disp.sys" or "nv4_mini.sys" > Nvidia Drivers (suggestion: update drivers)

"memory_corruption" > bad RAM maybe? (suggestion: run Windows Memory Diagnostics)

Please note that sometimes all you need to do is just run Chkdsk (BSOD 0xED or 0x24) or run System Restore to roll-back a healthy registry. But this takes experience or some quality reading-time from the knowledge bases I suggested in Part 1.
But I strongly believe in understanding the problem and not just fixing or bypassing it. That way you can be sure you won't get the same error again the next day..

If you find the WinDbg tool a bit unfriendly, you can also try using the DebugWizard tool from . It will simplify the process by automatically downloading the symbols it needs from the internet, debug the dmp and saving a text-log file for easy reading.

I hope you will find this information useful.