Freigeben über

Chat Question: Why do we see an exception on the heap, but it isn’t on a stack?

  • Artikel

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:

MissingException

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.

kick it on DotNetKicks.com

Comments