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 “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.  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 an elevated 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 times 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.

29 Comments

  • Boom shaakalka boom boom, problem solved.

  • Thank you very much. Atleast now I have an idea of what process is causing the problem. This really is a big step towards solving my problems. Thank you once again.

  • Thanks Scott, This was very helpful!

  • Many thanks, Scott! This helped me identify a problem with an ATI driver (atikmdag.sys). I've updated it now and have my fingers crossed.

    Thanks again!

    Lex

  • Hmm, I'm using windows 8 and for some reason its not recognizing kd or .logopen as any recognized commands

  • Hi G,

    Did you complete step #1 and #2 successfully? The debugging tools do need to be installed first and you need to navigate to the correct path. After that you should be set.

    Scott

  • Thank you very much for this concise explanation on how to parse a .dmp file. I used this info to help debug why BF3 was crashing on me. The culprit seems to be my on screen display, namely RTSShooks.dll. Thanks again!

  • Also not working for me on Windows 8. Steps one and two completed successfully as far as I can tell, can't work out what's wrong...

  • Hi G and ed,

    I'm curious what error you're running into. This worked for me in multiple situations, but there are so many different situations and slight differences that can throw it off.

  • hi windows 8 here too. KD does not open. when i opened a black box appears for a moment so i prntscr it.
    it says
    Failed to open \\.\com1
    Kernel debugger failed initialization, win32 error 0n2
    "the system cannot find the file specified."
    debuggee failed initialization, win32 error 0n2
    "the system cannot find the file specified."
    not sure if the 0n2 is a zero or an o its a circle with a slash in it

  • Hi Hussain,

    Interesting. I'm on the road for a couple weeks but when I return I'll try to reproduce this myself to see if I can see what you're seeing.

  • This article is so darn helpful! Thank you!!

  • Getting an error

    Could not open dump file
    "Access is Denied"

    Anyway to grant access?

  • Hi ed, hussain, and Ryan.

    I wonder if it could be because you are using a non-elevated command prompt where it doesn't have permission to make some of these changes. I just tried again on a new machine and it worked without any issue.

    I've updated the article to mention the elevated command prompt. That may do the trick.

    Otherwise, another good way to check permission or locking issues with with Process Monitor from sysinternals. Have it running while you reproduce the issue, then search it for the word 'denied'. Search until you see the correct denied line and then open it which will give helpful information on what fails.

  • really helpful and good explained in easy-to-follow steps. Thanks Scott!

  • Hi Scott,
    My problem is navigating to the installed folder in the elevated command prompt. I get C:\Windows\system32> but can't navigate from that.

  • Hi Robert,

    You can get to that folder with:

    cd \Program Files (x86)\Windows Kits\8.0\Debuggers\x64\

    Or, you can navigate to it in Windows Explorer and then Shift-right-click and click on "Open command window here".

  • Very cool and helpful, Scott. Your instructions are spot on. Thanks much for posting this.

  • This was helfull to see the reason for my BSOD but my process name appeard to be svchost.exe and i think i cant delete this file cause...its been a while but i ask for a little help please,

    TY in advance

  • Hi Tiago,

    You're right that svchost.exe is a core part of the OS and can't be deleted, and can't be updated (usually) if your computer is already up to date. The root cause is probably from something else.

    There maybe be other clues in the dump results, otherwise you'll need to dig deeper than this summary report if it doesn't provide enough info.

  • Worth mentioning...

    The latest SDK is listed as being "for Windows 8.1". The instructions above all still apply BUT even though you will have a folder c:\Program Files (x86)\Windows Kits\8.0\Debuggers\x64\ folder (as stated above) you need to navigate to c:\Program Files (x86)\Windows Kits\8.1\Debuggers\x64\ (note the embedded 8.1 instead of 8.0) to find the kd.exe program.

  • Bravo Scott. Brilliant work and thanks for your great effort.

  • Hi Scott,

    I just did the above process and got the following output. Can't figure out the output post the command. Seems to be a disk issues but the disk is just a year old. Can it be a driver issue too?

    Would it be possible for you to help a bit ??
    Thanks a ton in advance. //Sameer
    **********output***********


    ERROR_CODE: (NTSTATUS) 0xc0000185 - The I/O device reported an I/O error.

    DISK_HARDWARE_ERROR: There was error with disk hardware

    BUGCHECK_STR: 0x7a_c0000185

    DEFAULT_BUCKET_ID: WIN8_DRIVER_FAULT

    PROCESS_NAME: System

    CURRENT_IRQL: 0

  • Hi Sameer,

    This suggests that this is a hardware issue. Even though the disk is just a year old, something may be off with the disk. Also, it could be that there is an issue in the driver where it can't handle certain I/O patterns.

    If you can upgrade the drivers I would recommend doing that as a next step. The vendor may have discovered and addressed this issue.

    Otherwise it really is a hardware issue and you may need to replace the disk. Make sure you have a good backups of course, and you may want to wait for this to occur a second time to see if it's a one-off issue of it is becoming a real issue.

  • Awesome! Had a hard time getting the debugger installed but this worked perfect. Now to figure out why I'm blue screening.

  • I did not face a BSOD, or a system crash. What I did face was a particular python process starting to occupt a lot of memory.

    I am on Windows8.1.
    Opened the task-manager, noticed this python.exe, and right-clicked on the process and selected the "Create dump file" option

    Out of curiousity, I then proceeded to follow the steps you have listed here to see if there is something in the 1GB DMP file created. (As an aside, am using the python perf tools to analyse what is happening anyway)

    At step#6, I see an output which reads: "the symbol file for python.exe is not available" or something to that effect.

    I use python 32bit, so tried the instructions from within the x86 folder too.
    Any suggestions?

  • Hi Kiran,

    That simply means that the debugger doesn't have access to the information about python.exe to dig into it further. It's not a hint of an error, but rather it's telling you that it doesn't have information to find out more.

    You can point to the symbols if you have them, for example Step #5 does that for the Windows symbols.

  • Hi Scott,

    Thank you your post, it’s really helpful.
    I have one SQL Server which is going down frequently on weekends. below are the description of debugger output.


    DEFAULT_BUCKET_ID: DRIVER_FAULT

    BUGCHECK_STR: 0xD1

    PROCESS_NAME: sqlservr.exe

    TRAP_FRAME: f78aef2c -- (.trap 0xfffffffff78aef2c)
    .trap 0xfffffffff78aef2c
    ErrCode = 00000002
    eax=00001002 ebx=a25d43cf ecx=ffdffa48 edx=ffdffa40 esi=a25d4398 edi=ffdffa40
    eip=a25d43d8 esp=f78aefa0 ebp=f78aeff4 iopl=0 nv up ei pl nz na po nc
    cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010202
    a25d43d8 c60001 mov byte ptr [eax],1 ds:0023:00001002=??
    .trap
    Resetting default scope



    Could you please suggest posible cause for the server reboot.

    Thanks in advance.
    Pankaj BM

  • Hi Pankaj,

    That memory dump does show that SQL Server is the driver that crashed, but it doesn't give any further clues. Is there anything in Event Viewer? Has anything else changed since the crashed started that you're aware of?

    You can dig further into the memory dump but it's not straight forward to really dig into the memory and crash details in the memory dump. If event viewer doesn't give any clues then you may find it beneficial to open a case with Microsoft and send them the complete memory dump. They can dig into it in depth and if it's a bug in their software they should credit your support case to you.

Comments have been disabled for this content.