In this lesson, you will learn how to use a post-mortem heap dump to capture and analyze the state of a crashed .NET application as it existed at the moment of failure.
Understanding the "Snapshot"
When a .NET application crashes, it often leaves behind a .dmp file—a binary snapshot of the process's entire memory space. Think of this like a crime scene investigation; the application is no longer running, but all the "evidence" (the objects on the heap, the state of the threads, and the call stacks) remains preserved in the dump file.
Performing post-mortem debugging means loading this file into a debugger (like WinDbg or the Visual Studio Debugger) to inspect the memory without needing to reproduce the crash manually.
Inspecting the Heap
Once you load a dump, you are essentially looking at a static representation of your GC heap. You can inspect objects that were alive when the process terminated. For example, if your application crashed due to an OutOfMemoryException, you might investigate the dump to see which specific object types occupied the most memory:
// Example: Conceptually, a dump allows you to run commands
// to count objects on the heap like this:
!dumpheap -stat
By running this in a debugger against your dump, you might discover that a specific class, perhaps LargeDataCache, has millions of instances that weren't garbage collected.
Why Use Post-Mortem?
Unlike Runtime Event Tracing or standard Stack Trace Analysis, which look at real-time telemetry or active exceptions, a dump allows you to see the values held by your variables at the time of the crash. You can inspect strings, look at private field values, or check the state of the thread pool to see if a deadlock occurred just before the process exited.
Because you have the dump file, you don't need to guess what your user's environment looked like; you have an exact, bit-for-bit replica of their memory. You can traverse the object graph, find where references are held, and determine exactly why the CLR couldn't proceed.
Key Takeaway: A dump file acts as a static "time capsule" of your application's memory, enabling you to identify the root cause of a crash by inspecting the exact state of objects and threads at the moment of failure.