Tracking down CLR memory leaks

CLR programs have memory leaks, just like unmanaged ones, but for a different reason. There are lots of opportunities to add your object to a list – the major example being enlisting for events. If the event source lives for the lifetime of the program, then any objects listening for that event will also last for the lifetime of the program. So if you accidentally leave an object enlisted on such an event, you have created a memory leak – much like forgetting to call delete after calling new in C++.

But what is far better about the CLR is that it can pretty much tell you exactly what is causing a leak, although the technique is only documented on a few blog posts here and there. Also, they seem to be written by people who prefer using windbg. But after some fooling around, I’ve made it work in Visual Studio, which is a lot more convenient.