Advanced troubleshooting tips: Windows XP and Vista

Then click Start, All Programs, Debugging Tools for Windows, then WinDbg, and select File, then Symbol File Path. Type:

SRV*c:\symbols*http://msdl.microsoft.com/download/symbols

in the box (replacing c:\symbols with the path to your symbols folder, if you used something else) and click OK.

Click File, Exit, and click Yes when asked if you want to ‘Save information for workspace’ to ensure your changes are recorded.

That’s the debugger set up properly, but is Windows configured to save crash files?

Right-click Computer, select Properties, Advanced [System Settings], Startup and Recovery Settings and make sure ‘Write debugging information’ is set to ‘Complete memory dump’ if available, ‘Kernel memory dump’ if not.

Click OK and you’re ready to go.

Using WinDbg
The next time a blue-screen crash occurs, restart Windows and click Start, All Programs, Debugging Tools for Windows, then WinDbg. (Windows Vista users should right-click the WinDbg shortcut and select Run As Administrator.)

Then click File, Open Crash Dump, browse to your Windows folder and open the MEMORY.DMP file it contains.

If you can’t find the crash dump, Windows will write it to the paging file first.

If you have turned off paging, or perhaps set it to a fixed size to improve performance, this may not be possible.

Right-click Computer and select Properties, Advanced [System Settings], Performance Settings, Advanced, then Change, and make sure all your paging files are set to ‘System managed’.

Reboot and a crash dump file should now be created for the next BSOD.

If you skipped the ‘Write debugging information’ tweak we recommended, and left the setting as ‘Small memory dump’, then you may have a crash file in a different location.

Browse to \Windows\Minidump to look for it.

And sometimes Windows just can’t create a crash dump file, perhaps because it’s a file system-related driver that has crashed and it’s not safe to write to disc.

But if you have found the file then all you have to do is, well, wait.

Analysing the crash can take a few minutes, especially if you have a slow PC and a large dump file.

Once WinDbg has finished you will usually see a line beginning ‘Probably caused by’, that names the DLL or driver most likely to have caused the crash.

Exactly what you need to know – make a careful note of this.

The debugger provides a more thorough analysis of your crash than you’ll get from the initial BSOD error screen, but there’s still the possibility that it has delivered the wrong verdict.

So make a further note of any additional files where WinDbg complains that ‘symbols could not be loaded’.

These will be third-party drivers and DLLs that were active at the time of the crash, and will also be strong suspects for the cause of your BSOD.

Now search Google (and your PC) for these file names.

This should quickly tell you which application installed them, and whether others complain that they often cause crashes.

If you find a good candidate then check the author’s website for support documents that might help.

Updating your software may fix the problem, or you could try uninstalling the program if it’s not critical.

Resource leaks
If WinDbg has not identified a specific file as the cause of your problems, you may have a more general issue.

Many blue-screen errors occur because you have run out of system resources, for instance.

An example might be a driver that allocates more and more Ram without ever releasing it, until eventually you run out of Ram and your PC crashes.

To check for this, click in the WinDbg command line to the right of the kd > prompt, type !vm and press Enter.

You will immediately see how your Ram was being used at the time of the crash.

Scan down the report and look for references to ‘paged pool’ and ‘non-paged pool’, for instance, two special areas of memory that Windows and your drivers use to store memory.

If this is full then you will see a warning of ‘excessive usage’.

This can happen if you try to run large numbers of applications – 20, 30, 40 or more – but otherwise it’s a strong indication that you have a resource leak of some kind.

If it’s a slow leak then rebooting more often may help you live with the problem for now, as the driver won’t have time to grab all your resources, but ultimately you will need to identify the file involved.

Microsoft’s informative Performance Team blog has some detailed information that could help, and Windows expert Mark Russinovich walks you through a similar real-life problem-solving session on his own blog.

If you don’t see a leak then look at the second part of the report, from the ‘Total Private’ heading down.