NN is the sequence the dump files were created in if multiple dumps were generated on the same day (the first crash dump on a given day will be numbered 01, the second 02, etc.).
- The debugger will open the dump file and give a brief description of what caused the system to crash. (Figure 2)
The first time you use the Debugger to open and dump file on a system, it will take a few minutes to download symbol information in the background before it returns any information.
Figure 2: Windows Debugger
Suggested command for the Debugger's command line
Stop code from the blue screen (1000007F is the same as 0x7F)
What Windows thinks caused the crash (atapi.sysin this example, you will sometimes see things like memory_corruption
- When it returns this preliminary analysis, the Debugger tells you how to dig deeper. Type "!analyze -v" in the command line (kd>) field at the bottom of the window and press theEnter key to have the WinDbg perform a detailed analysis of the file.
The results will be lengthy, and you may have to scroll vertically within the Debugger's window to locate all the pertinent information.
Figure 3: Analyze the Results
A detailed explanation of the stop code (in the example, you can see that the kernel encountered an EXCEPTION_DOUBLE_FAULT (8), or an error while trying to process an error)
Figure 4: Further Analysis of the Results
The bug check code (notice in the example it includes the number 8, indicating the double fault)
The number of times the system has crashed with this exact error (typically 1)
The bucket in which Windows has categorized the crash
The stack trace at the time the system crashed, with the most recently called procedure on top (you can see in the example the system crashed while processing a request from the IDE controller)
Figure 5: Additional Analysis
The name of the module the system was in when it crashed. On an actual system, the module name is a link you can click to receive some useful information about the module, who created it, how old it is, etc