Reading a memory.dmp or other .dmp file
While the dreaded Blue Screen of Death (BSOD) occurs less frequently with newer versions of Windows than it did in years past, there are still times when the BSOD reveals itself.
I just ran into four BSOD’s on two Windows Server 2012 machines and I had the ‘opportunity’ to analyze a memory.dmp file today, so I thought I would post quick instructions on how to get a handy summary of the memory dump.
I’ve had this ”I Found a Fix” debugging page bookmarked for years and I’ve used it many times, so I need to give full credit to ifoundafix for their helpful steps. The only change I have below is to include updated paths.
It’s possible to debug remotely, and you may have requirements to do that. My quick instructions here are for local debugging. The debugging tools are very stable and if you install just what you need then they are small and a quick install, so running this on a production machine is generally safe, but you must make that decision for your particular environment.
This can be accomplished with 7 easy steps:
Step 1. Obtain and install the debugging tools. The links do change over time, but the following link is currently an exhaustive page which includes Windows Server 2012 and Windows 8 Consumer debugger tools, Windows 7, Vista, XP and Windows Server 2003.
Debugging Tools Windows
All you need to install is the “Debugging Tools for Windows”. Everything else is used for more advanced troubleshooting or development, and isn’t needed here. Today I followed the link to “Install Debugging Tools for Windows as a Standalone Component (from Windows SDK)” although for a different OS you may need to follow a different link.
Step 2. From the command prompt navigate to the debugging folder. For me with the latest tools on Windows Server 2012 it was at C:\Program Files (x86)\Windows Kits\8.0\Debuggers\x64\. You can specify the path during the install.
Step 3. Type the following:
kd –z C:\Windows\memory.dmp (or the path to your .dmp file)
Step 4. Type the following:
.logopen c:\debuglog.txt
Step 5. Type the following:
.sympath srv*c:\symbols*http://msdl.microsoft.com/download/symbols
Step 6. Type the following:
.reload;!analyze -v;r;kv;lmnt;.logclose;q
Step 7. Review the results by opening c:\debuglog.txt in your favorite text editor. Searching for PROCESS_NAME: will show which process had the fault. You can use the process name and other information from the dump to find clues and find answers in a web search. Usually the fault is with a hardware drivers of some sort, but there are many things that can cause crashes so the actual analyzing of the dump may take some research.
Often time a driver update will fix the issue. If the summary information doesn’t offer enough information then you’ll need to dig further into the debugging tools or open a CSS case with Microsoft. The steps above will provide you with a summary mostly-human-readable report from the dump. There is much more information available in the memory dump although it gets exponentially more difficult to track down the details the further you get into windows debugging.
Hopefully these quick steps are helpful for you as you troubleshoot the unwelcome BSOD.