Thereís a lot of noise out there about Vista. If you spend
all your time at Digg (http://www.digg.com), youíll probably come away with the
impression that Vista is the worst thing since open sewers. I leave that
distinction only to its price tag. For me, it has been the finest operating
system upgrade Iíve ever had the pleasure of experiencing (I upgrade all my
Windows operating system tests; theyíre the toughest scenario offering old
software, drivers, hardware and, usually, a massively diverse load of software
installed over time). The experience, however, hasnít been devoid of little
application compatibility issues and itís those problems for which there is now
a systematic approach in Windows Vista.
Previous versions of Windows were heavily dependent on a
total crash of the system, the infamous Blue Screen of Death (BSOD). If you had
a persistent, nagging software issue, you could configure the system to crash
itself and produce a memory dump file for debugging by pressing a particular
set of keystrokes (http://support.microsoft.com/kb/244139).
The problem with this approach is multi-faceted. First, you were going to crash
the entire system deliberately. (I bet your Service Level Agreements donít allow
for that behavior!) Second, youíd get a huge file exactly the same size as the
amount of installed memory which someone was going to expect you to FTP to them
for analysis. And, lastly, if you didnít have a paging file on the system drive
at least as large as the installed RAM, you couldnít get a memory dump file at
The unfortunate thing about dump files is that they are the
only way to examine the system state when you canít find logged entries about
software and hardware exceptions.
Vista has introduced a simple way to get a dump file of a
reasonable size and related strictly to your faulting application and it allows
you to do this without bringing the whole system down. Watch how itís done as
we create a simulated software failure and generate a dump file for analysis.
To get started, youíll need to first get a copy of the
Sysinternals Process Explorer (yeah, I know, theyíre Microsoft now, but I prefer
to honor their heritage) from http://www.microsoft.com/technet/sysinternals/ProcessesAndThreads/ProcessExplorer.mspx .
Once you have Process Explorer, go ahead and start it up.
Next, open Windows Explorer and attempt to map a network
drive to a share which doesnít exist!
Now, click Finish and wait for the error result. Do NOT click Diagnose!!
Note that the title of the dialog is Network Error. Bring Process Explorer back
to the foreground and look for a child process with this window title and make a
note of itís process ID (PID).
Right click the Taskbar and choose Task Manager from the menu.
Modify Windows Task managerís view to include the PID column then search for
the PID we noted before.
Right click that process and choose Create Dump File then
wait while the file is written
When the dump file is finished writing, a dialog will appear
to tell you where to find it.
In this case, a 266 MB dump file was created. Itís still
large but it could have been worse by being a complete memory dump which would
have resulted in a 4 GB file on this system!
Were this a real debugging exercise, you could now forward
the dump file to the software vendor for analysis where your problem
description would be compared to the contents of this dump file which would,
hopefully, result in a bug fix being issued from the software vendor.
The results for you are wonderful. You can now gather
application fault data or a more reasonable size and you can generate that data
without forcing a dirty crash of your system. Even the application may remain
running after the memory dump is performed so thereís a strong chance you wonít
even have interrupted any customer processing while taking effective,
systematic steps to generate useful debugging data.