Is Your WPF Application Leaky? JustTrace Will Tell You!

In a previous post I talked about some great new features in the newest (2013 Q2) release of JustTrace. The new features are terrific and certainly contribute to make JustTrace an indispensable part of any .NET developer’s toolbox, but there are three features that are so cool that they are deserving of their own individual blog posts:

• The Disposed Object View
• The Potential Binding Leaks in WPF View
• The Bottlenecks View

I covered the Disposed Object View in the previous post in this series. I’ll be demonstrating the Bottlenecks View in the next post in this series. Today I’m going to show you how the Potential Binding Leaks in WPF View can help you writer better WPF applications.

Getting to Know WPF

WPF (Windows Presentation Framework) is Microsoft’s preferred stack for building desktop Windows applications in .NET. One of the most obvious benefits of using WPF over conventional WinForms is that it’s XAML & code-behind architecture enables developers and designers to work together to create applications that are well designed and very user friendly. Its use of vector based rendering makes the forms easier to work with in terms of layout and resizing and enables designers to create controls of visual aspects that just were not practical (or even possible) in the bitmapped WinForms world. But from an architectural point of view, this is not the most compelling reason to use WPF over its predecessor.

In most WinForms applications the logic that controlled the user interface and interacted with the rest of the applications was tightly bound the visual aspects of the user interface. In many cases this code was actually in the event handlers for the various controls on the form. This tight coupling of logic and presentation made the individual parts of the form inflexible and made unit testing difficult.

In WPF the XAML that is used to define the front end is decoupled for the code (C# or VB.NET) that defines the logical functionality and controls the interactions between the form and the rest of the application. This makes both sides more flexible and makes unit testing the logic for the form much easier. This new paradigm gave rise to a new architectural pattern; Model-View-ViewModel. The MVVM pattern simplifies the interaction between the XAML based front end and the code based code behind by providing data binding facilities for your form. An introduction to the MVVM pattern, including some examples can be found here.

While WPF and the MVVM patterns have been a great help to Windows developers, they are not immune to resource issues. Memory leaks can occur in WPF if you data-bind to a view that does not implement INotifyPropertyChanged, don’t have their binding mode set to OneTime and are not using Dependency Properties. What happens in this case is that the runtime will attempt to use the ValueChanged event, which in turn calls The AddValueChanged event on PropertyDescriptor. This in turn creates a strong reference to the binding target. Not necessarily a common situation, but troubling none the less. A more detailed discussion of this phenomenon can be found here.

Never Fear, JustTrace is Here!

On a large project, finding these WPF leaks can be difficult. In most cases developers don’t really know what they are looking for due to the fact that WPF uses reflection to access bound properties, which prevents these problems from being discovered by static code analysis tools. The good news is that one of the newest features of JustTrace is to find and report these leaks.

To demonstrate this, I asked my fellow Evangelist and WPF Ninja Carey Payette to throw together a quick application that has one of these leaks. The application Carey created is a small WPF application that displays a window (as shown in Figure 1) with two types of cars that I can select by clicking on either one:

Figure 1 – The leaky WPF form

The ViewModel for this application returns a list of cars that are then bound the elements of the form. The key is that this ViewModel does not implement INotifyPropertyChanged:

 1: public class ViewModel

 2:     {

 3:  private List<Car> _carList;

 4:  

 5:  public List<Car> CarList

 6:         {

 7:             get {

 8:                 Car car1 = new Car() { CarMake = "Volkswagen", CarModel = "Bug", CarImagePath=@"Images/Car1.jpg" };

 9:                 Car car2 = new Car() { CarMake = "Audi", CarModel = "Prototype", CarImagePath=@"Images/Car2.jpg" };

 10:                 _carList = new List<Car>();

 11:                 _carList.Add(car1);

 12:                 _carList.Add(car2);

 13:  return _carList; 

 14:             }

 15:             set { _carList = value; }

 16:         }

 17:     }

To use JustTrace to find this memory leak I’ll select “Memory Profiler” from the JustTrace toolbar in Visual Studio (as shown in Figure 2)

Figure 2 – Memory profiling has been selected

I run the application by either hitting Ctrl+F5 or selecting “Start Without Debugging” from the “Debug” menu. My application will start and JustTrace will start profiling the application. When the application window appears I will switch back and forth between the selected cars a few times, then go back to Visual Studio and in the JustTrace widow click the “Kill & Get” button (shown in Figure 3) to take a memory snapshot then close the application:

Figure 3 – The Kill & Get button takes a memory snapshot then ends the application

Once the application is closed JustTrace will display the snapshot summery for the last snapshot taken (showing in Figure 4)

Figure 4 – The JustTrace snapshot summery

To see if my WPF application has any leaks related to data binding I can click on the “Potential Binding Leaks in WPF” option under the “Analyses” group. This will show me a list of classes that could be leaking memory in my WPF application (shown in Figure 5):

Figure 5 – Potential data binding leaks in WPF

Sure enough it looks like our ViewModel has been identified as a potential leak. It’s interesting to note that the Car class has also been identified as a potential leak, which makes sense as it essentially acts as a view model in this case. I can eliminate these leaks by having each class (ViewModel and Car) implement INotifyPropertyChanged. You can see the results of these changes by profiling the application again and observing that there are no potential binding leaks found. (Figure 6)

Figure 6 – No potential binding leaks found

This is a relatively small application. There is only one form and the data being bound is very simple, thus the total leak is 52 bytes and probably not a significant source of resource issues. However, in even a more simple production application (especially one where the data to be bound is coming from a larger data store) those numbers could become huge and quickly represent a major memory issue.

Summary