Sunday, July 15, 2012

BSOD - Reading and Using Windows Dump Files

Let's face it, there is nothing more frustrating than being in the middle of a great game and suddenly getting the dreaded Blue Screen of Death (BSOD), unless it's being in the gunners seat of a helicopter in BFBC2 when your pilot suddenly loses his internet connection.

We've all been there, some more than most. Anyone who owns a Windows computer will see a BSOD at least once in their lifetime.  If it happens once and recovers, then it was probably just a system hiccup, but if it KEEPS happening, then something is wrong.

For many of us, the blue screen will appear for 15 - 30 seconds, giving us time to read (and write down) the generated error code, but if the blue screen flashes by too fast to read the error code, how do you know what is going on?

Dump Files (dunna nunna nunna nunna)

 

If you have your system set to record dump files (and it should), when Windows crashes it will write all the necessary error information to the dump file.  This is wonderful if your blue screen flashes before your eyes like someone has just snapped your picture, but unfortunately, this is not a simple .txt file and extracting information from it is going to require jumping through a couple of hoops.

First off, let's verify that your system is set to record dump files.

For now this page will focus on Windows Vista / 7, but I will come back later and update for XP.

If you have Vista or Windows 7:

  • Go to Start > Control Panel > System and Security > System
  • From the right-hand menu options select Advanced System Settings
  • A box will pop up with the advanced tab selected  Under  "Startup and Recovery" select "Settings"
  • Make sure there is a check mark in the box labeled "Write an event to system log" and in the drop-down box below it ensure that it reads "Kernel Memory Dump"
  • Click OK and back out of your control panel.  


Now your ready for your next BSOD.  Unfortunately, if your system was not set up to record memory dumps, you'll have to wait until it crashes again to write a log file, but if it was already set to record memory dumps, then we're still in business.

Windows Debugger (WinDbg)

Your dump files should be located by default (Windows 7) in C:/Windows/minidump/ but to read the files is another matter entirely.  For this you will need something capable of actually reading the dump file.  There are several options, but we are only going to explore WinDbg at this time.

There are two files that you will need here.  Windows debugger and it's associated symbol file.

Start by downloading the Windows debugger. I prefer the stand-alone SDK but that's up to you.
When installing, you will get a checklist of items to install.  They are all checked by default.  This is un-necessary since all you will really be needing for this is the debugger.  Just uncheck everything else.

 Once installed you will need to install the symbol file.  You can download the latest symbol file for your operating system, but instead I prefer to simply provide the debugger with the address to the Microsoft Symbol Server and let it download the most updated symbol file.

To do install the symbols file:
  • Go to File > Symbol File Path (or just press Ctrl + S)
  • If you downloaded a symbol file, enter the path to the symbol file directory here
  • If you want WinDbg to download it for you type in http://msdl.microsoft.com/download/symbols

Now you are ready to open your dump file and find out what is going on with your computer!


Let's read those dump files!

 

To open the dump file you may either choose File > Open Dump File or simply use CTRL + D.
Navigate to your dump file directory (c:\windows\minidump\) and choose the latest dump file (if you chose not to overwrite old dump files).
Once open WinDbg will chew on it a bit then spit out something that looks completely useless.  As you scroll down you will see a blue hyperlink that reads !analyze -v.  Click on this link, and it will analyze your dump file and rather frankly tell you why your system crashed.

My last dump file reads:

DEFAULT_BUCKET_ID: WIN7_DRIVER_FAULT
MODULE_NAME: Pool_Corruption

So there we have it.  We got STOP 0x0019 BAD_POOL_HEADER because a driver malfunctioned.  Granted, this could also have been caused by a hardware issue such as a bad hard drive or bad sector on the HDD, or bad memory, or (since it's a laptop) the memory could have needed to be re-seated, but in this case it was an old program that I didn't use anymore that was causing the problem.  A bit of digital housekeeping, cleaning up the disk and tossing out old un-used programs did the trick.

Hope this helps :)