Over a million developers have joined DZone.

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

Here are a few tips for creating small, but usable, .NET application dumps.

Evolve your approach to Application Performance Monitoring by adopting five best practices that are outlined and explored in this e-book, brought to you in partnership with BMC.

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 theDumpWriter 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.

Learn tips and best practices for optimizing your capacity management strategy with the Market Guide for Capacity Management, brought to you in partnership with BMC.

Topics:
performance ,debugging ,.net

Published at DZone with permission of Sasha Goldshtein, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

SEE AN EXAMPLE
Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.
Subscribe

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}