One of the most annoying things that can happen to an administrator is when at random intervals a PC crashes and generates a so-called blue screen of death. A blue screen can be caused by a number of faults and it is sometimes very hard to pinpoint the cause simply by looking at the blue screen information itself. There are other ways to diagnose a blue screen and, if you have a Memory Dump, you can debug the crash and find out exactly what caused it.
Generating a Memory Dump:
In the event that your system is not configured to generate a Memory Dump file when a blue screen occurs, you need to enable the functionality before we can proceed with debugging the root cause of the issue. In order to do this you need to do the following:
- Open the Control Panel
- Open the System settings
- Switch to the Advanced Tab
- Click on the Settings button under the Start-up and Recovery section
A dialog will open with various settings; towards the end there is a section called “write debugging information”.
The first combo box contains the kind of memory you want to dump when Windows experiences a crash. For our purposes kernel memory dump will suffice. The next edit box contains the location where the memory dump will be stored.
Getting the Necessary Tool:
In order to debug a memory dump we will need a free tool supplied by Microsoft called WinDbg. This is actually a debugger and it can be downloaded for free from the Microsoft website.
Make sure you download the correct debugging tools for your architecture, run the file, install it and you’re ready to debug the blue screen.
Debugging the Issue:
A lot of people are not comfortable debugging a memory dump but the process is simpler than most people think.
The first step we need to do when WinDbg loads is to configure symbols path for the debugger. Symbols comprise information that for efficiency’s sake a compiler strips out of executables. Things like variable and function names are very important to a programmer but not to Windows. For this reason when your compiler compiles your source code this information is kept out of the executable to make it smaller and more efficient. To debug a problem however, symbols are very useful. Luckily for us, Microsoft provides a symbols server which WinDbg can make use of to get symbols as required.
To configure symbols click on:
- The File Menu
- Select Symbol Search Path
Now we need to enter the following line:
This will instruct WinDbg to fetch any needed symbols from the Microsoft symbol server and store them locally in the provided folder which in this case is c:\symbols. You can choose another folder if you want.
Click on the OK button and we can start to debug our dump file.
Note: WinDbg will need access to the Internet in order to fetch the symbol files it needs.
We now need to open the dump file itself and we do this by:
- Clicking on the File Menu
- Select Open Crash Dump
- Select the Crash Dump you want to debug and click OK
It will take a short while for WinDbg to open your dump file and load up the symbols required.
In order to do a detailed analysis after the dump file finishes loading, type in the prompt: !analyze –v and press enter.
After some time we’ll get all the information we need to determine what is causing the blue screen.
Information of Interest:
Right below Bugcheck Analysis we’ll get a small report by WinDbg on what error occurred and what information is relevant to that error, such as what parameters where used when the crash occurred.
Process_Name contains the name of the processes where the crash occurred.
BUGCHECK_STR displays the exception code. A list of codes can be found on the msdn site.
DEFAULT_BUCKET_ID displays the category of the error
STACT_TEXT displays the stack trace.
This should give you the information you need to determine the cause of the blue screen and provides you with a starting point you need to solve the problem.