Analyzing output

Memory.Introspect produces files in the same formats as the official .NET diagnostic tools. That means every standard analyser works without conversion — .gcdump opens in PerfView and Visual Studio, .dmp opens in WinDbg and dotnet-dump analyze.

.gcdump files

PerfView (recommended)

PerfView is the canonical viewer for .gcdump files and exposes the richest analysis surface.

1. Launch PerfView.
2. File → Open → select the .gcdump.
3. Double-click the file in the tree to open the heap view.

Useful views:

• Heap Snapshot — type histogram with sizes and counts. Sort by size to find the biggest leaks.
• Reference Chains — what's holding object X alive? Right-click a type → Show Who Allocated.
• Heap Snapshot Diff — compare two .gcdump files. Open both, then File → Diff. The right way to detect a leak: capture before and after a suspected leaky workload, diff.

Visual Studio

Visual Studio's "Memory Analysis" window opens .gcdump natively.

1. File → Open File → select the .gcdump.
2. Use the Types and Paths to Root views to navigate.

Compared to PerfView, Visual Studio's UI is friendlier; PerfView's is more powerful.

dotnet-gcdump CLI

Use the CLI to convert or report on .gcdump files programmatically:

dotnet tool install -g dotnet-gcdump
dotnet-gcdump report snapshot.gcdump

The report command prints a type histogram to stdout — useful in CI checks.

.dmp files (process dumps)

dotnet-dump analyze

Cross-platform, scriptable analyser bundled with the .NET SDK as a global tool:

dotnet tool install -g dotnet-dump
dotnet-dump analyze snapshot.dmp

That drops you into an interactive shell — try dumpheap -stat for a type histogram, clrstack to see thread stacks, gcroot <addr> to walk to a root.

WinDbg (Windows)

WinDbg Preview opens .dmp files directly. Load SOS for managed analysis:

.loadby sos coreclr
!dumpheap -stat

The official WinDbg cheat sheet for managed debugging lists the SOS commands you'll use most.

Visual Studio

File → Open → Crash Dump — VS launches a guided UI for managed dump analysis. Convenient, but dotnet-dump is faster for repeat investigations.

Sampling profiles

SamplingProfileResult doesn't produce a file — read it directly in code, or serialise it yourself:

var profile = await introspector.CollectSamplingProfileAsync(pid, TimeSpan.FromSeconds(30));

await File.WriteAllTextAsync("profile.json",
    JsonSerializer.Serialize(profile, new JsonSerializerOptions { WriteIndented = true }));

If you want a .nettrace instead (the format dotnet-trace produces, openable in PerfView and dotnet-trace report), use the CLI tooling directly — CollectSamplingProfileAsync returns the aggregated top-methods view, not a raw event stream.

A workflow that works

For a typical "the process keeps growing" investigation:

1. Capture a .gcdump shortly after process startup.
2. Run the suspect workload.
3. Capture a second .gcdump.
4. Open both in PerfView and use Heap Snapshot Diff. The types that grew are your leak candidates.
5. For each candidate, follow the reference chains back to a GC root.

The two-snapshot diff is more reliable than reasoning about a single dump — absolute heap state at one point in time is hard to interpret, but growth is unambiguous.