What could explain over 5,000,000 System.WeakReference instances on the managed heap?

Question

I have been running load tests against a production ASP.NET web application and am seeing a huge number of System.WeakReferences created on the heap. Within about 15 minutes under load managed heap memory has shot up to about 3GB and I have approximately 5,000,000 references to System.WeakReference. Performing a forced garbage collection of all generations does not release these references.

I have seen posts about the __ENCLIST helper class which if assemblies are compiled in debug can create WeakReferences to all objects which are created, at first I thought this was the problem, but have verified all deployed assemblies are built in release.

I have been using WinDbg to debug the process, here's the final few lines of !dumpheap -stat

000007fef788e0c0    39253     18510000 System.Collections.Hashtable+bucket[]

00000000021bf120    94336    151023192      Free

000007fef7887e98     5959    189838752 System.Char[]

000007fef7874390   517429    589750224 System.Object[]

000007fef78865a0  1531190   1230824112 System.String

000007fef787dab8 51723338   1655146816 System.WeakReference

As you can see about 1.5GB of memory has been consumed by these System.WeakReferences.

Does anyone have any idea what could be creating all these WeakReferences?

Answer 1

So it turns out I had a System.WeakReference leak due to dynamically creating large numbers of System.Diagnostics.TraceSwitch instances, internally TraceSource/TraceSwitch allocates a WeakReference to the new TraceSource/TraceSwitch and puts the WeakReference into a list. Although the WeakReference allows the TraceSource/TraceSwitch to be garbage collected, the WeakReference itself will never be freed resulting in a memory leak.

A little more info can be found here

http://msdn.microsoft.com/en-us/library/system.diagnostics.tracesource(VS.80).aspx