4

I am using windows 2003 R2 and windows 2008 R2 with .NET framework 4.0 (64bit).

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.

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 https://connect.microsoft.com/VisualStudio/feedback/details/430646/thread-handle-leak#tabs Quote:” Posted by Microsoft on 4/8/2009 at 12:39 PM

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.

Posted by Ed Nicholas on 4/7/2009 at 8:20 AM” 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.

I have already reviewed following threads/links.

Handle leaks with .NET System.Threading.Thread class

https://connect.microsoft.com/VisualStudio/feedback/details/430646/thread-handle-leak#

Can anyone suggests a workable solution? Thanks in advance.

Wajid Hussain

Community
  • 1
  • 1
user3455219
  • 41
  • 2
  • Have you identified where the handles come from? I am inclined to say "fix your bug and dispose disposable objects when you are done, dude" - any object that creates a handle has to implement IDIsposable and it looks you forget to dispose those (and rely on the GC to clean up resssouces). A memory profiler should help you analyze the problem. – TomTom Mar 24 '14 at 11:57
  • The Thread class doesn't have a Dispose() method, even though it uses 5 handles. For a rather good reason, it would be terribly difficult to call. *Very* unlikely that this is the actual source of your handle leak, two days is *way* too long to explain it. Look for a deadlocked finalizer thread instead. – Hans Passant Mar 24 '14 at 12:02
  • 1
    Creating a new thread to process each message seems like a lot of overhead, especially when you're processing up to 200 transactions per second. Seems like you should instead have the messages queued to a `BlockingCollection` and have several persistent consumer threads that service the queue. That would prevent you from creating so many threads, and thus avoid the problem of leaked event handles. – Jim Mischel Mar 24 '14 at 15:25
  • I have verified that every time 5 handles increases when I created and called a new thread. My thread function completed its work and I have called Thread.abort() function but still handles does not released. – user3455219 Mar 25 '14 at 10:18
  • It seems that I have the same issue, but am still investigating. I disagree with MSFT, as my process is constantly increasing those outstanding handles. – Bruno Brant Feb 07 '15 at 18:49

1 Answers1

0

I have got a similar issue, and it turned out that it has something to do with the antivirus software installed. Try your software in safe mode and/or antivirus disabled. If that helps, you can solve the issue the way Jim Mischel suggests: elaborate your messages using queues and persistent threads. (To complain at the antivirus software provider could be another solution) I also recommend to read the comments to .Net Memory Leak when creating lots of threads

Janos
  • 165
  • 10