So there is a common issue that people run across when they start trying to debug managed code. How does the heap compare to the current threads that are running?
For example, here is an exception that we have found in the managed heap running !dumpheap –stat:
But if we try to search for this exception on our callstacks using !gcroot, all we see is:
0:066> !gcroot 11c11a44 Note: Roots found on stacks may be false positives. Run "!help gcroot" for more info. Scan Thread 18 OSThread be4 Scan Thread 24 OSThread 2e0 Scan Thread 25 OSThread 358 Scan Thread 26 OSThread fc Scan Thread 27 OSThread 5c4 Scan Thread 28 OSThread c84 Scan Thread 13 OSThread dd4 Scan Thread 15 OSThread b80 Scan Thread 17 OSThread d84 Scan Thread 16 OSThread 724 Scan Thread 8 OSThread 624 Scan Thread 7 OSThread ef4 Scan Thread 6 OSThread db0 Scan Thread 9 OSThread 5e4 Scan Thread 29 OSThread 6b0 Scan Thread 30 OSThread 8b4 Scan Thread 31 OSThread 260 Scan Thread 32 OSThread 1a4 Scan Thread 33 OSThread 420 Scan Thread 34 OSThread 900 Scan Thread 35 OSThread ef8 Scan Thread 36 OSThread eb0 Scan Thread 37 OSThread f90 Scan Thread 38 OSThread f8c Scan Thread 39 OSThread df0 Scan Thread 40 OSThread de0 Scan Thread 41 OSThread bc0 Scan Thread 42 OSThread 710 Scan Thread 43 OSThread 87c Scan Thread 44 OSThread 5c8 Scan Thread 45 OSThread 638 Scan Thread 46 OSThread 550 Scan Thread 47 OSThread 73c Scan Thread 48 OSThread e4 Scan Thread 49 OSThread ba4 Scan Thread 50 OSThread 504 Scan Thread 51 OSThread 8bc Scan Thread 52 OSThread c08 Scan Thread 53 OSThread ac4 Scan Thread 54 OSThread e88 Scan Thread 55 OSThread e00 Scan Thread 56 OSThread 8f4 Scan Thread 57 OSThread c68 Scan Thread 58 OSThread fb0 Scan Thread 59 OSThread f50 Scan Thread 60 OSThread 36c Scan Thread 61 OSThread 378 Scan Thread 62 OSThread d64 Scan Thread 63 OSThread 690 Scan Thread 64 OSThread 90c Scan Thread 65 OSThread dd0
So this object is not on a thread or referenced in any global. Why are we seeing it in the heap?
The answer is that it was on a thread, but that thread has since completed executing, but the GC (Garbage Collector) hasn’t run yet to clean up this object. So the object will remain in the managed heap until the GC runs the next time. The GC can run against the different generations, so if it runs against the generation that contains this Exception object, then it will be cleaned up and removed from the heap. You can look here for more information on the generations of the managed heap.
Keep checking the RECAP- ASP.NET Blog Chat to see other topics that Tess or I write about.