Home / Product Selection / PC / Microsoft Windows / How to use the Microsoft Debugging Tool to troubleshoot Stop Errors (Blue Screen) in windows
  • Question

    How to use the Microsoft Debugging Tool to troubleshoot Stop Errors (Blue Screen) in windows

    • Answer
    • Dell Recommended Video - Dell has created an online tutorial on how to use the Windows Debugger tool to troubleshoot specific blue screen errors. 
      Click here to view the Windows Debugger tutorial! - NOTE: English Only 


      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:

      1      Download and install the Windows Debugger from the Microsoft Web Site .

      Note: 
       
      If you use Google to search for "windows debugger," the first link returned will be the Windows Debugger home page.
       







      2      Once installation completes click , click  All Programs, click  Debugging Tools for Windows, then click  WinDbg to open the debugger. 


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


      4      Open a minidump file: expand the File menu, select Open Crash Dump, select the desired dump file and click Open.

      Note: 
       
      The system usually stores minidump files in either: C:\WINNT\Minidump\ or C:\Windows\Minidump\. The files will be named miniMMDDYY-NN.dmp, where MM is the month, DD is the day, and YY is the year in which the dump file was created. NNis 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.).
       







      5      The debugger will open the dump file and give a brief description of what caused the system to crash. (Figure 2)

      Note: 
       
      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.sys in this example, you'll sometimes see things like memory_corruption







      6      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 the Enter key to have the WinDbg perform a detailed analysis of the file.

      Note: 
       
      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









    •  
    • View Answer at http://support.euro.dell.com/support/topics/global.aspx/support/entvideos/windebug_tool
    •  
    •  
    • Not the answer you were looking for?
    •  
    • Click a problem area below for more PC solutions
    •  
    •  
    •  
    •  
    •  
ad_holder