Oct 142014

Introduction to MiniDumpWriteDump

In this post, let me show you some sample code to create a full memory dump of any given process using the Windows API MiniDumpWriteDump.

Creating Full Memory Dumps using MiniDumpWriteDump

Here’s some sample code to create a full memory dump of any given process. Just call WriteFullDump(hProcessHandle). This process handle must have PROCESS_QUERY_INFORMATION and PROCESS_VM_READ access to the process. If handle information is to be collected then PROCESS_DUP_HANDLE access is also required.

Please test out before production use. Just some quick code that I was writing up for a customer.

#include <tchar.h>
#include <windows.h>
#include <DbgHelp.h>

using namespace std;

#pragma comment (lib, "dbghelp.lib")

void WriteFullDump(HANDLE hProc)
   const DWORD Flags = MiniDumpWithFullMemory |
   MiniDumpWithFullMemoryInfo |
   MiniDumpWithHandleData |
   MiniDumpWithUnloadedModules |

   HANDLE hFile = CreateFile(_T("F:\\main.dmp"), GENERIC_ALL, 0, nullptr, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, nullptr);
   if (!hFile)
     std::cerr << _T("Failed to write dump: Invalid dump file");
     BOOL Result = MiniDumpWriteDump( hProc,
                                      nullptr );


     if (!Result)
        std::cerr << _T("Looks like an error: MiniDumpWriteDump failed") ;
   }// End if


Significance of MiniDumpWriteDump flags

What gets into a process’ memory dump is determined by the flags we pass in to MiniDumpWriteDump API. The code that I’ve given produces the biggest dumps possible for a process. The output dump file in this case will have the entire process’ memory, modules, registers, thread information, unloaded module information, and process handle related information.

For our case we’ve given these five flags, this will just basically copy everything from a process’ virtual address space into a dump. Comment out any flags if you’re not interested in that information, for e.g. if you don’t need information on the handles in a process just comment out: MiniDumpWithHandleData.

MiniDumpWithFullMemory |
MiniDumpWithFullMemoryInfo |
MiniDumpWithHandleData |
MiniDumpWithUnloadedModules |



Jan 222014

[Edited post for Visual studio 2017, I had written this post for Visual Studio 2013]

Visual Studio 2017 comes with a new feature called “Debug Managed Memory” this feature also allows to compare managed memory usage across two dumps.  Read on…

This is how you would open a .net 4.5 memory dump in Visual Studio…


So for the purpose of this blog I’ve created memory dumps of a managed application that consumes high memory: memtest.exe. I’ve collected three memory dumps…

  1. MemTest.dmp
  2. MemTest (2).dmp
  3. MemTest (3).dmp

For demo purpose I’m opening MemTest (3).dmp ‘first’ as shown in the above screenshot. So once you open the dump in Visual studio this is how Visual Studio will look like…


Check out mouse cursor location in the above screenshot. Click on this option. You’ll see following dialog pop up….


Following which you’ll see the following screen…


This report will show the most number of objects on heap. If you noticed; the largest objects in my case are ArrayLists and second one is MemTest.Form1. This report will also show you the roots to an object, similar to gcroot in WinDbg.

Further in the above screenshot, I’ve highlighted an item in red. That option allows us to compare multiple dumps.

The resultant report will show you the diff view between the two dumps. For demo I’m comparing MemTest (3).dmp with MemTest.dmp. MemTest (3).dmp was collected after  memtest.dmp was collected so you should ideally see a positive diff between the two dumps since memory usage increased in MemTest(3).dmp. Please see screenshot…


Now you’ll see that, new columns has been added to this report, for e.g. “Count Diff.”, ‘Size Diff (Bytes)” etc. The bottom table shows you the “Reference Count Diff.” as well.

Really cool feature! Comparing managed memory has been never easier. Please note this feature is only enabled for.net memory dumps that use .net 4.5.