Static EventHandler Memory Leaks in the Framework

Question

I'm in the process of troubleshooting some memory problems we're having in our .NET WinForms application. I'm using SciTech's .NET Memory Profiler as well as dotTrace and they all seem to be indicting root allocations by static event handlers in the .NET Framework controls. From google'ing around, I've found reports of this here and here but this appears to be reported on the v1.1 of the .NET Framework and fixes promised for 2.0. We're running on 2.0 and we're still seeing these problems. The top 25 memory offenders that I've found all point to these static event handlers and specifically SystemEvents.UserPreferenceChanged. This guy went to great lengths to find a way to unwind these handlers. I haven't tried this yet, but I did try the workaround mentioned in the Microsoft support ticket, and none of them worked for me.

I'm well aware of the leak potential of event handlers (especially long living static handlers), but this one is almost out of my control. Anyone have any experience with this?

Answer 1

For really deep memory leak problems in the CLR, I find the best tool is windbg. If you can get past the cryptic syntax it's an amazingly effective debugger and leak tracker. The downside is it's not very intuitive to use and there is a very steep learning curve.

The best way to learn windbg though is by doing. Here are a couple of articles that talk about using windbg to track down a leak.

• http://blogs.msdn.com/ricom/archive/2004/12/10/279612.aspx
• http://weblogs.asp.net/scottgu/archive/2006/02/02/437231.aspx

Answer 2

I don't know if WinDBG is going to help here. It sounds like this is truly a bug in the framework. Is there a way you can post a simple repro? If so, then I could dig into what the heck is going on and see if there is a workaround. Otherwise your better bet would be to open a ticket on Connect. They are pretty good about getting back to people.

If you did want to look into it with WinDBG, you could investigate what is going on the heap to see what is going on. Start looking at what the objects that are hanging around are being rooted by. My guess is that you'll see pretty much what you see in the profilers above. The tricky thing with WinDBG is it can tell you just about whatever you want - you have to know what questions you want answered going into it.