Tracking a .NET Memory Leak with a Managed Heap Dump

Look for types that account for a substantial portion of the heap or appear to grow unexpectedly between snapshots.

For example, a heap summary might reveal a large number of strings, byte arrays, dictionaries, or application-specific objects.

The interpretation depends on the application. A service that processes documents may legitimately retain byte arrays while processing a batch. A web service that accumulates request objects indefinitely may indicate an unintended retention problem.

You can also inspect objects of a particular type:

dumpheap -type System.Byte[]

This narrows the output to byte arrays, which can be useful when large buffers dominate memory usage.

The exact output depends on the dump and runtime. Avoid treating object count alone as a measure of severity; total size and reference relationships are equally important.

Inspect a Specific Object

If the heap summary identifies a suspicious object, inspect its address:

dumpobj 00007ff012345678

Replace the sample address with an address returned by the analyzer.

The command displays information about the object, including its type and fields. Addresses are specific to the dump, so never reuse an address from one snapshot when analyzing another.

For collections, inspect the object structure and determine whether it holds references to many other objects. A small dictionary can retain a large amount of memory if its entries reference large object graphs.

Step 4: Find What Keeps an Object Alive

Finding a large object is only part of the investigation. The next question is why the garbage collector cannot reclaim it.

Use gcroot with the address of a suspicious object:

gcroot 00007ff012345678

The command attempts to identify reference paths from garbage-collection roots to that object.

A root may be associated with a static field, a stack reference, a handle, or another runtime-managed reference. If a long-lived static collection references the object, the output can help explain why it remains alive.

Consider this example:

public sealed class RequestRecord
{
    public required string RequestId { get; init; }

    public required byte[] Payload { get; init; }
}

public static class RequestHistory
{
    public static readonly List<RequestRecord> Records = new();

    public static void Add(RequestRecord record)
    {
        Records.Add(record);
    }
}

Every record added to RequestHistory.Records remains referenced by a static collection. Unless the collection removes entries, the records and their payload arrays can remain alive for the lifetime of the process.

A heap dump may reveal the growing list and its retained object graph.

The important finding is not simply that RequestRecord objects exist. It is that a long-lived collection continues holding references to objects the application may no longer need.

Step 5: Fix the Retention Problem

The correct fix depends on why the objects remain reachable.

For an unbounded request-history collection, possible solutions include:

• Store only the fields required for diagnostics.

• Apply a maximum number of retained entries.

• Use a bounded queue or ring buffer.

• Move durable history to an external storage system.

• Remove entries when their retention period expires.

For example, a bounded queue can limit the number of records held in memory:

using System.Collections.Concurrent;

public sealed class RequestHistory
{
    private readonly ConcurrentQueue<string> _records = new();

    private readonly int _capacity;

    public RequestHistory(int capacity = 1000)
    {
        if (capacity <= 0)
        {
            throw new ArgumentOutOfRangeException(nameof(capacity));
        }

        _capacity = capacity;
    }

    public void Add(string requestId)
    {
        _records.Enqueue(requestId);

        while (_records.Count > _capacity)
        {
            _records.TryDequeue(out _);
        }
    }
}

This example demonstrates a bounded retention policy, but it is not a complete high-throughput bounded-buffer implementation. ConcurrentQueue.Count and the enqueue/dequeue sequence do not enforce a strict capacity atomically under concurrent writers. Production implementations that require a hard memory limit should use an appropriately synchronized bounded structure.

The broader principle is to define an explicit retention policy rather than assuming the garbage collector will remove objects that remain referenced.

Step 6: Compare Before and After Dumps

After implementing a fix, repeat the same workload and collect another dump.

Compare the object counts and total sizes for suspicious types. Also examine whether the reference paths that previously retained the objects still exist.

A successful fix should produce evidence such as:

• The number of retained objects stops growing indefinitely.

• The managed heap reaches a more stable level after workload cycles.

• The problematic root-reference path disappears or retains only the intended number of objects.

• Memory usage remains within the application's operational limits.

Memory does not always return immediately to its previous level. The runtime may retain committed memory for future allocations, and caches may legitimately preserve objects. Evaluate trends across comparable workload cycles rather than expecting the process memory figure to drop to a precise value.

Other Tools for Heap-Dump Analysis

dotnet-dump is useful for command-line investigations, but other tools can help depending on the problem.

Visual Studio Diagnostic Tools provide a graphical workflow for supported environments, including memory analysis and object-retention inspection.

PerfView can help investigate managed allocations and garbage-collection behavior, particularly on Windows.

JetBrains dotMemory provides graphical heap analysis and comparison features that can make object retention easier to investigate.

Choose tools based on the runtime, operating system, dump format, and available diagnostic data. Not every tool supports every dump type or every deployment environment.

Production Considerations

A dump may contain credentials, tokens, personally identifiable information, request payloads, and other sensitive data. Treat it as a sensitive production artifact.

Restrict access, encrypt it during storage and transfer, and delete it according to your incident-response or diagnostic-data retention policy.

Also verify that the process permits diagnostic access. Container security settings, user permissions, runtime configuration, and deployment restrictions can prevent dump collection.

Finally, avoid repeatedly capturing large dumps from an already memory-constrained process. Collection itself can require additional resources and may worsen an incident. When the application is close to its memory limit, evaluate the risk before triggering a full dump.

Summary

A managed heap dump helps explain why a .NET application retains memory. By examining heap statistics, inspecting suspicious objects, and tracing references with gcroot, developers can move from observing memory growth to identifying the code responsible for it.

The most reliable workflow is to establish a baseline, capture a dump after representative workload, identify growing object types, trace their references, implement a targeted fix, and repeat the same experiment.

The key distinction is between allocated memory and retained memory. The garbage collector can reclaim objects that are no longer reachable, but it cannot determine that a reachable object is no longer useful to the application. Finding and removing those unintended references is the central task when investigating a managed memory leak.