title: handle leaks with .net 4.0 system
body: <p>I am using windows 2003 R2 and windows 2008 R2 with .NET framework 4.0 (64bit).</p>
  
  <p>I have an OLTP windows service which listens for messages on a socket and create threads for processing each message. The application is expected to process up to 200 transactions per second but the load varies from time to time(average of around 80 TPS per day). 
  The problem we are facing is that for some reason, the application is creating Handles and not getting rid of them. I have used the ProcessExplorer tool to see that the Handles that are increasing are the Event Handles and all other types of Handles are being released regularly. When this happens, after a day or two of execution the handle count increases too much and my application is getting crashed with OutOfMemory Exception.</p>
  
  <p>I have also verified using the ProcessExplorer that all Event Handles that are not getting released do have at least one reference. By my problem is that I have no control over them as my program do not create any Handles explicitly. My natural doubt was on CLR and upon investigation I found the <a href="https://connect.microsoft.com/VisualStudio/feedback/details/430646/thread-handle-leak#tabs" rel="nofollow noreferrer">https://connect.microsoft.com/VisualStudio/feedback/details/430646/thread-handle-leak#tabs</a>
  Quote:” 
  Posted by Microsoft on 4/8/2009 at 12:39 PM</p>
  
  <p><strong>Thank you for the feedback. I am the threading developer on the Common Language Runtime (CLR) team. The problem you report is a known issue in the CLR, and we are working to fix it in a future release. The problem is that CLR thread handles (and other associated data structures) are cleaned up by the finalizer thread, which normally only runs in response to a garbage collection (GC). If many threads are created and destroyed before a GC occurs (which would be the case if there were few memory allocations in the meantime) then it has the effect of "leaking" handles and memory, althgough these will be reclaimed the next time finalization is triggered. A workaround is to periodically manually trigger finalization, through calls to GC.WaitForPendingFinalizers. As I said, we are working to correct this in a future CLR release.</strong></p>
  
  <p>Posted by <strong><em>Ed Nicholas on 4/7/2009 at 8:20 AM”</em></strong>
  On the same page, Microsoft has marked this issue as fixed, but I see no reference to which version of the CLR contains the fix.</p>
  
  <p>I have already reviewed following threads/links.</p>
  
  <p><a href="https://stackoverflow.com/questions/2895821/handle-leaks-with-net-system-threading-thread-class">Handle leaks with .NET System.Threading.Thread class</a></p>
  
  <p><a href="https://connect.microsoft.com/VisualStudio/feedback/details/430646/thread-handle-leak#" rel="nofollow noreferrer">https://connect.microsoft.com/VisualStudio/feedback/details/430646/thread-handle-leak#</a></p>
  
  <p>Can anyone suggests a workable solution? Thanks in advance.</p>
  
  <p>Wajid Hussain</p>