|
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
all.
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.
|
