How to find a memory leak in .NET?

28 January 2022 at 10:00 by ParTech Media - Post a comment

Memory leaks have long been programmer's worst nightmare in .NET. When it comes to production servers, memory leaks are one of the most common and annoying issues. As we all know production servers must operate with the least amount of downtime possible.

But memory leaks slow it down and eventually knock the server down by eating large chunks of memory. The majority of the time, customers reboot the machine to get it to operate again.

So now, let us quickly begin with the article and understand what is memory leak, its forms, and how to find a memory leak in .NET.

Table of contents

  1. What is a memory leak?
  2. What are the forms of memory leaks?
  3. What are the causes of memory leaks in .NET?
  4. Best practices to find memory leaks.
  5. Conclusion

What is a memory leak?

In general, a memory leak occurs when software or application holds a computer's primary memory for an extended period of time. It happens when a resident memory program does not return or release allotted memory space after execution, causing the system to become sluggish or unresponsive.

A memory leak also occurs when unmanaged code fails to release unreachable memory that can no longer be allocated by any process during the allocation process. GC (Garbage Collection) procedures or automated technologies can usually cure or detect this.

A memory leak can be considered a failure to release reachable memory that is no longer required for your program to run successfully in managed code.

What are the forms of memory leaks?

Following are the forms of memory leaks:

  • Leaks that go unchecked (code that allocates unmanaged code).
  • Leaks of resources (code that allocates and uses unmanaged resources, like files, sockets).
  • Objects have a longer lifespan.
  • A misunderstanding of how the GC and.NET memory management systems function.
  • Bugs in the.NET runtime.

What are the causes of memory leaks in .NET?

Memory leaks may seem counterintuitive in a garbage-collected system. Most of us wonder - how can my memory ‘leak’ when the garbage collector (GC) ensures that everything is collected?

There are two main reasons for this. The first root cause is when you have references to objects that are effectively unused. They will not be collected by the garbage collector since they are referenced, and they will remain in memory indefinitely. For example, this can happen when you register for events but never unregister.

The second reason is when you allocate unmanaged memory (without garbage collection) and then fail to free it. Now, this is not a difficult task for a developer to do. There are many classes in.NET that allocate unmanaged memory. Almost everything that has to do with streams, graphics, the file system, or network calls does it behind the scenes. Typically, these classes have a Dispose function that releases memory. With special.NET classes (like Marshal) or PInvoke , you may simply allocate unmanaged memory yourself.

How to find memory leaks?

Following are the best practices to find memory leaks:

Detecting a memory leak issue using Diagnostic Tool Window

The Diagnostic Tools Window is pretty useful. It can quickly identify two issues: memory leaks and GC pressure. When you create new items and dispose of them too quickly for the garbage collector to keep up, this is known as GC Pressure.

You won't be able to pinpoint specific memory leaks this way, but you will be able to detect the presence of a memory leak, which is useful in itself. The Diagnostics Window in Enterprise Visual Studio also has a built-in memory profiler, which can be used to locate the exact leak.

Detecting a memory leak issue using Task Manager, Process Explorer or PerfMon

The Task Manager or Process Explorer is the second easiest technique to detect serious memory leak concerns (from SysInternals). These tools can display how much memory your process consumes. If it continues to rise over time, you most likely have a memory leak.

PerfMon is a little more difficult to use, but it may produce an attractive graph of your memory utilization over time.

It's important to keep in mind that this procedure is unreliable. Because the GC hasn't collected it yet, you may notice an increase in memory consumption. There's also the issue of shared and private memory, which means you could overlook and/or misdiagnose memory leaks that aren't yours.

Despite the drawbacks, this strategy is simple to use and can be your only option in some situations.

Usage of memory profiler to detect a memory leak

When it comes to memory leaks, a memory profiler is akin to the chef's knife. It's the primary instrument for locating and repairing them. While other strategies may be simpler or less expensive, it is best to be familiar with at least one memory profiler in order to properly handle memory leak problems.

DotMemory, SciTech Memory Profiler, and ANTS Memory Profiler are the most popular.NET memory profilers. If you have Visual Studio Enterprise, you may also use a "free" profiler.

Memory profilers all work in the same way. You have the option of attaching to an active process or opening a Dump file. A Snapshot of your process' current memory heap will be created by the profiler. You can view how many instances of each type are allocated, how much memory they consume, and the GC Root reference path. Comparing two snapshots where the memory should return to the same state is the quickest and most useful profiling technique. The first snapshot is taken prior to the operation, and the second is taken after.

Using “Making Object ID” to find memory leaks

Assume you suspect a memory leak in a specific class. To put it another way, you suspect that after performing a specific scenario, this class will remain referenced and will never be collected by the GC. Follow these procedures to see if the GC actually collected it:

  • Set a breakpoint where the class instance is created.
  • To open the debugger's data-tip, hover over the variable, then right-click and select Make Object ID. To verify that the Object ID was created correctly, type $1 in the Immediate Window.
  • Complete the scenario that was supposed to de-reference your instance.
  • With the known magic lines, force GC collection.
  • In the immediate window, type $1 once more. If it returns null, your item was collected by the GC. Otherwise, you have a memory leak.


As we work in the era of advanced technology, being able to efficiently utilize the memory available becomes an important skill. So it becomes crucial to know the various techniques through which you can detect memory leaks and furthermore prevent them.