Last night my computer decided to randomly blue screen while I was using it. The errors displayed by these blue screens are typically pretty useless. Usually you’re shown some sort of stop error and a bunch of hex code along with it. When your computer blue screens there is a good chance it will create a memory dump during the crash. Most people don’t realize that you can analyze Windows crash dump files to find out what may have caused the crash. If you know what caused the crash then you might be able to fix the problem and prevent it from happening again. Sometimes it can be as simple as updating a buggy device driver or installing a Microsoft patch.
Locating the dump file
By default windows will store dump files in two different locations.
Minidumps – %SystemRoot%\Minidumps\
Kernel Dumps – %SystemRoot%\MEMORY.DMP
Minidumps are a much smaller in size than kernel memory dumps but contain less information. Its possible that a crash could create both a minidump and a kernel dump or neither. The conditions have to be just right in order for Windows to actually create a dump file. If your hard drive doesn’t have enough free space the memory dump will not be created.
Memory Dump Settings
If you weren’t lucky enough to get a crash dump when your computer blue screened there are a few settings you can check so that next time it occurs you have a better chance of getting the file.
Open the system properties menu by right clicking on my computer and going to properties (or press Windows key + Break). On the advanced tab click on settings under startup/recovery. For the ‘Write debugging information’ selection box choose kernel memory dump. If you want you can change the location the dump file will be saved to , I recommend keeping it somewhere on the C drive though. If you want you can disable the automatic restart so that you have time to view the blue screen error.
Installing the Windows debugging tools
In order to analyze the crash dump you will need to download and install the Windows debugging tools which are part of the Windows SDK.
When you get to the installation options page I recommend selecting all of the install options. As a minimum you will need to select debugging tools for windows, and debugging tools under redistributable packages.
Once the installation is complete you will have a new item on your start menu called ‘Microsoft Windows SDK’, although the utility we are going to be using (windbg) can not be found there. Instead you can either navigate to its location via Windows explorer or run it via the command line. I prefer to just use the command line myself.
1. Change to the programs directory
From the command prompt:
cd C:\Program Files\Debugging Tools for Windows (x64)\
2. Then launch the debugger
windbg
3. Load the crash dump file
Next we will open the dump file we want to analyze by selecting ‘Open crash dump’ from the file menu.
4. Load the debugging symbols
Before the debugger can interpret the dump file it will need to load the debugging symbols from Microsoft’s symbol server. To do this select ‘Symbol file path’ from the file menu. In the box enter 
http://msdl.microsoft.com/download/symbols. Make sure to check the reload box so it will download them as soon as you click OK. The symbols won’t take long to download. You will see a confirmation in the command screen when the download is complete.
5. Analyze the memory dump using !analyze -v
In the small command window at the bottom where the kd> prompt is type !analyze -v and hit enter. This command will instruct the debugger to analyze the crash dump and try to determine the root cause of the crash. If you take a look at the screen shot below the first item I have circled is default_bucket_id. You’ll see it has identified the crash as a Vista driver fault. This means that most likely the problem is due to a faulty driver.
If you look further down the output you an see the module name is SbieDrv.sys. A quick google search on this sys file identifies it as belong to Sandboxie, a sand box program I have installed on my computer. So something must have happened that caused a bug in the Sandboxie driver which resulted in a crash. I’ll probably try updating the program first, or just uninstalling it if the problem persists.
Final thoughts
Next time one of your computers crashes due to a blue screen of death grab the memory dump and fire up your debugger to find out what happened. As I said earlier you won’t always get a crash dump file when a blue screen occurs. I highly recommend making sure that your computer is configured to save a full kernel memory dump so you will be as best prepared as you can when a crash occurs. Another thing to take into consideration is that blue screens often occur due to a hardware error, such as bad memory. Memory dumps from hardware related issues will probably not contain anything of value and will often lead you down a rabbit hole. If you want to learn more about memory dumps check out my post about memory dump analysis using Moonsols.
References
Microsoft Support – How to read small memory dumps
One thought to “How to Analyze Windows Crash Dump Files”