Friday, August 16, 2013

How to read a Windows memory.dmp

I just ran into BSOD’s on Win7 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.



                                                        Photo Credit - Dominick Reed

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. This can be accomplished with 6 easy steps:

Step 1. Obtain and install the debugging tools.  

All you need to install is the “Install Debugging Tools for Windows as a Standalone Component (from Windows SDK)” and during the install only select "Debugging Tools for Windows".  Everything else is used for more advanced troubleshooting or development, and isn’t needed here. 

Step 2. Run cmd.exe as admin and navigate to the debugging folder(C:\Program Files (x86)\Windows Kits\8.0\Debuggers\x64\.  Type the following:

kd –z C:\Windows\memory.dmp (or the path to your .dmp file)

Step 3. Type the following:
.logopen c:\debuglog.txt

Step 4. Type the following:
.sympath srv*c:\symbols*http://msdl.microsoft.com/download/symbols

Step 5. Type the following:
.reload;!analyze -v;r;kv;lmnt;.logclose;q

Step 6You will now have a debuglog.txt in c:\, open it in notepad and read it carefully. I recommend looking out for PROCESS_NAME: X
You should type X into Google and find out what this process is related to. Whatever is causing the problem you should then install, remove, update, etc accordingly 

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.


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.

No comments: