New Silverlight SOS.DLL Commands: !HeapStat and !GCWhere

Another SOS.DLL command new in Silverlight is !HeapStat, featuring statistics on the sizes and available space in the various GC heaps and generations.  (Previously in this series: Basic steps with Silverlight SOS; The !AnalyzeOOM command.)

Because Silverlight applications run within a browser, there’s typically going to be a single GC heap because the browser’s CLR host uses workstation GC.  However, generations and the large object heap (LOH) are still of interest.

The following is the (edited) output of executing the !HeapStat command a couple of times in a Silverlight application that allocates memory once in a while:

0:017> !heapstat
Heap        Gen0       Gen1       Gen2      LOH
Heap0       106508     176432     12        18640

Free space:                                                 Heap0       12         39576      0         144

SOH: 13% LOH:  0%

0:012> !heapstat
Heap        Gen0       Gen1       Gen2      LOH
Heap0       2551768    8347676    15988516  8732248

Free space:                                                
Heap0       12         1094504    1770688   1616

SOH: 10% LOH:  0%

Some of this information is also available with Windows performance counters; however, if you’re looking at a crash dump, this is extremely valuable.

Before you panic in view of the very low amount of free space in gen2 and the LOH, note that their sizes can extend – they are capped by the available virtual memory in the process.  The !VMStat or !ProcInfo commands are more appropriate for reporting whether available memory is running low.

A somewhat related new command is !GCWhere, which provides information on the heap and generation to which a specific object belongs.  This information can be (somewhat tediously) extracted from the output of !EEHeap –gc, but !GCWhere makes the information much more readily available.

The following is the output of !GCWhere on two objects – the first one belongs in the LOH (and has its generation reported as gen3), and the second one belongs in gen0.  (Note that for invalid objects which still happen to fall within the GC heap’s memory range, the reported size will be 0.)

0:012> !gcwhere 0513b150
Address  Gen Heap segment  begin    allocated size
0513b150 3   0    049d0000 049d1000 05224e58  ...(96248)
0:012> !GCWhere 06aa8db8
Address  Gen Heap segment  begin    allocated size
06aa8db8 0   0    06270000 06271000 06cd5ff4  ...(8852)