Net memory leak tools

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. So the working set memory can be larger than the actual memory used.

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:. Delete all the current performance counters by selecting the counter and deleting the same by hitting the delete button. 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.

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? 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. I have used Aqtime with great success over the years.

Stack Overflow for Teams — Collaborate and share knowledge with a private group. Create a free Team What is Teams? Collectives on Stack Overflow. Learn more. Asked 13 years ago. Active 9 years, 7 months ago. Viewed 50k times. Community Bot 1 1 1 silver badge. DOn't close a question as a dupe withotu adding a link to the live question it's a dupe of Not a duplicate.

The other question is about "profilers" which indicates a focus on performance. This question is about "memory profiling".

There will likely be some overlap in the tools, but it is definitely a different question. Add a comment. Active Oldest Votes. NET Memory Profiler Real-time analysis feature Excellent how-to videos on their web sites Easy to use Reasonably performant obviously slower than without the profiler attached, but not so much you become frustrated Show instances of leaking objects Basically they both do the job pretty well ANTS One-click filters to find common leaks including: objects kept alive only by event handlers, objects that are disposed but still live and objects that are only being kept alive by a reference from a disposed object.

This is probably the killer feature of ANTS - finding leaks is incredibly fast because of this. In my experience, the majority of leaks are caused by event handlers not being unhooked and ANTS just takes you straight to these objects.

Object retention graph. Shows size with children in addition to size of the object itself but only when an instance is selected unfortunately, not in the overall class list.

Better integration to Visual Studio right-click on graph to jump to file Scitech. This is really useful for objects that are allocated in lots of different places. With ANTS it is difficult to determine exactly where the leaked object was created. Shows count of disposable objects that were not disposed. While not indicative of a leak, it does identify opportunities to fix this problem and improve your application performance as a result of faster garbage collection.

What do we want to see? If everything works fine, the ad window should be present in the first snapshot but absent in the second. Let's take a look. Click Add to comparison for each snapshot to add them to the comparison area. The order in which you add snapshots is not important as dotMemory always uses the older snapshot as the basis for comparison.

Click Compare in the comparison area. This will open the Snapshots comparison view. The view shows how many objects of a certain class were created the New objects column and removed the Dead objects column between snapshots. Survived objects shows how many objects have survived garbage collection, or, in other words, exist in both snapshots. Currently, we're interested in the AdWindow class. To ease the finding of the AdWindow class, let's sort all objects by the namespace they belong to.

To do this, click Namespace in the Group by list on top of the table. What's that? The GameOfLife. AdWindow object is in the Survived objects column, which means that the ad window is still alive. After we closed the window, the corresponding object should have been removed from the heap. Nevertheless, something has prevented it from being collected.

It's time to start our investigation and find out why our ad window has not been removed! As mentioned in the How to Get Started with dotMemory tutorial, you should think of your work in dotMemory as of crime investigation. You start your investigation by analyzing a huge list of suspects objects and continuously narrow the list until you find the one that causes the issue. Your chain of reasoning is shown in the so-called Analysis Path on the left side of the dotMemory window.

Open the survived GameOfLife. AdWindow instance. To do this, click the number 1 in the Survived objects column next to the GameOfLife. AdWindow class. As the object exists in both snapshots, dotMemory will prompt you to specify in which snapshot the object should be shown. Of course, we're interested in the last snapshot where the window should have been collected.

This will show us the instance "The instance of the AdWindow class that exist both in snapshot 1 and 2". Note that the list of possible views for instances differs from the one of an object set. For example, the default view for an object instance is Outgoing References that shows the tree of instance's references to other objects. Nevertheless, we're interested not in the objects that are referenced by AdWindow , but only in those that reference it, or, in other words, retain the ad window in memory.

To figure this out, we can switch to the Key Retention Paths view. This view shows the graph of retention paths. Note that the view shows not all possible paths , but only those that differ from each other most significantly. This excludes a huge number of very similar retention paths and simplifies the analysis. Click Key Retention Paths in the list of views. As you can see, the ad window is retained in memory by the event handler EventHandler , which, in turn, is referenced by an instance of the DispatcherTimer class.

The text above the DispatcherTimer instance gives us one more clue - the instance is referenced via the Tick event handler. Now, let's find out which method subscribes our instance to the Tick event handler and take a thorough look at the code. Now, all we need is to determine the method that creates our instance. To quickly find the required method, switch to the Creation Stack Trace view. Here it is! The latest call in the stack that actually creates the timer is the AdWindow constructor.

Let's find it in the code. As you can see, our ad window uses the ChangeAds method to handle the event. But why is the ad window kept in memory after we close it?

The thing is that we subscribed the window to the timer's event but forgot to unsubscribe it. Therefore, the fix of this leak is quite simple: we need to add some Unsubscribe method which should be called when closing the ad window.