.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

Leaving database connections open.

Answer 2

Failure to implement Dispose and so not disposing child objects.

Answer 3

Impersonation token handles left open.

Answer 4

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

Answer 5

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 6

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 7

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 8

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 9

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 10

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 11

Not using Using.

Answer 12

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 13

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).

Answer 14

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 15

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 16

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