.NET Resource Leak Gotchas

Question

There are several ways that developers can get caught out by unintentional resource leaks in .NET. I thought it would be useful to gather them in one place.

Please add yours with one answer per item, so the best get voted up :)

Answer 1

Failure to remove Event Handlers.

Registering for an event should be paired with un-registering:

   this.myObject.MyEvent += new EventHandler(myObject_MyEvent);
   this.myObject.MyEvent -= new EventHandler(myObject_MyEvent);

There is an example of a system where this happened on CodeProject.

Answer 2

P/Invoking to unmanaged code, and not cleaning them up, or not implementing IDisposable to get them cleaned up.

Answer 3

Not using Using.

Answer 4

Leaving database connections open.

Answer 5

Failure to implement Dispose and so not disposing child objects.

Answer 6

WCF client objects do not perform like other IDisposable objects. The client of a WCF service must be aborted if the operation is in a faulted state or else it will keep the connection open. This is usually learned the hard way.

Answer 7

Pretty much everything when using the Office APIs. Since they are all COM objects, they must be disposed. You also have to keep a class reference to them if you want to use event handlers, otherwise they lose their reference. In a lot of cases, you even have to manually call the GC in order to clean up the objects

Answer 8

Using a WeakReference can lead to the subtle leak where the object held by the WeakReference is cleaned up because it has no strong references but the WeakReference itself is not because you keep a strong reference to it.

You can run into this if you have something like a List or Dictionary of WeakReferences which you never prune. You'll end up leaking WeakReference objects even after the target has been collected.

Answer 9

Easy memory leak: make a static field in a class of type List. Add items to List. They'll never get garbage collected, so unless you remember to manually remove your items when you're done with them, the memory is permenantly tied up.

Answer 10

Failure to call the 'Close' method on the System.Windows.Window object.

The only way to ensure that all managed resources for a System.Windows.Window object are garbage collected is to call the 'Close()' method on the Window object. Calling Dispose or setting the object reference to null will not destroy the object.

Answer 11

If you count managed memory as a "resource" - failing to unhook event handlers is a common source of memory leaks (and various other more serious bugs).

Answer 12

Static Lists, Dictionaries and collection based resources that are populated outside of start-up code.

This can happen if you have a Dictionary you use as a global cache instead of a proper LRU based cache.

Anything static requires a lot of extra caution!

Answer 13

WPF resource dictionary leaks. Some helpful links:

• WPF Memory Leak, the story of lazily hydrated resources
• DynamicResource\StaticResource cause memory leaks
• Memory leak problem with ResourceDictionary and MergedDictionaries

Answer 14

Misconfiguring Spring.NET to create multiple instances of something that should be a singleton.

Answer 15

Failed to call Dispose() on Timer

Answer 16

Impersonation token handles left open.

Answer 17

Failure to dispose any Drawing related objects (Graphics, Font, SolidBrush, Pen, etc.) on the .NET Compact Framework. This can cause some serious memory leaks when you don't want (mobile device = limited memory).