How to profile memory leaks in .NET applications with dotnet-counters

A memory leak in a .NET application is rarely a single dramatic event. It often appears as a gradual rise in private memory, longer garbage-collection pauses, or an application that behaves normally during testing but becomes unstable after several days in production. The .NET garbage collector can reclaim objects that are no longer reachable, but it cannot remove objects that your code still references accidentally.

dotnet-counters provides a lightweight way to investigate this behaviour while an application is running. It exposes runtime counters for allocation, garbage collection, managed heap size, working set, exceptions, and thread-pool activity. The tool does not replace a heap dump or a full memory profiler, but it can quickly show whether a suspected leak is real and where to focus the next diagnostic step.

This approach is useful for ASP.NET Core APIs, worker services, background processing applications, and containerised workloads. It is also practical when a production process must be observed with minimal disruption. A team in Sydney supporting customers in Melbourne, Brisbane, or Perth can collect useful runtime evidence without immediately attaching a heavyweight graphical profiler.

The most valuable result is a timeline rather than a single reading. Memory that rises during a request burst and then falls after collection may be normal. Memory that rises repeatedly while Gen 2 collections fail to reduce the managed heap deserves closer attention.

What dotnet-counters can reveal

dotnet-counters is a command-line global tool included in the .NET diagnostics toolset. It connects to a running .NET process and reads EventCounters or Meter-based runtime metrics. The data is sampled at intervals, making it suitable for watching trends rather than inspecting individual objects.

For a modern .NET application, useful counters commonly include:

• gc-heap-size: the managed heap size reported by the runtime
• working-set: physical memory associated with the process
• allocation-rate: bytes allocated per second
• gen-0-gc-count, gen-1-gc-count, and gen-2-gc-count: collection activity by generation
• time-in-gc: the proportion of time spent in garbage collection
• loh-size: the size of the Large Object Heap where available
• threadpool-thread-count: thread-pool activity that can help correlate load and blocked work

Counter names and availability can vary with the .NET version and runtime provider. Start by listing the available providers and counters rather than assuming every metric exists on every target. In a mixed estate containing .NET 6, .NET 8, and older services, this small check avoids misleading comparisons.

A leak investigation should distinguish managed memory from total process memory. A growing managed heap suggests retained .NET objects. A growing working set with a stable heap points towards native allocations, memory-mapped files, image libraries, sockets, runtime structures, or fragmentation. Both signals matter in a Kubernetes pod or an Azure App Service plan, where the operating system may terminate a process after its total memory crosses a limit.

Installing and connecting to a process

Install the tool on the machine where the target process can be reached:

dotnet tool install --global dotnet-counters

If it is already installed, update it when appropriate:

dotnet tool update --global dotnet-counters

List running .NET processes with:

dotnet-counters ps

Then monitor a process by its process identifier:

dotnet-counters monitor --process-id 12345 \
  --refresh-interval 5 \
  --counters System.Runtime

On Windows PowerShell, the command can be written on one line or continued with PowerShell’s backtick character. On Linux, ensure the diagnostic tool has permission to inspect the target process. Containers may require the tool to run inside the same container, or require suitable process and diagnostic socket access.

For a focused view, specify individual counters when supported by the installed tool and runtime:

dotnet-counters monitor --process-id 12345 \
  --refresh-interval 5 \
  --counters System.Runtime[cpu-usage,working-set,gc-heap-size,allocation-rate,time-in-gc]

The provider syntax is version-sensitive, so use the available provider list if a command returns an unknown counter. In managed hosting environments, process access may be restricted. Azure App Service, for example, may require diagnostics to run through the platform’s supported console or monitoring features rather than through a workstation connected directly to the production worker.

A practical Australian operating pattern is to collect a baseline during a quiet period in AEST or AEDT, then repeat the observation during the busiest customer window. A service used by retailers around the end of the financial year may show a very different allocation profile from the same service on an ordinary Tuesday arvo.

Reading memory trends correctly

Begin with the managed heap and working set. Record several minutes of normal activity, trigger a representative workload, and continue watching after the workload stops. A healthy application usually shows a saw-tooth pattern: allocations push the heap upwards, garbage collection reduces the live portion, and the cycle repeats. The exact shape depends on request volume, object lifetimes, server GC settings, and available memory.

A possible leak has a different pattern. The post-collection baseline keeps moving upwards after comparable workloads. Gen 2 collection counts increase, yet gc-heap-size does not return close to its earlier level. If time-in-gc also rises, the application is spending more time trying to manage a growing live set. This is stronger evidence than a single high memory reading.

Workload consistency matters. Comparing a quiet Melbourne morning with a high-volume Sydney campaign can create a false diagnosis. Repeat the same operation several times, such as importing the same file, processing an equivalent batch, or sending a controlled set of API requests. Note the time, request volume, deployment version, and relevant feature flags.

Look for relationships between counters:

• High allocation rate with a stable heap often means short-lived allocation pressure rather than a leak.
• A rising heap with modest allocation rate may indicate retained objects.
• Stable heap with rising working set suggests memory outside the managed heap.
• Increasing Gen 2 collections and large-object usage can point to long-lived buffers, oversized responses, or cache entries.
• A rising exception count may identify a failed processing loop that repeatedly allocates error objects and retains work items.

The tool reports symptoms, not retention paths. It can show that memory is not being reclaimed, but it cannot tell you which dictionary, event handler, static field, or task is keeping an object alive.

Turning counter evidence into a diagnosis

Once the trend is repeatable, capture a richer diagnostic artefact. A dump can be collected with dotnet-dump, while event traces can be gathered with dotnet-trace. A memory profiler can then show object types, generation placement, reference paths, and retained sizes.

Common causes include unbounded in-memory caches, static collections, event subscriptions that outlive their publishers, timers that retain state, queued work that is never completed, and closures holding large object graphs. Incorrect use of dependency-injection lifetimes can produce similar symptoms. A singleton that stores request-specific data effectively extends that data’s lifetime for the duration of the process.

Large Object Heap behaviour deserves special attention. Large arrays, strings, JSON documents, image buffers, and file contents can remain alive long enough to create pressure even when the application eventually frees them. Repeated large allocations can also produce fragmentation. A counter trend may reveal the problem, while a dump confirms which object types occupy the space.

Use a controlled comparison after applying a fix. Deploy the change to a staging slot or a canary instance, run the same workload, and compare the post-collection baseline. In a regulated Australian business, retaining diagnostic dumps may involve customer data and privacy obligations, so remove sensitive content where possible and store files according to the organisation’s access and data-retention rules.

Operating the investigation in production

Keep observation lightweight and time-bounded. dotnet-counters is generally less intrusive than a full trace or profiler, but continuous monitoring still creates operational overhead and diagnostic data. Set a refresh interval that reveals the trend without producing unnecessary output, and save readings with timestamps alongside deployment and infrastructure events.

For Linux services, systemd and container logs can be correlated with counter output. In Kubernetes, compare the managed heap with pod RSS, memory limits, restart counts, and throttling. A pod in an Azure Australia East region may appear healthy at the application level while approaching its container limit because native memory is growing outside the GC heap.

Use process identifiers carefully after restarts: a new deployment receives a new PID. A small script can discover the current process, start monitoring, and write output to a dated file. If the service runs across multiple instances, monitor more than one replica because a leak may depend on a particular traffic route, tenant, feature flag, or node condition.

Production access should follow least privilege. Avoid exposing diagnostics endpoints publicly, and do not copy dumps casually between offices or cloud regions. Teams operating across Sydney, Canberra, and Perth may have different access paths and support rosters, so document who can collect evidence, where it is stored, and when it must be deleted.

dotnet-counters is most effective as an early-warning and triage tool. It establishes whether memory growth is repeatable, separates managed from process-level symptoms, and helps select the right next diagnostic method. Combined with a controlled workload, a heap dump, and disciplined operational records, it turns a vague report that an application is “chewing through memory” into evidence that developers can investigate and verify.