Memory Leaks Which are Still Present in WPF 4

Question

I was planning on building a WPF MVVM business application framework and I came across many articles when doing research that talk about memory leaks in the WPF platform.

A memory leak may occur when you use data binding in Windows Presentation Foundation
Avoiding a WPF memory leak with DataBinding (Black Magic)
Serious Memory Leaks Plague WPF
Top 5 Memory leaks in WPF and Silverlight
WPF Binding Bug leads to possible Memory Issues

But most of them date back to 2007 and 2008 so I was wondering which of them has been solved and which not.

In other words, what are the possible sources of memory leaks (that might happen) to account for when building my framework or to watch for in general (WPF 4.0, .NET 4.0) ?

Edit: I will try to be more specific. Can i take advantage of the WeakEventManager and its subclasses to listen for events without having to develop my own solution ?

Edit 2: Even more specific. Can i use the WeakEventManager to solve the problem of memory leak caused by events in .NET in general and not just WPF ?. If so why is it part of a WPF namespace and not a general .NET namespace ?

Answer 1

First that comes to my mind:

• System.Windows.Interactivity.Behavior from System.Windows.Interactivity.dll: a behavior might not detach when you expect it to and vice versa, leaving added event handler on the control to survive gc
• Just by your description I´m pretty sure you´ll be using third-party-components in the future, we found this to be a first-class candidate for leaks

The fact that you are considering this before starting is a plus, invest in a good MemoryProfiler and profile your app right from the start on a regular basis and you´ll be fine.

Edit: To comment on your edits: Checking through your links I think you can Isolate three main Topics:

• Implementing INotifyPropertyChanged is a must. Your first developer telling you "ist only a static view, data is not going to change on my model, i just skipped INPC" has to be drawn and quartered in public. Even better, your framework should enforce implementing this interface, or at least make it easy as possible for developers to use it.
• Dont bind to PropertyDescriptors, which might not be obvious in the first place but again your Framework might set a path for developers using it only to bind to custom viewmodel properties.
• Always unregister your eventhandler, which in my opinion is more a question of code hygiene

As to your edit concerning weak events, yes this might work. Personally i wouldn´t consider this good practice as it might lead to situations where your model exposing the events you are registering to is cleaned up earlier than you expect it. I´d suggest to walk the extra mile and consciously unregister your handler.