How to Use Windows Debugger to Troubleshoot a Blue Screen Error (BSOD)

download and install the Windows debugging tools for your version of Windows, visit the Microsoft Debugging Tools Web site.

Standalone version Windows Debugging Tool for Windows 7

 Windows SDK fow Windows 7

Windows SDK of Windows 10 

Start the Debugger

Start -> All Programs -> Debugging Tools for Windows (x64) ->WinDbg

1.    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:\symbols*http://msdl.microsoft.com/download/symbols" in the dialog box
then click OK.

2.    Open a minidump file:
expand the File menu,
select Open Crash Dump,
select the desired dump file
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.).

3.    The debugger will open the dump file and give a brief description of what caused the system to crash. 

a.     

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 likememory_corruption

b.    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

 (Credit: Dell.com)