Creating Smaller, But Still Usable, Dumps of .NET Applications

August 19, 2015

5 comments

MiniDumper is born. It is an open source library and command-line tool that can generate dump files of .NET processes. However, unlike standard tools such as Procdump, MiniDumper has three modes of operation:

  1. Full memory dumps (analogous to Procdump’s -ma option). This is a complete dump of the process’ memory, which includes the CLR heap but also a bunch of unnecessary information if you’re mostly working with .NET applications. For example, a full memory dump will contain the binary code for all loaded modules, the unmanaged heap data, and a lot more.
  2. Heap-only dumps (no Procdump analog). This is a dump that contains the CLR heap memory as well as some additional useful information that you will need to analyze .NET-related issues: sync blocks, thread stacks, certain parts of binary modules, unmanaged data allocated by the CLR but required for debugging, and so on.
  3. Minimal dumps (analogous to Procdump’s default). This is a dump that can be used for basic triage: figure out what the threads are doing, if there is a current exception, which modules are loaded in memory, and so on.

Heap-only dumps can be 5x-10x smaller than full memory dumps for certain kinds of .NET applications. I haven’t done a lot of experimenting yet, but for an empty 32-bit console app, a heap-only dump is around 4MB while a full memory dump is more than 50MB. For a Visual Studio process with a loaded (small) solution, a heap-only dump is 350MB while a full memory dump is over 900MB.

Memory address spaces are getting rather big, so hopefully you can appreciate why you need smaller memory dumps of .NET processes. If you think you can find MiniDumper useful, head on to the GitHub repo to download the source code and play around. You can find some basic usage documentation in the README. If you don’t like external executables, you can use the DumpWriter class in your own application.

In a future post, I will explain how I built MiniDumper—or, specifically, how MiniDumper can tell which regions of memory are required for subsequent analysis of .NET issues.

Add comment
facebook linkedin twitter email

Leave a Reply

Your email address will not be published.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

5 comments

  1. Pingback: The Morning Brew - Chris Alcock » The Morning Brew #1929

  2. Alois KrausAugust 20, 2015 ב 8:20 PM

    This is a nice demonstration of what you can do with ClrMd. It would also be nice to be able to convert a full dump taken e.g. by WER into something smaller before it is transferred and packed. Ideally you could convert and zip the dump and create besides it a text file with all managed thread stacks and exceptions. If the process did crash with a plain exception there is no need to go into Windbg and look for the obvious.
    Just some ideas …

    Reply
    1. Sasha Goldshtein
      Sasha GoldshteinAugust 23, 2015 ב 4:48 PM

      Yeah, converting a full dump to a somewhat smaller dump could be cool. Unfortunately there is no API for that. The IDebugClient API that lets you create a dump from an existing target doesn’t afford all the customisation options and callbacks that you get from MiniDumpWriteDump.

      Reply
  3. Pingback: Automate the Planet

  4. Pingback: New features coming to minidumper | Low Level Design