You'll be using the debugger to diagnose memory crash files, so first you need to make sure that Windows is set up to create them. Right-click My Computer, select 'Properties | Advanced' and check the Startup and Recovery settings to ensure that 'Write debugging information' is set to 'Kernel memory dump' (unless you have good reason to do otherwise).

Click 'Start | All Programs | Debugging Tools for Windows' and launch WinDBG. (In Vista, make sure you right-click the WinDBG shortcut and select 'Run as Administrator'.) Click 'File | Open Crash Dump' and browse to your last crash dump file, perhaps '\Windows\ Memory.dmp' or a file in the '\Windows\ Minidmp' folder.

The debugger needs to download information from the web to help figure out the contents of your file, so be patient. You'll know when it's finished because a '0: kd>' prompt will appear in the bottom left-hand corner.

You should then see some basic information about the error type; 'Access violation – code c0000005' or whatever, and perhaps a DLL name as well. It's all data that might be useful if you want to search for online references to the error later. However, there's better to come. Once the debugger is ready, click in the command window to the right of the 'kd>' prompt and type the command: '!vm'.

After pressing [Enter], you'll be able to see how your virtual memory was being used at the time of the crash, including details for resources like paged pool, non-paged pool and system PTEs. The maximum values are displayed too, so it's easy to spot whether or not there was a resource problem at the time of the crash.

What if the resources all look fine? No problem – just enter this command instead: '!analyze -v'.

The debugger will now look at the record of what was going on at the time of the crash and tell you which file it thinks is most likely to be responsible. This may take a while, but it pays to be patient: in our tests, the debugger regularly managed to produce useful information. In the most recent test that we performed, it explained that our Windows crashes were probably caused by 'pctfw2.sys'. A quick visit to Google told us that the file was connected to the PC Tools Firewall and updating the program successfully solved the problem.

Of course, the debugger isn't right all of the time. Sometimes the '!analyze' command displays no useful information at all – and on other occasions, it'll blame the wrong file entirely. Results pointing to 'ntoskrnl', 'win32k', 'hal', 'ntfs' and other core components are usually false alarms and you shouldn't take any verdict as guaranteed. And you absolutely must not explore other debug commands or options while you're doing anything important in other applications. You could easily crash your own PC.

Still, cautious debugging frequently produces invaluable troubleshooting results which you simply can't discover any other way and this means that it's definitely worth a try. So don't be intimidated by the apparent complexity of these developer-oriented tools and techniques. Learning just a few low-level Windows details really can deliver positive results for everyone.