I did a high volume test on a software product that was being release approx 1 year ago. That test was performed on a system configured with Win 2003 Enterprise Edition (original version, no sp or updates) running on a HP Blade, single CPU Opteron 2.4 , 4gb ram. The test was completed and the software passed.

Then this year we are required to re-validate the same software again. This time, the hardware and OS have been upgraded. OS: Windows 2003 R2 SP2, Hardware 4 dual core Xeon CPUs, 8GB ram.

The issue is that running the software again this year on the new hardware and OS causes the Handles Count shown in the task manager to grow to over 3 million. This is not the same behavior.

Question: What if any changes between win2003's original vs R2 SP2 versions might account for this type of behavior?

Tombaz

How did you resolve this problem?I have a similar problem that appears to be a Thread Handle leak issue in .NET or the operating system (Windows 2003 SP2)

I have a .NET application where I create Thread objects. The threads complete, the objects go out of scope and should be garbage collected. However, they never are garbage collected. I was able to resolve the problem by using the ThreadPool object instead. But,this seems to be a GC bug but I can't find any other information about it.

Ed

---

Ed

An object of the Thread class consume four operating system handles. The Thread class doesn't have a Dispose() method, there is no practical way to call it. Those handles need to be released by the finalizer. In very unusual circumstances, a program may allocate so little managed memory that the garbage collector only rarely runs. Common if it runs threads that only activate unmanaged code. Such a program will eventually consume a very large number of handles. Diagnose with Perfmon.exe.

The workaround is use a System.Threading.Timer and periodically call GC.Collect().

---

Hans Passant.

Thanks for your reply. One of the first things I tried was calling GC.Collect but it has no affect on the allocated thread handles. The number of thread handles was increasing at a rate of about 15,000 per day. I made a simple change to my code to using ThreadPool.QueueUserWorkItem and the problem went away (in that section of the code). I'm fairly certain this is an operating system or .NET error.

The ThreadPool is not ideal for all purposes and I'm struggling to get rid of all of the uses of the Thread object because the ThreadPool requires extra effort to use if you want to monitor the thread. With threads, you can simply try to Join the thread (with a timeout) and see if the thread has completed. With the ThreadPool, it looks like you have to create your own synchronization objects and pass them as part of a parameter object to the function being queued.

Regards,
Ed

---

Ed