Diagnose and Fix Blue-Screen Crashes

Troubleshoot PC crashes, lockups and other instabilities with the free Windows Debugging Tools

There’s nothing quite as frustrating. One moment you’re working at your PC, the next your screen turns blue and your system reboots, destroying all unsaved work. Then, an hour or so later, it happens again. What’s going on? To diagnose and fix blue-screen crashes you need to know what is causing them. But don’t expect Windows to help. Head off to ‘Problem Reports and Solutions’ in Vista, for instance, and you’ll typically see useless crash descriptions like ‘Windows shut down suddenly’. Gee, thanks.

If your blue screen of death displays on an angle, we'd wager you've got a problem with your monitor. Just theorising.

Fortunately there’s a free alternative: Microsoft’s debugger, WinDbg. Point this at the last crash dump and it can tell you the most likely file, DLL or driver behind the crash; list everything else that was running; warn you of potential memory leaks; and provide useful troubleshooting and diagnostic information. If your PC is unstable then there’s no better tool to find out the cause.

Configure WinDbg

Microsoft does its best to hide WinDbg. You’ll have to download the Windows Driver Kit ISO image, a chunky 619MB, and then burn it to disc. Launch KitSetup and you’ll be presented with a list of various driver development options. Just check the box for ‘Debugging Tools for Windows’ and click ‘OK’.
For WinDbg to work properly it must be able to download ‘symbols’: files that help the debugger convert raw binary information into the function and variable names used by Windows components. These can be saved locally – a good idea as it’ll mean you only have to download them once. Create a folder for them – something like ‘C:\Windows\Symbols’ will be ideal. You’ll then need to tell the program where its symbols can be found and saved. Click Start, type WinDbg and click the ‘WinDbg.exe’ link to launch the debugger. Click ‘File | Symbol File Path’ to see the current path. Next, enter a path like SRV*c:\windows\symbols*http://msdl.microsoft.com/download/symbols in the box, where ‘c:\windows\symbols’ is replaced by the path to your own local symbol folder.

Windows Driver Kit contains the WinDbg component.

Click OK, close the program and click ‘Yes’ when asked if you want to save information for workspace – this will save the path you’ve just entered. It’s important to check that Windows is configured to create memory dump files when your PC crashes, because WinDbg needs these to figure out what was happening at the time. To set this up, click Start, right-click ‘Computer’ and click ‘Properties | Advanced system settings | Startup and Recovery Settings’. Ensure that the ‘Write an event to the system log’ box is checked to make sure that Windows collects information on your crashes. Next, clear the ‘Automatically restart’ box so that you’ll have a chance to read any on-screen error messages, and select ‘Kernel memory dump’ in the ‘Write debugging information’ list to ensure Windows saves all its memory blocks if it crashes.
Make a note of the dump file name – it’s probably ‘Memory.dmp’. This is the crash dump file you’ll need to locate later. Finally, click ‘OK’ to finish the job.

Create a report

Once WinDbg has been set up, it’s surprisingly easy to use at a basic level, and absolutely anyone can use it to find out more about their system’s last crash. To give this a try for yourself, click Start, type WinDbg and click the WinDbg link. Click ‘File | Open Crash Dump’, then navigate to and select your last crash dump file. This will probably be at?‘\Windows\Memory.dmp’, although you may have additional files in ‘\Windows\Minidump’.
Click ‘Open’, then wait as the file is analysed. This can take a while – five minutes or more – depending on the complexity of the dump file and the speed of your PC, so be patient. A ‘0 : kd>’ prompt appears at the bottom of the screen when it’s done, and you can then scan the rest of the report to see what’s on offer.

The crash dump can make for interesting reading.

Typically, near the bottom of the report, you’ll see a line like ‘Probably caused by : driver.sys’, where ‘driver.sys’ is replaced by the name of the file that WinDbg believes was responsible for the crash. Perfect! If you don’t recognise the name, Google it – maybe with additional keywords like blue screen – and you might immediately discover the app behind the instability, as well as some potential fixes.
Blue-screen crashes can be complicated, though, because the file that caused the crash isn’t necessarily the one responsible for your problems. That sounds odd, but look at it this way: if a faulty driver gives Windows an incorrect memory location, then this may be passed on to several other Windows components. Eventually one may try to access the memory, triggering a crash in that file – but the real problem is in the driver.
If WinDbg names some core Windows component or another application that you’re sure is working just fine, then it may be a problem like this. You’ll need to do a little more research to figure out what’s really going on.

Dig a bit deeper

Scan your WinDbg report again, looking for lines highlighted with ‘** ERROR’, complaining that ‘symbols could not be loaded’ for a particular file. If you’ve correctly configured WinDbg then it will be able to load symbols with Windows components with no problem, so you’ll know that these must be third-party drivers that were active at the time of the crash. Anything named like this is a possible culprit: again, search the web for the filename and you may locate other crash reports.
If that turns up nothing then click in the command line at the bottom of the WinDbg window, type !analyze –v (the ‘-v’ means ‘verbose’) and press [Enter] for a more detailed analysis of your crash file. The verbose report will be very much in developer-speak, with lots of figures, pointers, and development-related jargon, but you don’t have to understand all of it. Just pick out the parts that provide more information.
You’ll probably see an error message that spells out the crash reason, for instance. In one of our tests, the first report simply said our crash was ‘probably caused by nvlddmkm.sys’. The verbose report explained that the crash occurred when an ‘attempt to reset the display driver and recover from timeout failed’, which is much more specific and useful. If something similar appeared for you then you might install the latest driver updates for your display driver, and maybe that would solve the problem.
The verbose report may also contain details of the stack, essentially a list of the functions being called by Windows and your software immediately before the crash. This looks complicated – and to be honest, it is – but again, you don’t have to understand every word. All you’re looking to do is figure out what your PC was trying to do when the crash occurred, and the stack can offer very useful clues.

Read the stack

Open a crash dump file in WinDbg, type the command k and press [Enter], and you’ll see the stack, which is a list of the program functions that were called just before your crash occurred. These activities could give you a clue as to the general cause of your crashes.

The stack is baffling at the best of times, but it's the key to discovering the source of crash problems.

The oldest function on the stack is at the bottom, so you should start there and read up. Each line has two memory-related values followed by a function name, such as this: ‘00000000 00000000 nt!KiThreadStartup?+0x16’. Forget the numbers – it’s the function name that matters. In this case, the ‘nt’ before the exclamation mark tells us it’s a Windows kernel function, and ‘KiThreadStartup’ means it’s starting a thread.
You’ll almost certainly have different function names in your stack, but unless they’re very vague, don’t spend too long Googling them. All you really need to do is figure out generally what your PC was doing when it crashed. If most of the names begin with ‘dxgkrnl!-something-’, these are DirectX Graphics Kernel functions. This means your PC was engaged in something video-related when it crashed, so the video driver may be the cause. If a function begins with ‘tcpip!’ then it’s network-related, ‘ntfs!’ refers to the filesystem, ’mm!’ is the memory manager, and so on. The activity you find may not be the cause of the crash, but it’s another factor to consider.

Examine your system

If the standard and verbose reports can’t explain your crashes, you should take a closer look at your PC’s configuration at crash time. It’s just a matter of choosing the right command.
Typing !vm and pressing [Enter] will display comprehensive details on your system’s memory use, for instance. Scroll down the report, looking for oddities. For example, is there a warning of ‘excessive usage’ around the ‘paged pool’ or ‘non-paged pool’ details? This could mean that you have a resource leak somewhere, perhaps a driver that’s allocating Windows resources but not releasing them.
Is your paging file near its maximum size, maybe? If this is happening, it may also be aused by a resource leak, or perhaps you’ve manually set it to a size that’s smaller than it needs to be. Finally, below the general report is a list of Windows components and the RAM they were consuming at crash time. Does anything stand out?
The Process command can also be useful, as it shows you the system processes that were running at crash time. Type !process 0 0 (to clarify, those are zeroes) and press [Enter] to get the full list. Look for the HandleCount number here – this shows you how many Windows objects a process has open. This is normally a few hundred, perhaps a few thousand in some cases, but if it’s many thousands without an obvious good reason – it’s not an antivirus tool scanning your entire system, for instance – then again this might indicate that there’s a problem.
For the in-depth report on exactly which processes were in memory when your PC crashed, type lmv and press [Enter]. The command is an abbreviation for ‘Loaded Modules Verbose’, and the report gives you a very long list of programs, drivers and Windows components that were active at crash time. Have a scroll through the list, and you’ll probably find many drivers that you never knew you had. On our test PC, for instance, were drivers installed by HWiNFO32, VMware, VirtualBox, Paragon Partition Manager, assorted security tools and more.
If you want to keep similar third-party drivers on your PC, that’s fine. If you spot any relating to applications that you no longer use, though, it’s a good idea to uninstall them. There’s no guarantee that it will stop your blue-screen crashes, but you’ll free up a few system resources and simplify your system, and that’s always a solid step forward.
Perhaps the most important point of all is not to give up. Crash dump analysis is tricky, and WinDbg won’t always help with every crash, but you should keep digging anyway. It’s likely that, before long, it will provide the clues you need to get your PC running smoothly again.

Diagnose locked and hung applications

WinDbg isn’t just about troubleshooting blue-screen crashes – it can provide useful information regarding regular application crashes and hangs, too. If a program seems to have locked up, for instance, then press [Ctrl]+[Shift]+[Esc] to launch Task Manager, click the Applications tab, right-click the hung application and select ‘Create Dump File’. This only works in Windows Vista and 7, though, not XP.

See what your running processes are doing with your system's memory.

After a moment or two Task Manager will tell you where on your system it has created the file (this will usually be somewhere under ?‘\Users\[UserName]\AppData\Local’). Launch WinDbg, click ‘File | Open Crash Dump’ and open that file, using the command !analyze –hang –v for more clues about the cause of the problem.
You can use the other WinDbg commands we’ve described here, too, but application dumps contain different information to regular crash dump files, and the results aren’t always as clear. You’re unlikely to get accurate memory information from the !VM command, for instance. The differences mean that you should be careful how you interpret application crash dump reports.

Use workspaces

By default WinDbg will regularly ask if it should save information for workspace. Essentially this means saving your current settings, and when you first enter the symbol path this is essential. Otherwise, though, we’d recommend clicking the ‘No’ button – it’ll ensure the program works with its default settings, which is probably best for casual WinDbg users. If you find yourself using WinDbg a lot, though, it may be worth learning how workspaces can help. The NT Debugging blog has a detailed post that explains all that can be found at bit.ly/99yPCU.

 For More Check Related Links :