Last week I was asked to look at one of our web apps that kept running out of memory. We could see that it was the gen2 heap kept growing continuously but we had no idea why.
As I was researching this (googling) I ran across windbg, which I remembered from years ago, and was used for user-mode and kernel-mode debugging. But, now Microsoft has released a windbg extension to allow debugging of managed application, called SOS.dll (Son of Strike). This allows you to do things like look at the app domains, see which assemblies are loaded, look at the managed heap sizes, see what's on the heaps and to see what holds references to that object.
So, we put the app under stress, generated a memory dump, and fired up Windbg. First we looked at what was on the heap, and we saw a bunch of strings that looked like view state data. So we used the !gcroot command to see why the objects were not being gc'd. Turns out it was being held by a reference from an event. From Windbg, we got the specific class that was holding the reference.
Then we went to that class and saw that we had a static event that we were wiring up to a handler, but never removing it. Since the event was static, the event handler list kept the references and just kept growing. We added 1 line to remove the event handler when done, and our memory issue was fixed.
Since then I've been learning more about windbg and what it can do. It really is a powerful tool, and lets you really get under the covers of the clr.
http://msdn2.microsoft.com/en-us/magazine/cc164138.aspx
Labels: Development
