The BSOD: Finding and Fixing its Causes

If you own a computer, it’s probably happened to you before. You’re in the middle of an important document or intense online game, when you get the dreaded “blue screen of death” or BSOD. These crashes don’t tell you why they happen; all you get is an error message followed by a string of seemingly random letters or numbers, and a rebooted PC—meaning that you just lost everything you were working on.

Blue screen errors are usually caused by a glitchy driver, but even systems with good error tracking systems will seldom tell you which one’s the problem. You don’t have to deal with a ticking time bomb of a PC; when blue-screen crashes happen, you can use Windows Debugging Tools to pinpoint the problem driver (and hopefully the cause of your problem). Here’s how to do it:

Using Windows Debugging Tools to Identify BSOD Problems

1. Download Windows Debugging Tools from Microsoft; it works on everything from that old relic of a Windows NT4 right on up to a current OS. Windows 7’s beta debugging tool isn’t nearly as reliable, though.

2. Configure your Windows installation to save memory when the blue screen error happens, so the debugger can access it. Right-click on ‘Computer’, select ‘Properties’ from the drop-down menu, click ‘Advanced’>Startup & Recovery, and check that the box marked “Write debugging” information has the “complete memory dump” or “kernel memory dump” option checked.

3. Now, click on Start, All Programs, Debugging, WinDbg, and click ‘File’ then ‘Symbol File Path’. The debugger will have to download data in the form of ‘symbols’ from MS in order to decipher the crash file; type SRV*c:symbols*http://msdl.microsoft.com/download/symbols to get the most current list. When you’re done, click ‘OK’ and then exit, clicking ‘yes’ if asked to do so. That’s it! You’re ready to figure out why you’re getting the blue screen of death message.

How to Fix BSOD Problem

The next time you get a blue death screen and your PC reboots, launch WinDbg (if you’re running Windows Vista, you’ll have to right-click and run the program as an administrator). Click ‘File’, then open the crash dump, usually located at c:Windows/MEMORY.DMP. Windows Debugger will analyze the crash file; it may take a while, so you’ll need to be patient. You’ll end up with a line at the bottom of the analysis page saying “likely caused by: filename.sys:. Google the filename and find out where it’s located. If WinDbg has pinpointed the cause as being something you installed, try uninstalling or updating drivers to see if the problem is resolved.

In rare cases, Windows Debugging Tools can’t find the offending file, or it chooses a core .dll file. If it happens to you, click the command window right above your status bar and type in: !analyze –v for a more detailed report. If even that doesn’t work, don’t feel as if you’ve failed—debugging is hard, even for those who’ve been doing it for years. Just close the debugger and wait for the next crash; you could get a more accurate result.

Erin Walsh is an avid blogger for common pc issues like how to speed up a slow computer or how to fix your registry. You’ll find her blogging most often at PC HealthBoost where she likes to help people solve common PC issues that people can fix themselves without having to spend a lot of money. She feels that most issues are a lot less scary than they initially seem once you get past all of the computer jargon and speak to people in terms that they can understand. She also likes to write about green technology in her spare time.