Find the cause for a blue screen – with Memory.dmp

For a long time I have wanted to write a short instruction on how to find the cause for a blue screen of death with the help of a Memory.dmp file.

What causes a blue screen?

Yesterday I had to find out such a cause again and I took the opportunity to give you an explanation:
 
 

Requirements for the creation of a “Memory.dmp” file

1. It can be set in the system properties of a Windows Computer. You can get there via the sytem applet “sysdm.cpl“.
2. You should set the following on the index card “ Extended” :
   – Deactivation of the option “Automatic restart”
   – Ideally select “Kernel memory dump” in the field debuginformation
   – Activation of the option “Overwrite existing file”
   – You can also view and adapt the location of the “Memory.dmp” –file if necessary

In case a “Memory.dmp” –file is not created, it is possible to do it manually. The following KB article explains how to do this. http://support.microsoft.com/kb/244139

 
Looking up the STOP Error

To get a first indication to the cause of the error, you can view the STOP-error on the following website where these errors are categorized for you.

Link : http://aumha.org/a/stop.htm
 

Analyzing the Memory.dmp

For the analysis of the file you have to install the “Debugging Tools for Windows” on a computer which does not necessarily have to be the one the error occurred on.

Link : http://msdn.microsoft.com/en-us/windows/hardware/gg463009.aspx

After the installation, the “WinDbg” hast o configured to be able to analyze the “Memory.dmp“-file.

We have to configure the place where the debugger gets its “symbol-files” from.

1. Create a folder on the computer, i.e. “C:\WinDbg\Symbols“
2. Start “WinDbg” and select the command “Symbol File Path“. Enter the following:
   SRV*C:\WinDbg\Symbols*http://msdl.microsoft.com/download/symbols.
   The path “C:\WinDbg\Symbols” is the folder you created under 1.
3. Now you can copy the “Memory.dmp“-file onto the computer. Via the menu “File” -> “Open Crash Dump” the Windows debugger starts the analysis of the “Memory.dmp“-file and we get our first hint to the cause. => “Probably caused by“
4. To get a more thorough analysis, enter “!analyze -v” into the lower box of the “command”-window and confirm with ENTER. Already the first line of the result is interesting for us. The symbolic name of the error is listed there in capital letters.
   i.e: ATTEMPTED_WRITE_TO_READONLY_MEMORY
   In this case it can be that the “WinDbg” knows more and can give clues on how to solve the error.
   Enter .hh and the name of the error
   i.e. .hh ATTEMPTED_WRITE_TO_READONLY_MEMORY into the lower box of the “command”-window
5. Looking at the other lines of the result we get further information about the cause.
   STACK_TEXT = Here, the contents of the stack which the processor processed are listed. The last function is listed in hexa-decimal-numbers. The last column contains the names of the participating drivers and system-files. The entry before the exclamation mark, is the respective file, which usually has to complemented with .sys. The listed files are to be included into the circle of possible suspects, except their name is nt.
6. Now we are looking into who the producer of the files is which caused the bluescreen. When you found the files on the server, you can search for clues to the producer in the following places: name of the folder the file is in, in the file properties (version and/or the producer’s name). Now you can look for a solution or a new version of the driver/file on the producer’s support website. Also try the Microsoft Knowledge Base http://support.microsoft.com/search/.