To be 100% sure what the problem is, crack out windbg with the SOS extension for .Net. You can use ADPlus to take a memory dump of the .Net process in question, and then load the dump file into windbg. The SOS debugger extension is used for debugging .Net memory dumps. Using !dumpheap -stat will show you all instances of objects on the heap. Given an instance handle, using !gcroot will tell you which thread is keeping the instance alive. Using !clrstack for that thread will show you the stack for that thread, pin pointing the exact code. These commands are only the tip of the iceberg though, check out Tess Fernandez's blog at http://blogs.msdn.com/b/tess/[^] for help on using windbg for memory leak debugging in .Net.