Memory Leak in WPF with No BitmapImages?

Memory profiling for .NET developers

Moderators: Luke Jefferson, StephenC, AndrewH, melvyn.harbour, james.billings, Laura Morley, dene.boulton

Memory Leak in WPF with No BitmapImages?

Postby Tim Trese » Thu Jan 27, 2011 1:33 am

[Moderator: new user here--please refer to appropriate forum.]

Prosecuting a memory leak on .NET 3.5 WPF desktop application using the Unity Composite Application architecture. Following tree of steps recommended in your "Overview: Checking for memory problems," I have determined that this is an unmanaged memory leak. However, when checking unmanaged memory usage due to graphics buffers, I am unable to find in the class list a class called System.Windows.Media.Imaging.BitmapImage as directed. Confirmed zero filters applied; it isn't in the class list.

A graphics buffer leak is a strong suspect, because the leak does not occur when the application is minimized, only when it is continuously displayed on screen. Is there some other class besides BitmapImage that might be an indicator?

Thanks in advance,
Tim
Tim Trese
 
Posts: 1
Joined: Thu Jan 27, 2011 1:14 am

Postby AndrewH » Thu Jan 27, 2011 3:36 pm

The memory profiler currently doesn't tie unmanaged blocks to managed objects, so debugging these issues can involve a certain amount of trial and error.

The main issue you'll encounter is that .NET objects that reference unmanaged objects will all show up as the same size, so you'll need to investigate how they're used in the program to determine if they're a possible cause of the issue that you're seeing. You'll need to investigate objects by instance count rather than size - in particular, if memory usage is increasing, it's likely to be related to the objects which are increasing in instance count over time. We're investigating improving this situation for future versions of the profiler.

You're probably on the right track looking for bitmap images, I'd suggest also looking for the System.Windows.Media.Imaging.CachedBitmap class (which is often used by WPF), and perhaps also using the 'Objects that implement' filter to look for everything that implements System.Windows.Media.ImageSource to find all the different types of image that your application is creating.

If there's still nothing that looks particularly amiss, you'll need to broaden your search: a new technique that we've added to version 7 of the profiler may help a lot. Take two snapshots before and after memory has grown and use the 'survivors in growing class' filter, then sort by the 'instance diff' column in the class list. With this filter applied, this column will be showing you the number of objects in each class that have been garbage collected between snapshots (with shrinking or static long-lived objects filtered out). Classes with a difference of 0 are very good candidates to be leaking, and may be worth investigating.

At this point the instance categorizer can be useful for finding the objects that are problematic: something that may be useful is to switch between the 'survivors in growing classes' filter (which will show why old instances of that class are remaining in memory) and the 'new objects' filter (which will show why new instances are causing memory usage to grow).
Andrew Hunter
Software Developer
Red Gate Software Ltd.
AndrewH
 
Posts: 134
Joined: Thu Aug 17, 2006 3:44 pm


Return to ANTS Memory Profiler 7

Who is online

Users browsing this forum: No registered users and 0 guests