Paul Stovell says…

Update: this bug is no where near as bad as I first suspected. I am instead going to supercede this post with a post about event handlers.

Update: I have reported this bug to MSDN Connect here. If you are a WPF developer please vote, as I can virtually guarantee this will affect your applications at some point too

As a Windows Forms or Windows Presentation Foundation developer, it is important to be aware of how event handlers and the .NET garbage collector work. A very common scenario that lands developers in trouble is this:

 

In this scenario, some code in a Window is subscribing to an event on a static object instance. To be a little more generic, the Window represents an object with a “short lifecycle” (we new()‘ed it up, and we’ll stop using it), and the static object represents an object with a “long lifecycle” (longer than the Window).

The reason this can be problematic comes from the way event handlers work. When the Window subscribes to an event handler on the Static Object, the Static Object actually has a reference back to the Window:

If you are familiar with .NET garbage collection you’ll recognize the problem: since the “long-lived” or static object is still in scope (since it is “static”), the reference it keeps to the Window means that the Window will never be reclaimed by the garbage collector whilst the Window is still subscribed to the event.

This creates a problem - if you forget to unsubscribe your event handlers (-= in C#, or RemoveHandler in VB.NET), the memory used by expensive objects like Windows (and all of the controls and data they contain) may never be reclaimed while your application is running. We’ve seen cases where hundreds of MB have been wasted due to static event handlers alone.

Weak Event Handlers

If you’ve used .NET for some time you may have heard of the WeakReference class. The idea of a weak reference is that you can still reference the other object, but the garbage collector will ignore the reference when it is figuring out what memory to collect.

Weak references can be used in clever ways so that event handlers can be weak referenced too. The basic idea is to introduce a proxy object into the middle:

This trick breaks the chain so that your short-lived object (the Window) is not referenced by the long-lived object (our Static Object). The static object will still have a direct reference to the proxy object (our Weak Event Handler class), but this is a lightweight class so it’s not so bad. As part of the destructor of our Window, we can unsubscribe the event handler too, so that no memory is kept laying around.

Some good examples of how to implement weak references can be found here:

• CodeProject article by John Stewien
• Simulating Weak Delegates by Greg Schechter

Alternatively, if you are using WPF, you can make use of the new WeakEventManager class.

WPF Binding Bug

This brings me to the reason for my post. If you’re using WPF, you’re probably (at least, I hope) making use of the INotifyCollectionChanged interface, either directly or through the use of classes like the ObservableCollection<T>. This interface provides an event, named CollectionChanged, which allows the collection to tell the bound UI element that the items in the collection have changed.

Can you guess where this is going?

When you bind to an object implementing INotifyCollectionChanged, WPF automatically subscribes to the CollectionChanged event on the object. This means your collection has a reference back to your UI element - which has references to your Window, and so on.

So, if you happen to bind to a static or long-lived instance of a collection (a cache, for example), you’re in a lot of trouble.

I have uploaded a sample project - tested against .NET 3.0 and 3.5 - which reproduces the problem. I haven’t yet found a workaround (setting the DataContext/ItemSource properties to null when closing don’t seem to help), so my only suggestion so far would be to be very wary of binding to static objects or objects which will live longer than your Window

Download sample project (VS2008 format).

Filed under: WPF