Dealing with software crashes, Part 2
A look at drivers, dumps, event logs, and disk checking.
The first part of this posting on dealing with software crashes covered preventing the leakage of personal information, portable applications, and controlling the programs that run automatically when Windows starts up. Here we look at dumps, event logs, and disk checking, but first, we pick up on the topic of drivers.
Driver Verifier
In Windows, the term "driver" refers to software used by the operating system to control the hardware in the computer. Each piece of hardware (sound, video, printer) has an associated driver program.
The last topic in the previous posting was an airplane analogy to illustrate the potential for problems with Windows drivers. They run alongside the most critical parts of Windows itself and a bug in the driver can crash Windows.
Considering this, it should come as no surprise that Microsoft has a utility program designed to weed out bugs in drivers. The program is called Driver Verifier, and it is included in all recent versions of Windows (Windows 2000 and later).
Driver Verifier does extra checking on the actions of drivers, while they are running, looking for potential problems. Think of it as super-debugging mode. Quoting Microsoft: "Driver Verifier monitors kernel-mode drivers and graphics drivers to detect illegal function calls or actions that might corrupt the system. It can subject the drivers to a variety of stresses and tests to find improper behavior."
I bring this up because it can be a useful thing for debugging. When working with a tech-support person, ask them if drivers are a possible cause of the software problem you are experiencing (video drivers were a suspect in the problem described in The Wall Street Journal story). If so, then ask if Drive Verifier would be helpful. If nothing else, use Driver Verifier to gauge the reaction of the person assisting you.
There is a performance cost to the extra error checking Windows does on the drivers being verified. If verification is turned on for all drivers, Windows may be noticeably slower. Hopefully, the tech-support person can limit the verifying to a small number of drivers.
But, every PC has a different set of drivers. Fortunately, Driver Verifier can list the installed drivers, their version number, and the company that produced them. To run it, open a Command Prompt window (aka DOS window) and type "verifier" without the quotes. You can then close the Command Prompt window. In Vista, a security dialog will ask for permission.
I suggest starting with the radio button that displays existing settings. If this is the first time Driver Verifier has been used, there should be no drivers listed in the right side of the resulting window.
This window also shows different types of tests that will all be set to "No" initially. Windows XP offers eight types of verification tests; Vista has a few more.
Click the back button, turn on the radio button to create standard settings, and then click the Next button. If you "Select driver names from a list," you can see all the installed drivers.
Unless you are a serious Windows techie, driver verifier does not produce any output that is of use to you. It is best used when working with assistance from professional tech support.
Minidumps
Another thing to look for when Windows software crashes is a minidump--a snapshot of the state of the system at the time of the failure.
Dumps can be invaluable to a tech-support person. I spent many years doing technical support and can attest that verbal descriptions of a problem over the phone are not much to go on. Dumps and event logs (the next topic) give a picture of the problem that no person can.
Windows dumps are only useful to someone familiar with the internal working of the operating system. Normal users can't even look at the contents of a dump, Windows does not include the necessary program (Dumpchk.exe) to format it.
Minidumps are small (88K) so sending them to tech support should not be a problem. If you're not asked to look for, or provide, a dump, it would make me wonder how capable the support person is.
By default, Windows XP writes dumps to folder C:\WINDOWS\Minidump. If this folder is empty on your computer, consider yourself lucky.
You can control a number of dump-related options. To do so in Windows XP, start at the Control Panel, then System, then the Advanced tab, and finally click on the Settings button in the start-up and recovery section.
In the system failure section (the bottom half of the resulting window, shown above), I suggest enabling the option to write an event to the system log and turning off the option of automatic restart.
In the write debugging information section, "small memory dump 64K" is the default and should be fine. Only if a tech-support person says this small/minidump doesn't provide enough information, would I chose one of the other options.
The small dump directory defaults to %SystemRoot%\Minidump, which normally translates to C:\WINDOWS\Minidump. There is no need to change it.
Minidumps have a file type of .DMP. The format of the filename is MiniMMDDYY-99 where the last two numbers are a sequence number. For example, Mini110407-01.dmp is the first dump taken on November 4, 2007.
Event Logs
Event logs provide a history of problems and thus can be very helpful in debugging software problems.
To look at the event logs in Windows XP, start at the Control Panel, select Administrative Tools, then Event Viewer. There are at least three different logs: Application, Security, and System. Each log is separate file. To determine the filename and location, right-click on the name of the log, get the Properties, and look for the "Log name." By default, the Application, Security, and System log files are respectively:
C:\WINDOWS\system32\config\AppEvent.Evt
C:\WINDOWS\System32\config\SecEvent.Evt
C:\WINDOWS\system32\config\SysEvent.Evt
A tech-support person should be interested in some, if not all of these files. Event logs shouldn't be that big; in XP they max out at 512K by default.
Check Disk
A corrupted file system may play a part in any software failure. One of the first steps to take when dealing with a software crash should be to run the Windows Check Disk utility.
To do so, open My Computer and get the properties of the C disk. Then go to the Tools tab and click on the Check Now button. This opens a windows with two Check Disk options; I suggest turning on both options. When you click the Start button, Windows will say it can't check a disk that's in use and ask if you want to schedule the checking for the next restart. Say yes and then restart Windows.
Checking a disk can take a long time and Windows does not stop when it's done to let you view any messages. But there is no need to watch the thing run since a summary of the disk checking is written to the Application log. Just after Windows starts up, look at the top of the Application log (where the most recent events should be) for an event with a source of "Winlogon" and a type of "Information." Double-click on it to see the results of the disk check. In my experience, minor inconsistencies are the rule rather than the exception.
May your Minidump folder be forever empty.