Like many of you, my copies of Windows XP crash with the now-classic "blue screen of death" (BSOD). When this happened a couple times recently to a new ThinkCentre A61 tower, I called Lenovo tech support. As the title of this posting suggests, it did not go well.
When Windows XP crashes, the default behavior is to create a minidump, a small file (only 88K) with a summary of, hopefully, the most important information about the failure. I wrote about minidumps back in November (see Dealing with software crashes, Part 2). If your copy of Windows has crashed (aka "blue-screened") in the past, you may find a minidump describing the problem in the C:\WINDOWS\Minidump folder. The format of the filename is MiniMMDDYY-99.DMP (the last two numbers being a sequence number).
Minidumps are in a binary format, opening them with Notepad is a waste of time. Windows XP doesn't include the necessary software (program Dumpchk.exe) to open a minidump file. The target audience for a minidump is a tech support person.
But, it seems Lenovo didn't get the memo.
When I spoke to a Lenovo technician on the phone, I was told they don't do that. That is, they aren't allowed to accept minidump files from customers. Instead, the debugging session is totally verbal. Been there, done that. Verbal debugging of computer problems over the phone is all but guaranteed to be a waste of time. It was in this case.
Although the minidump can be impenetrable, the Windows event log, specifically the System event log, also has information about Windows crashes. Shown below is the identifying information about the two Windows crashes I experienced.
The bugcheck was: 0x0000001a (0x00041284, 0xd7817001, 0x00003fde, 0xc0e00000)
A dump was saved in: C:\WINDOWS\Minidump\Mini021508-01.dmp
The computer has rebooted from a bugcheck.
The bugcheck was: 0x1000000a (0x00000010, 0x00000002, 0x00000001, 0x8051b0c8)
A dump was saved in: C:\WINDOWS\Minidump\Mini021508-02.dmp
At this point you have more information than the Lenovo tech support person assisting me had. He was only interested in the two error codes, not any of the additional data fields shown above in parentheses, which provide additional information about the problem.
While the System event log doesn't provide much information about the crash itself, taken together, the six event logs can provide a wealth of information about the overall goings-on inside Windows. Like the minidump files, the event logs are not very big; in XP they max out at 512K by default. You can see them below for the computer in question.
Lenovo's technicians are also not allowed to accept event logs from customers.
What's Your Experience?
Lenovo is only one company of many offering technical support for Windows. What has been your experience in trying to get a technician to review either a minidump or an event log?
Do other computer manufacturers also refuse to accept these small files when offered?
Has a support person ever asked for them?
Is there an equivalent situation with Macs?
Either leave a comment below, or e-mail me at minidump at michaelhorowitz dot com.
And, if anyone works for Lenovo, is this, in fact, the normal procedure or did the person I dealt with not follow the rules?
Debugging operating system crashes can be hard to impossible, especially with the small amount of information in a minidump. But not even trying is disgraceful.
See a summary of all my Defensive Computing postings.
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.
Software crashes all too often, and since misery loves company, computer users often swap horror stories. Back on Halloween, Lee Gomes did so publicly in the Wall Street Journal. His problem was with the Adobe Premiere Pro, a video editing program and, while I found it interesting, the article didn't offer advice for avoiding or dealing with software crashes. That's what I hope to do here. First though, defending your privacy.
ERROR REPORTING
When applications crash, a window often pops up asking if you want to report the problem to Microsoft. Gomes writes that the Microsoft employees who get these crash reports are "scrupulous ... about respecting user privacy". Perhaps, but the last company I would trust with personal information is Microsoft (just behind Marshalls and TJ Maxx). What's the connection between failed software and personal privacy?
Suppose Word crashes while you are working on a document that you don't want others to see. It's safe to say that pieces of that document are included in the information about the error that's sent to Microsoft. And it is possible, though I don't know how likely, that information from other running programs may also be included.
While just saying no, when asked about reporting the error to Microsoft, is easy enough, it's also easily forgotten. Fortunately, you can configure Windows to never report software failures to Microsoft by turning off the error reporting feature. In Windows XP this is done with:
Control Panel -> System -> Advanced tab -> Error Reporting button
I suggest disabling error reporting but still getting notified of critical errors.
CONFLICTS
The root cause of the problem in the article was all too common, a conflict with other software installed on the computer. Apparently the other software had mis-labeled something and "that slip-up cascaded throughout Windows...".
It doesn't have to be this way. In a perfect world, each application would be isolated from other applications.
Getting to this ideal is one of the reasons for the popularity of virtualization. For example, important applications can be run inside a virtual copy of the operating system and be the only software installed in that instance of the operating system. Virtualization software lets you run multiple operating systems concurrently on a single computer, so if need be a single machine can run multiple applications with no chance of their stepping on each others toes. Another option, often used with servers, is to limit one computer to a single application. Both are non-trivial steps to take, but when the application is important enough it makes sense.
There is also software, such as Thinstall, to virtualize a single application rather than the entire operating system. Here too, the idea is to isolate an application from the proverbial other kids in the sandbox that may not play well together.
The simplest way, however, to get application isolation is to use portable applications.
The name portable derives from the fact that the application can be run in any instance of it's supported operating system(s) without being formally installed. A portable program designed for Windows XP, for example, will run on any copy of Windows XP and from any disk drive letter, but the portability does not, in and of itself, imply that it will also work on Vista or Windows 2000.
The classic use of portable applications is to run them off a USB thumb drive, but they work just as well running off the C disk. I do this all the time. Whenever possible, I prefer to use portable applications (see this about portable Thunderbird).
An excellent source of portable applications is John T. Haller's portableapps.com. The interesting thing about this site is that Mr. Haller converts applications that were not designed to be portable in the first place. Some applications are portable even though they may not be described as such on their web site. For example, I often use the free EditPad Lite text editor from Just Great Software which is not touted as being portable, but is nonetheless. The same is true of the free, open source, AbiWord word processor. (Both are also available at download.com: AbiWord EditPad Lite)
AUTOMATICALLY RUN PROGRAMS
Complexity is at the heart of many software failures and, as the article pointed out, the complexity of Windows is frequently added to by a whole host of programs that insist on automatically running when Windows starts up. Auto-started programs are a long standing problem because:
- They make Windows start up slower
- They make it more likely that Windows will fail to start up
- They consume RAM and processor resources
- The more programs running in the background, the more that can go wrong
Windows XP has a built-in function (MSCONFIG) for controlling the programs that run automatically at startup time, but it's poorly designed. I am a big fan of a free program called Startup Control Panel, by Mike Lin. I install it on every computer I work on, feel lost without it and never had it cause a problem.
Both programs display a checkbox next to each auto-started program and you control if a given program will be auto-started the next time Windows boots by simply checking or unchecking the box. That's where the similarity ends though, Startup Control Panel is easier to use than MSCONFIG and more complete in its reporting.
For one thing, it's easier to find. Whereas MSCONFIG is one of those things you have to know about to run, Startup Control Panel creates a Startup icon in the Control Panel, just where a function like this logically belongs. Also, after modifying the list of auto-started programs it doesn't produce a confusing warning window the next time Windows starts up.
Windows has many different lists of programs to run automatically and Startup Control Panel shows five of those lists, each in its own tab. As for completeness, MSCONFIG shows 11 programs that are auto-started by Windows on the computer I'm writing this on. Startup Control panel shows 36.
There are two versions of Startup Control Panel. The normally installed version creates an icon in the Control Panel, the standalone version does not need to be installed. The advantage of the standalone version is that it's portable, the program is a single EXE file. The advantage of the installed version is that it's easy to find in the Control Panel (except that you have to use Classic View).
At download.com the Editor's review gave it only three stars, I would have rated it higher. Voters there agree, it is rated 4.5 stars (out of 5) by 229 CNET users.
Startup Control Panel works with Windows 95, 98, ME, NT4, 2000 and XP. According to the author it is not needed in Vista: "Windows Vista, after all these years, finally has a very good startup manager built-in; go to Control Panel > Performance Information and Tools, and then click on Manage Startup Programs on the left."
AUTORUNS
While Startup Control Panel is great for non-techies, us nerds are better served by another free program, Autoruns. Originally developed by Mark Russinovich and Bryce Cogswell of Sysinternals, the program is now available from Microsoft which purchased Sysinternals a while back.
Autoruns is even more complete than Startup Control Panel. According to the author it has "the most comprehensive knowledge of auto-starting locations of any startup monitor..." It's so complete as to be intimidating if you're not familiar with things like Explorer shell extensions, browser helper objects and Winlogon notifications.
There are two types of auto-started programs in Windows and both MSCONFIG and Startup Control Panel only show one type. The other type, services, is included in Autoruns. It's extensive list of auto-started programs can be pared down by opting to Hide Signed Microsoft Entries (under Options on the menu bar).
Autoruns has been helpful to me in tracking down assorted malicious software. The bad guys want their software to run automatically when Windows starts up, so Autoruns is bound to have an entry for it. In addition, it has shown some auto-loaded drivers that make for interesting stories that I'll discuss in future postings.
Autoruns is portable and works with all versions of Windows.
FIRST CLASS
When Windows crashes with the infamous Blue Screen of Death (BSOD) the offending program may not have been written by Microsoft.
Windows is internally structured like an airplane with first class and coach sections. The applications we use on a daily basis sit in, and are restricted to, coach. First class is where the guts of Windows (referred to as the kernel) sits. But anyone with enough money can get a first class ticket.
To illustrate, software from Andrea Electronics, Meetinghouse Data Communications, Atmel Inc, Analog Devices, Conexant Systems, Parallel Technologies and UPEK Inc. is sitting in first class on the computer I'm using to write this. Technically, these companies wrote driver software, as did three other companies that refused to identify themselves at all.
Once you're in first class you can wander around anywhere. Driver programs, from these companies and others, can thus muck up any part of Windows. And many of them have.
How often is Microsoft at fault when Windows crashes? According to Mr. Gomes, they know, but won't say. That tells me two things: 1) it's often their fault and 2) it's nice to be a monopoly.
Part 2 covers Driver Verifier (a utility built into Windows for debugging drivers), dumps, event logs and disk checking.
November 14, 2007: Updated to reflect the topics in Part 2.
November 9, 2007: Updated to reflect the two different versions of Startup Control Panel.
- prev
- 1
- next
