title: Debugging huge memory leak in application
body: <p>My application has just leaked 1.5GB of memory.  I guess since I don't have a ton of data available to me, I'm assuming that it's leaked the memory, but it could also just be holding onto it.</p>
  
  <p>I'm currently using perfmon to gather as much information as I can, to try to understand what could be causing the problem.  I don't have a whole lot of leads at this point, and was hoping to get more hints from people here.</p>
  
  <ol>
  <li><p>The first thing I can say is that I do not implement IDisposable in any of my classes.  However, I know I do not call Dispose on any of the GUI elements, like SolidColorBrush.  As my app isn't graphics-intensive by any means, I figure this can't be causing the problem.  However, I will add the necessary calls.</p></li>
  <li><p>I don't know if I'm using any other classes in the framework that implement IDisposable.  I read a post <a href="https://stackoverflow.com/questions/20386/memory-leaks-in-net">here on SO</a> about FxCop.  I installed and used it to analyze my assembly, but it seems to only check for my own classes' correct implementation of IDisposable.  Is there another tool that can tell me ALL classes that implement IDisposable?</p></li>
  <li><p>I'm currently using WF in my application, and WFs are constantly being launched and finished.  Perfmon shows that WFs are ending properly, and I am using the "using" keyword, which I understand deals with proper disposal for me.</p></li>
  <li><p>Is there a simple way to tell if the memory being "leaked" is from unmanaged or managed code?</p></li>
  <li><p>The app was using 77k+ handles at the time I got the OOM exception.</p></li>
  </ol>
  
  <p>Any tips on how to proceed next would be greatly appreciated.  I am planning on running the app again and monitoring the performance counters, and maybe stubbing out certain calls.  I can also run the simulation for comparison's sake, since in that mode it won't call into my C DLL.</p>