Question

My development team is using ASP.NET 3.5 / 4.0 right now, and our sites are running on IIS 7.5. Recently, we’ve been having problems (about once a week) that are causing Out of Memory exceptions to be thrown in our ASP.NET applications. The “Solution” is to restart the application pool on our website. I say “Solution” because it’s hardly a solution; it’s more of a bandage that’s just keeping our application pool running at a reasonable state. It seems to me that some application or many applications are leaking memory, which is building up over time and causing the out of memory exception. While I can set IIS to periodically restart the application pool, I’d rather know how I can detect the memory leaks in order to attempt the fix the program rather than keep applying band-aids. Are there any tools out there that can possibly detect and log memory leaks for ASP.NET applications?

Also, we really started seeing more of this problem when we switched to using Telerik’s RAD controls. Has anyone else had problems similar to this using these controls?

Thanks,

Aaron

Answer 1

I previously posted this guide in response to another question, but that question and my answer appear to have been deleted. It’s not for the faint of heart:

1. Install the Debugging Tools for Windows (Available as part of the Windows SDK) on the server

2. When the application has been running for a while, use adplus to capture a memory dump of the process (It’s useful to use something such as Process Explorer to find the correct process ID to dump):

   ADPLUS -hang -p <process id> -o .

3. This will create a directory containing the memory dump. You can now use windbg, and open the dump file (File -> Open Crash Dump…)

4. The joys of unmanaged code now appear. But you use something called Son of Strike, which understands .NET code, to see what objects are allocated. First you load SOS:

   .loadby sos mscorwks

And then you ask it to examine the managed heap:

!dumpheap -stat

This generally spews a ton of output, but there are two columns showing the number of instances and the amount of memory being consumed, by type. Some types you expect to see a lot of (e.g. String), but if, say, there are thousands of instances of one of your own types, you might be leaking these objects somehow. One that’s caught me in the past is hooking up an event handler in an object to a static event in the application – that event then has a live reference to every one of those objects.

I can never remember how most of this works, and generally refer to this cheat sheet for SOS

Tess Ferrandez has a good blog which sometimes covers .NET debugging using the unmanaged debuggers

---

E.g. a post from last May, detailing a potential problem if you use XmlSerializers with a non-default constructor.