Rising process memory is a reason to investigate, not sufficient proof of a managed-memory leak. Separate process memory, managed-heap capacity, allocation activity and objects that remain reachable. Then identify the owner keeping unexpected objects alive.1, 4
A useful diagnosis explains both the growth and the unwanted lifetime. “There are many strings” describes a heap; “a long-lived collection retains completed requests without eviction” identifies a candidate defect that can be tested.
Memory captures can affect service availability and contain sensitive information. This guide does not include collection commands.
Define the number that is increasing
Begin with the exact metric, units, process identity and sampling interval. A host's total memory use, a container's accounted usage and one process's working set are not interchangeable. Keep the workload and process start time alongside the chart.
Microsoft's diagnostic example presents managed-memory measurements separately from process working set. Managed object storage is only part of the process picture. A rising process measure with stable managed-heap evidence does not establish managed-object retention.1
Also distinguish allocated bytes over time from currently retained bytes. An application can allocate many short-lived objects that collections subsequently reclaim. Allocation pressure may harm performance even when the long-lived population remains bounded.
Conversely, modest allocation can still accumulate an unwanted retained population over a long period. The investigation therefore needs both rates and comparable snapshots, not one large value from one moment.
Compare equivalent workload phases
Warm-up, cache population, a batch operation and steady service are different phases. Record which phase each observation represents. Comparing a newly started process with a heavily used process can confuse expected population growth with a leak.
As an editorial method, compare measurements after similar completed work and at comparable collection boundaries. Note whether requests are still in flight and whether queued work is increasing. A backlog intentionally retains data until it is processed; that can be an operational capacity problem without being a lost-reference bug.
Do not force collections merely to make a dashboard look smaller. A forced collection changes the experiment and can affect latency. If a collection is part of an approved diagnostic procedure, record it explicitly.
A hypothetical bounded cache may grow to its designed limit and then stabilise. A collection that continues growing with every completed operation, beyond the intended retention policy, deserves a different investigation. Neither conclusion should be inferred from the first few samples alone.
Understand why the collector keeps objects
The garbage collector determines reachability from roots such as static fields, stack references and handles. Objects still reachable from those roots are retained. Objects that the business no longer needs are not automatically unreachable.4
That distinction explains many managed leaks: the runtime is correctly preserving objects that application ownership has accidentally kept alive. The fault lies in the lifetime relationship, not necessarily in the collector.
Inspect the path from a retained object to its root. Determine whether the owner is intended to live that long, whether its collection should be bounded, and which code should remove or release the reference.
A large object is not automatically a problematic owner. A small collection object may retain a much larger graph. Equally, multiple root paths can keep an object alive after one reference is removed. A credible explanation must account for the relevant surviving paths.
Move from type totals to ownership
Microsoft's memory-leak tutorial uses heap type statistics to find large populations, then inspects instances and root paths. It also describes comparing captures from the same continuing process over time.1
Start with which types grew in count and total size. Then examine representative instances from the growing population and their owners. Separate repeated instances from an unusually large instance; they can imply different defects.
For example, many retained response objects might be owned by a diagnostic collection, a cache or unfinished work. Those are hypotheses until the ownership graph and application lifecycle support one of them. Do not change cache limits merely because a type name contains “cache”.
Record the deployed build, symbols and relevant configuration with the evidence. The intended retention policy is part of the diagnosis: a root path can explain why an object survives, but only the application contract explains whether that survival is wrong.
Choose the capture for the question
dotnet-gcdump reconstructs a managed object-root graph from runtime events. It is useful for object counts and retention relationships. The retrieved documentation applies to tool version 10.0 and later; do not assume its options or buffering behaviour match every older installation.2
Collection triggers a full generation 2 garbage collection, which can suspend the runtime for a substantial period on a large heap. Event buffers and the collector tool also require memory. A process already near its limit is not a safe target simply because the output format sounds lightweight.2
A process dump provides different evidence. The dotnet-dump documentation distinguishes Full, Heap and Mini captures. A small capture is not guaranteed to contain the heap information required for a retention investigation.3
Microsoft warns that collecting a Full or Heap dump can page in substantial memory and can cause a memory-limited container to be terminated. Plan the capture with the service owner and test its resource needs in an appropriate environment.3
Capture success is not evidence completeness
The GC-dump documentation describes incomplete captures when required events are lost or information is missing. Buffering behaviour also varies with the target runtime. A generated file does not by itself establish that the entire intended heap graph is available.2
Check the collection result and analysis warnings before relying on absence of a type or root. If the capture is incomplete, state that limitation and decide whether another approved evidence source is needed. Do not interpret missing objects as proof that they were released.
Microsoft recommends a process dump when the GC dump is incomplete.2 Review its memory, storage and service impact before collection; switching capture type does not remove those constraints.
Protect captures as sensitive operational data. A process dump can include application memory, so its collection, storage, sharing and deletion need controlled access. This is a handling recommendation derived from the documented contents, not a claim that every capture contains a particular secret.
Recognise when the question is outside the managed heap
If managed retention does not explain process growth, broaden the evidence to runtime structures, thread counts, native dependencies and the operating system's memory accounting. Keep the distinction between a candidate and a proven cause.
dotnet-dump supports managed analysis but is not a native debugger and does not display native stack frames. A native-memory investigation may therefore require other platform-appropriate tools and expertise.3
Do not subtract two loosely related dashboard numbers and label the remainder a precise native leak. Their definitions, timing and accounting boundaries must align before such arithmetic is meaningful.
Verify the ownership fix
An effective fix changes the unwanted lifetime or bounds the retained population while preserving application behaviour. It might correct an owner's cleanup path or enforce an intended retention policy, but that choice must follow the evidence.
Under an approved repeatable workload, compare retained types, ownership paths, memory trends, latency and failures before and after the change. Include the period long enough to exercise the original growth mechanism. A restart alone only resets the observation.
The final finding should name the objects, their owner, why that ownership exceeded the intended lifetime and the measured result of the correction. If only growth has been observed, report growth and keep the leak diagnosis provisional.
Learning notes
- Allocation rate and retained memory describe different behaviours.
- A reachable object can be unwanted while the collector behaves correctly.
- Root paths connect heap growth to application ownership.
- Memory captures need resource planning, completeness checks and controlled handling.
Acceptance checklist
- [ ] Process memory, managed heap, allocation and retention are distinguished.
- [ ] Captures are complete enough for the claimed conclusion and handled under approved limits.
- [ ] Retained objects are linked to an owner and an unintended lifetime.
- [ ] Comparable workload demonstrates bounded retention and correct application behaviour.
References
- Debug a memory leak tutorial - .NET | Microsoft Learn. Accessed 2026-11-01.
- dotnet-gcdump diagnostic tool - .NET CLI - .NET | Microsoft Learn. Accessed 2026-11-01.
- dotnet-dump diagnostic tool - .NET CLI - .NET | Microsoft Learn. Accessed 2026-11-01.
- Fundamentals of garbage collection - .NET | Microsoft Learn. Accessed 2026-11-01.