Task Manager
The simplest way to check your current Windows resources is through Task Manager. Press [CTRL]+[Shift]+[ESC] to launch it, select the Processes tab, click 'View | Columns' and ensure the 'Memory – Paged Pool', 'Memory – Non-paged Pool', 'Handles', 'USER Objects' and 'GDI Objects' are checked. Reboot your PC and make a note of the highest value in each case, as well as the paged and non-paged totals displayed on the Performance tab.
An hour or two later, take a look at Task Manager again. Anything using several thousands of handles, GDI or USER objects should be looked at closely, and Windows XP users should be concerned if non-paged pool use is over 200MB or paged pool allocations have passed 250MB. This may not mean buggy software – your application may simply be doing a lot of work – but this can help point you in the right direction. Google the process name to find out more.
The Windows Performance Monitor can also help display this data, along with some other figures that Task Manager doesn't provide. Launch 'perfmon.exe', click the plus sign to graph a new value, then open the Memory counters and choose 'Free System Page Table Entries'. If this is very low, perhaps a 1,000 or less, then you may also have a resource leak somewhere.
So where is it? If you're regularly getting complete PC crashes – the 'blue screen of death' that kills Windows and forcibly reboots your system – then there's one suite that can probably help you find out: the Windows Debugging Tools. Sure, they're aimed at developers, and they're complicated and packed with jargon, but they can also take a crash dump file and let you know whether resource problems were the cause. If they're not, then you can get some very helpful clues about the real culprit. And, despite their technical reputation, using the Debugging Tools at this level is very, very easy.
Debugging tools
Start by downloading and installing the appropriate debugging package for your system (www.microsoft.com/whdc/devtools/debugging/ debugstart.mspx).
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.
