Crash Dump Analysis

You can use the dot commands to load and unload debugger plug-in DLLs (also called debugger-extension DLLs) and control the behavior of a live debugging target. A live target is an operational system that you're actively debugging. Like the built-in commands, dot commands either don't facilitate crash dump analysis or they require advanced knowledge.

Debugger-extension DLLs implement the bang commands. WinDbg and Kd automatically load the kdextx86.dll basic kernel-debugging extension DLL, which provides commands that let you display information about various Win2K or NT kernel objects. Start with some initial data gathering by running the !process pid command. This command dumps information about the process that was being executed when the crash occurred. To obtain a complete list of processes, use the !process 0 0 command. The command !thread tid dumps data about the thread that was being executed, including its stack trace. Simply determining which process was running at the time of a crash might provide a useful clue to the crash's cause, and the stack trace might list a driver that was responsible for the crash. If you run !thread tid on a crash dump you generated with BSOD, you'll see a stack trace that identifies crashdd.sys.

If you see text such as TrapFrame @ 8013eee8 on the right side of the stack trace's line, run the .trap nnnn command, where nnnn is the hexadecimal number that appears after the ampersand in the text (8013eee8 in the sample text). Then, run the Kv command. WinDbg shows you the stack trace of a trap frame, which reflects the stack before a trap handler function took control. Although WinDbg isn't always able to display an accurate stack trace, when it does, the trap frame's stack trace reveals the actual trace that led to the crash. Do a Knowledge Base search for the names of any drivers you see in the stack trace on the chance that you've encountered a Microsoft-documented problem. Refer to the WinDbg Help for advanced tips about trying to determine a stack trace yourself.

The !drivers command dumps a list of load drivers that contains some of the same information that NT 4.0 presents on its blue screens. This command displays driver creation dates, which can alert you to out-of-date drivers. Check with vendors for updates to old drivers. One way to determine a driver's vendor is to view the properties of the driver file in Windows Explorer (most drivers are stored in the \winnt\system32\drivers directory); the version information includes the developer's copyright notice and sometimes a description of the driver.

Numerous other bang commands exist (the !help command provides a complete list), but I've presented those that you can use without advanced knowledge of Win2K or NT internals. The WinDbg Help file describes various options that the bang, dot, and built-in commands support.

Good Luck with Your New Knowledge
Despite Kanalyze's best effort, no magic wand exists that you can wave at every crash dump to precisely identify the cause. I hope I've provided some guidance that helps you extract from a crash dump information that you might not otherwise have obtained. As I wrote at the start of this article, spending a few minutes with Kanalyze or WinDbg might save you from repeated crashes or from spending hours reinstalling the OS. Thus, learning about these tools is worth your while even if they don't always help you.

End of Article

   Previous  1  2  [3]  Next