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.
(Credit:
Guardsoft)
Supercomputers need super, or at least novel, debugging.
To meet that need, Cray has just agreed to license Australian software start-up Guardsoft's "relative" debugging technology for use in its new DARPA-funded supercomputer.
Relative debugging allows programmers to track bugs that creep into software as it is modified, or ported from one system to another, according to Guardsoft. It does this by comparing the execution of a suspect program with a clean version. This differs from traditional debugging in two ways: First, it compares program variables not with the user's expectations but with another program known to be correct; second, the process can be automated.
"Relative debugging is orders of magnitude faster than existing approaches because the programmer doesn't have to understand all the details of the code," said Professor David Abramson of Monash University where the technology was developed. "This is particularly valuable when the person performing the debugging is not the original developer."
The new software is called Guard and can be used on a number of platforms, including Linux, IBM's Eclipse, and Microsoft Visual Studio. Cray will use it to help application developers port existing programs into its new supercomputers.
This is all part of DARPA's $250 million effort to develop a High Productivity Computing System, which it hopes will provide a new generation of systems for national security and industrial users. You can find everything you ever wanted to know about relative debugging here.
- prev
- 1
- next
