2. Checking unmanaged memory usage - ANTS Memory Profiler

Before you check your application's usage of unmanaged memory, we recommend that you check for fragmentation of the large object heap.

If you are not familiar with memory profiling, you might find it helpful to read about the .NET heaps before you start.

To check for unmanaged memory usage

Set-up ANTS Memory Profiler.
Click .
Do the action that you think causes the problem (for example, open the dialog box).
Click .
On the summary screen, look at the .NET and unmanaged memory pie chart. If there is a large amount of unmanaged usage, you should investigate it; see 'To identify the cause of large amounts of unmanaged memory', below.

If you do not have a large amount of unmanaged memory use, continue checking managed memory use.

To identify the cause of large amounts of unmanaged memory usage

Possible causes of large amount of unmanaged memory usage include:

Graphics buffers.
See the next section.
The .NET Common Language Runtime (CLR) itself.
The CLR itself uses unmanaged memory. If your application uses very little memory in total, the amount of memory used by the CLR may appear to take up a large percentage of the memory in use by the application.
If the amount of unmanaged memory used in your application is less than about 40MB, the CLR is likely to be the cause. Continue checking for managed memory usage.
Accessing unmanaged data through P/Invoke or COM+.
In these cases, ANTS Memory Profiler is unlikely to reveal any useful information, because it cannot profile unmanaged code.
Problems with object disposal in unmanaged code.
This is rarely the cause of a problem, but to check for this, switch to the Class List. On the Filters panel, switch to Filter By Reference. Select Kept in memory exclusively by..., click Add new item and then select By disposed objects. For each class that remains in the Class List, click the instance categorizer icon (), to check why instances of that class are being kept in memory.

Checking unmanaged memory usage due to graphics buffers

Switch to the Class List.
On the Filters panel, switch to the Filter by Object Type tab and select Objects that implement.
Click Add class / interface, then choose the appropriate graphics class for your application type:
- For WinForms applications, choose System.Image.
- For WPF applications, choose System.Windows.Media.Imaging.BitmapImage.
Switch to the Instance List and sort it by Distance from GC Root.
Look at the instances which are furthest from the GC Root. This is because leaked images are likely to be further from the root.
Use the instance retention graph to work out why each image is still in memory; see The Instance Retention Graph.
If you do not see the cause of the memory problem, and if your application is a WinForms application, repeat the steps above using Objects that implement System.Windows.Media.Imaging.CachedBitmap.
If the objects that implement System.Windows.Media.Imaging.CachedBitmap filter does not show the cause of the memory problem, repeat the steps again using Objects that implement System.Windows.Media.ImageSource.

We recommend that you do not use the instance categorizer for this investigation, because the categorization will tend to emphasize large numbers of small images. It may not show small numbers of large images.

Note that in the Instance List all images will appear to be the same very small size (24 bytes in the case of System.Image objects). This is actually only the amount of managed memory used to create the pointer to the image. The image itself is in unmanaged memory, and so ANTS Memory Profiler cannot show its size.

Was this article helpful?

Search support