Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News Serious Memory Leaks Plague WPF

Serious Memory Leaks Plague WPF

This item in japanese

WPF, also known as Windows Presentation Foundation, represents the future of UI on the Windows platform. And if Microsoft has its way, its younger sibling Silerlight will take over the web and mobile markets. But like any new technology, it has some issues to work through including some rather serious memory leaks.

There are many memory leaks to discuss, so bare with us. The first one has been known for a while, but its cause is non-obvious to most developers, even ones reasonably familiar with WPF. The conditions needed to cause it follow:

  1. A data-binding path refers to property P of object X.
  2. Object X contains a direct reference or an indirect reference to the target of the data-binding operation.
  3. Property P is accessed through a PropertyDescriptor object instead of a DependencyProperty object or a PropertyInfo object.

This issue is described in detail in KB 938416.

Next up is a nasty bug that is triggered when you replace one data-bound collection with another. Ayende Rahien has a block of code that reproduces the issue. For an explanation, we turn to Mike Brown:

Digging in I discovered that the Binding System doesn't deregister the listener for the "Name" property when you notify that Data has changed.

It's definitely a bug and it has to do with the way the binding system looks at the binding in question. When you notify that Data has changed, rather than deregistering the existing bindings further down the tree (in this case the Name binding on your Textblock) and reusing the elements it appears that an entirely new set of elements are created. Unfortunately, the Textblock never gets the opportunity to deregister its binding.

Now if you made Data an observable collection (necessitates making your anonymous type into a full class) and made the collection raise a CollectionChanged event (e.g. Data[0]=Data[0]), everything works just fine.

This next group of memory leaks come to us from a Microsoft blogger going by the handle jgoldb.

  • CMilChannel leaks if initial HWND is destroyed on XP.
  • ShutdownListener leaked for each thread using Binding
  • Create and Destroy WriteableBitmap on XP in HW
  • SW Viewport 3D w/ VisualBrush, WB, etc. leaks on XP

In addition to these leaks, he lists some other common developer mistakes that lead to memory leaks as well as some past WPF issues that have been since corrected.

Rate this Article