Identifying root objects with ANTS Profiler

This article explains how to use ANTS Profiler to find out why objects are surviving garbage collection. The techniques described in this article are useful when you have already identified the parts of the application that are causing memory leaks. For example, when you close a particular dialog box in your application, and you expect to see an immediate drop in memory usage, but what you actually see is the number of bytes on all the heaps remaining constant.

You can use tools such as Task Manager and Performance Monitor to identify the general area of your application where you suspect you have a memory leak. ANTS Profiler enables you to track down the actual object that is causing the memory leak.

Setting up the profiler

Start ANTS Profiler, and do the following:

In the Profiler Project Wizard, select Memory profiler, and click Next.
Select the type of application you want to profile.
Specify the location of the executable file and click Finish.

ANTS Profiler asks you if want to start profiling your application. Click Yes.

To gather the profiling results, you will be taking a series of snapshots while your application is running. Click OK.

Getting results

With the application running in ANTS Profiler, work through the application until you get to the part where you suspect you have a memory leak. Take a snapshot by clicking Take snapshot in the ANTS Profiler toolbar. Whenever you take a snapshot, ANTS Profiler displays the profiling results and leaves your application running, ready for you to take more snapshots.

Using the "All objects" panel

Now that you have your profiling results, you need to locate the object that is not releasing memory when you expect it to. Click the All objects tab to display the All objects panel. This panel shows all the live objects in your application at the time when you took the snapshot. As there are thousands of live objects in a .NET application, you will find it useful to group the objects by Namespace, so that you can concentrate on objects created by your own code, rather than the .NET Framework. You may also find it useful to group by Object type. This should make it easier to find the object that you want to investigate.

All objects panel screenshot

Identifying root objects

When your .NET application runs, it creates a hierarchy of objects that reference each other. For example, in a form with a toolbar, the toolbar contains buttons, and each button contains images or text.

When an object is no longer required, such as when a toolbar button is removed, the garbage collector can release memory, provided that the object is not referenced by any other object. To find potential memory leaks, you need to walk through the object references to find the object at the top of the hierarchy. The object at the top of a hierarchy is known as the root object. However, an object can belong to more than one hierarchy, so you may need to investigate all the hierarchies to find the actual source of your memory leak.

Click the object you are investigating in the All objects panel, and then click the Hierarchy tab. The grid on the left shows objects that reference the current object (Referenced from), and the grid on the right shows objects which the current object refers to.

Hierarchy panel screenshot

You work your way up a hierarchy to identify root objects by clicking objects in the Referenced from grid. Each click takes you up a level in the hierarchy. When you get to the top of a hierarchy, the grid is empty. To be sure that you are at the top of a hierarchy, you can add the Root object column to the grid. To do this, right-click a column header in the Referenced from grid, and click Choose columns. In the Choose columns dialog box, drag the Root object column to the required position in the column header. When you reach the top of the hierarchy, Root object is set to Yes.

Fixing the problem

Having identified the root object, you can see the method that allocated the object by looking at the Allocated by value. Click the Source code tab to view the source code for the method. If there are many lines of code in your method, it may be useful to look for the new keyword to identify where the object is instantiated.

When you think you've found the source of your memory leak, fix the code in your application development tool, and then build your project. Run your application again in ANTS Profiler, and take a snapshot before you expect the object to be released, then another one after you expect the object to be released. When you examine the profiling results, the object should be present only in the results for the first snapshot. You may have to go through the process of identifying root objects and fixing your code several times, before your application uses an acceptable amount of memory.

Was this article helpful?

Search support