Best Practices No 5: Detecting .NET application memory leaks

Introduction

Memory leaks in a .NET application have always been a programmer's nightmare. Memory leaks are the worst problem in production servers. Production servers normally need to run with the least down time. Memory leaks grow slowly and after time they bring down the server by consuming huge chunks of memory. Most of the time people reboot the system, make it work temporarily and send a sorry note to the customer for the downtime.

Avoid task manager to detect memory leak

The first and foremost task is to confirm that there is a memory leak. Many developers use windows task manager to confirm, is there a memory leak in the application?. Using task manager is not only misleading but it also does not give much information about where the memory leak is.

First let's try to understand how the task manager memory information is misleading. Task manager shows working set memory and not the actual memory used, ok so what does that mean. This memory is the allocated memory and not the used memory. Adding further some memory from the working set can be shared by other processes / applications.

So the working set memory can be larger than the actual memory used.

Using private bytes performance counters to detect memory leak

In order to correctly get the amount of memory consumed by the application we need to track the private bytes consumed by the application. Private bytes are those memory areas which are not shared by other application. In order to detect private bytes consumed by an application we need to use performance counters.

The steps we need to follow to track private bytes in an application using performance counters are:

• Start you application which has memory leak and keep it running.

• Click start and Goto run and type 'perfmon'.

• Delete all the current performance counters by selecting the counter and deleting the same by hitting the delete button.

• Right click and select 'Add counters' and select 'process' from performance object.

• From the counter list select 'Private bytes'.

• From the instance list select the application which you want to test memory leak for.

If your application shows a steady increase in private bytes value that means we have a memory leak issue here. You can see in the below figure how private bytes value is increasing steadily thus confirming that application has a memory leak.

The above graph shows a linear increase but in live implementation it can take hours to show the increase. In order to check memory leak you need to run the performance counter for hours or probably days together on production server to check if really there is a memory leak.

3 step process to investigate memory leak

Once we have confirmed that there is a memory leak, it's time to investigate the root problem of the memory leak. We will divide our journey to the solution in 3 phases what, how and where.

• What: - We will first try to investigate what is the type of memory leak, is it a managed memory leak or an unmanaged memory leak.

• How: - What is really causing the memory leak. Is it the connection object, some kind of file who handle is not closed etc?

• Where: - Which function / routine or logic is causing the memory leak.

What is the type of memory leak? Total Memory = Managed memory + unmanaged memory

Before we try to understand what the type of leak is, let's try to understand how memory is allocated in .Net applications. .NET applications have two types of memory managed memory and unmanaged memory. Managed memory is controlled by garbage collection while unmanaged memory is outside of garbage collectors boundary.

So the first thing we need to ensure what is the type of memory leak is it managed leak or unmanaged leak. In order to detect if it's a managed leak or unmanaged leak we need to measure two performance counters.

The first one is the private bytes counter for the application which we have already seen in the previous session.
The second counter which we need to add is 'Bytes in all heaps'. So select '.NET CLR memory' in the performance object, from the counter list select 'Bytes in all heaps' and the select the application which has the memory leak.

Private bytes are the total memory consumed by the application. Bytes in all heaps are the memory consumed by the managed code. So the equation becomes something as shown in the figure below.

Unmanaged memory + Bytes in all helps = private bytes, so if we want to find out unmanaged memory we can always subtract the bytes in all heaps from the private bytes.

Now we will make two statements:

• If the private bytes increase and bytes in all heaps remain constant that means it's an unmanaged memory leak.

• If the bytes in all heaps increase linearly that means it's a managed memory leak.

Below is a typical screenshot of unmanaged leak. You can see private bytes are increasing while bytes in heaps remain constant

Below is a typical screen shot of a managed leak. Bytes in all heaps are increasing.

How is the memory leak happening?

Now that we have answered what type of memory is leaking it's time to see how is the memory leaking. In other words who is causing the memory leak ?.

So let's inject an unmanaged memory leak by calling 'Marshal.AllocHGlobal' function. This function allocates unmanaged memory and thus injecting unmanaged memory leak in the application. This command is run within the timer number of times to cause huge unmanaged leak.