James Bannan20 November 2007, 11:55 AM
The Windows Blue Screen of Death is hated and maligned, but it's really just trying to help. Read on to find out what it's trying to tell you.
The Windows Blue Screen of Death is hated and maligned, but it's really just trying to help. Read on to find out what it's trying to tell you.
Dan Warne recently had a cheeky dig at what some consider to be the quintessential interactive Windows screen – the blue screen of death, or BSOD.
Certainly, the unfriendly, “it’s all over for you” vibe which every BSOD gives off has given Windows system faults a bad reputation over time. Personally, I rather like these haiku error messages:
Windows NT crashed.
I am the Blue Screen of Death.
No one hears your screams.
Chaos reigns within.
Reflect, repent, and reboot.
Order shall return.
A file that big?
It might be very useful.
But now it is gone.
However, joking aside, I learnt recently that BSODs aren’t all that bad, and can actually be very helpful.
When Windows bluescreens, it has encountered some sort of fault or incompatibility which is severe enough to cause an immediate system stop.
The blue screen itself is a memory dump – the system dumps the contents of running memory to a dump file to facilitate debugging, and then the system restarts.
To most people, a bluescreen means it’s time to rebuild the system, but there are times when you really don’t want to do that.
I recently built a system for running virtual test systems – an ASUS P5KR-based system with 4GB RAM, which bluescreened whenever Vista Ultimate x64 tried to boot -- even in Safe Mode and even off the Vista DVD.
However with 2GB RAM it worked perfectly. So there was obviously some sort of memory configuration issue, but there wasn’t enough information to perform a proper search.
What I didn’t know is that when Windows bluescreens, it often writes the memory dump to a smaller file, called a minidump. This is true of all versions of Windows from 2000 to Vista/Server 2008. The minidumps are incredibly useful because they’re small and easy to navigate, and give you much richer information with which to troubleshoot the problem.
To open a minidump file, you need the following tools:
The Debugging Tools for Windows is the framework which lets you open and navigate dump files. Download the version which is relevant to the platform you’re installing it on, rather than the platform you’re going to troubleshoot (ie: if you want to open a dump file from Vista x64 on a Vista x86 machine, download the 32-bit tools).
The symbol packages contain information necessary for the debugger to resolve data like local variables, structure type information and source file info specific to the package you’re trying to debug.
Windows XP, 2003 and Vista don’t require symbol packages if you’re debugging the local system. Otherwise, you’ll need the package file of the system platform you’re debugging.
The packages are quite big, and install to C:\Windows\Symbols. To set the symbol path parameter, install the Debugging Tools and go Start, Programs, Debugging Tools for Windows and launch WinDbg. Then go Files, Symbol File Path (or CTRL+S) and browse for the folder.
Alternatively, if the debugging machine has access to the internet, in the Symbol Path window type in the following:
SRV*c:\windows\symbols*http://msdl.microsoft.com/download/symbols
 Grab the latest symbols automatically |
This points WinDbg to the Microsoft site and it will download any symbols it needs to open any particular minidump file. This does slow the process down, but it’s certainly more convenient than download hundreds of megabytes of symbol packages.
If you’re debugging any other OS than Vista or Server 2008, you’ll also need to point WinDbg to the source files. This is just the i386 folder on the Windows install CD (Vista and Server 2008 don’t use the i386 structure). Go to File, Source File Path (or CTRL+P) and browse to the source files.
Then go File, Open Crash Dump (or CTRL+D) and browse to C:\Windows\Minidump and open the most appropriate DMP file. They’re created by date, so it should be easy to locate the relevant file.
The dump file opens up and loads once the symbols have been accessed (or downloaded – this can take a few minutes). Once you see the lines “Loading Kernel Symbols” and “Loading User Symbols” then “Bugcheck Analysis”, you’re ready to go.
There’s a command line at the bottom of the debug window where you can enter in debug commands. If you’re not sure that the dump file as been loaded properly, type in the following command to reload it:
.reload (don’t forget the full stop)
Once the file is fully loaded, type in:
!analyze –v
The command line should then have *BUSY* next to it while the debugger does a detailed analysis of the minidump. The file’s contents are then rendered in the debug window. The analysis automatically scrolls to the bottom, so scroll back up again. The bugcheck gives some pretty detailed information about what happened and where the fault lies.
 Find out precisely why your system's unhappy |
Scroll back down to the bottom of the bugcheck and look for the following two lines – MODULE_NAME and IMAGE_NAME. These lines tell you precisely which software module caused the fault. The MODULE_NAME value is actually a hyperlink – click on the link and it will give you more detailed information about that particular module.
 Faulting module found and locked on |
Once you’ve got that information, use it to do a relevant Google search. System faults are very well documented online, but the trick is using the right information. BSODs on their own don’t give you that much, and without knowing what caused the bluescreen in the first place, any search is based largely on guesswork and speculation. It’s worthwhile checking out the minidump and get your answers quickly.
In my case, it was memory misconfiguration in the BIOS. I could possibly have stumbled across the answer eventually, but the minidump took me to the right online forums in minutes.
If the Windows fault is particularly severe, the system may perform a full memory dump, and depending on the amount of RAM you have, this dumpfile can be huge. However you can still use WinDbg to track down the faulting module. The debug window is searchable like a text file, so just go Edit, Find (or CTRL+F) and search for the MODULE_NAME and IMAGE_NAME strings and you’re away.