driver and the system BIOS are fully up-to-date, check with the manufacturer for recent driver updates.
- As a last resort, try exchanging the video card.
Reinstalling Windows is not likely to prevent this error from reoccurring.
The Windows Debugger is one of the primary tools used by Microsoft software developers and support staff to analyze and resolve errors that result in memory dumps, and it's available for you.
The Windows Debugger is a powerful tool with many useful applications, but for this article, we are only interested in its ability to analyze memory dump files generated by blue screen errors to determine the cause of the error.
Before you can use the tool, keep in mind the following:
- The Windows Debugger is not a native Windows tool. You must download and install the application (15 MB) from the Microsoft web site. Administrator access is required to install the tool.
- The Debugger requires some minor customization before use.
- The Debugger can take anywhere from 30 seconds to two minutes to fully analyze a memory dump.
To use the tool, follow these steps:
- Download and install the Windows Debugger from the Microsoft Web Site .
If you use Google to search for "windows debugger," the first link returned will be the Windows Debugger home page.
- Once installation completes click Start, click All Programs, click Debugging Tools for Windows, then click WinDbg to open the Windows Debugger.
- Configure the symbol path used by the debugger to turn addresses in the memory dump file into meaningful location names: expand the File menu, select Symbol File Path, type "SRV*c:\debug_symbols*http://msdl.microsoft.com/download/symbols" in the dialog box then click OK.
- Open a minidump file: expand the File menu, select Open Crash Dump, select the desired dump file and click Open.
The system usually stores minidump files in either: C:\WINNT\Minidump\ or C:\Windows\Minidump\. The files will be named miniMMDDYY-NN.dmp, where MMis the month, DD is the day, and YY is the year in which the dump file was created. 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