We recently completed some load tests and found a bug with the SqlConnection object in .NET 4.0. When reviewing the results of our load test we noticed that the handle count climbed up to 85,000 and never went down. After investigation we found the problem is with the SqlConnection object.
We contacted Microsoft about the issue and they confirmed this is a bug with .NET 4.0. Microsoft currently has no plans to create a .NET 4.0 patch for this bug. The bug is fixed for .NET 4.5.
Basically if an app/process uses a SqlConnection and is never under memory pressure the garbage collector will never run. This will cause the handles to continually rise. The handle count will rise even after we close and dispose the SQLConnection object. You can view the handle count in your task manager under the “Processes”. You may have to select to show the Handles column under the “View” menu option.
A work around is to periodically explicitly call System.GC.Collect. This is not a recommended action because this will block all threads when the garbage collection occurs.
The Microsoft assigned bug number: CLR bug 288562
Here is what Microsoft had to say about the issue:
“The problem is that the garbage collector is very slow to collect managed thread objects created by the thread pool. The thread pool is being utilized every few minutes by SqlConnection to check the status of the connection pool. The reason that the garbage collector is slow to collect them is that there is very little activity going on, and the garbage collector keys off of activity to decide when to collect.
A potential workaround is to manually call System.GC.Collect at some interval to force a collection. For example, I created a timer in the test program that ran System.GC.Collect every 5 seconds, and there was no handle growth.
This issue happened when the app is not under memory pressure, you would see this issue.
When the app comes under memory pressure, GC will be kicked in automatically and these leaked handles will be claimed back.
We fixed in 4.5. The workaround is to call GC once in a while to clean it up if the app is not memory pressure related.”
Again this bug only exists in .NET 4.0.
You can see additional info here:
Tip By: Author Revita