I have a memory dump. In this dump I have a heap with handle fd00000. This is an excerpt from the output of !heap -s fd00000 command:
0: Heap 0fd00000
Flags 00001002 - HEAP_GROWABLE
Reserved memory in segments 80192 (k)
Commited memory in segments 56540 (k)
Virtual bytes (correction for large UCR) 60592 (k)
Free space 3884 (k) (572 blocks)
External fragmentation 6% (572 free blocks)
Virtual address fragmentation 6% (69 uncommited ranges)
Virtual blocks 124 - total 0 KBytes
Lock contention 23
Segments 1
You see that it shows summary information as expected. But the ouptut of !heap -stat -h 0fd00000
shows the following:
heap @ 0fd00000
group-by: TOTSIZE max-display: 20
size #blocks total ( %) (percent of total busy bytes)
19fa40 7a - c614280 (93.96)
62d30 4 - 18b4c0 (0.73)
d49 13d - 107365 (0.49)
It is all hexadecimal, so from here I see that "total busy bytes" exceed 205 MBytes. So you see that !heap -s tells me that this heap has 80 MB/60 MB of Reserved/Virtual memory, while !heap -stat tells me that this heap occupies 205 MBytes. The descrepancy is so huge. How this is possible? When I run !heap -s I see multiple entries like this:
Virtual block: 293c0000 - 293c0000 (size 00000000)
Maybe this is the reason?
Some !heap switches are known to behave incorrectly when large allocations flow through the Heap Manager. The Heap Manager will forward large allocations directly to VirtualAlloc, and while some of the !heap commands know how to keep track of these allocations, other commands do not. You should also try updating your WinDbg version to the most recent Windows SDK, because the !heap commands are intimately tied to the Heap Manager's internal data structures, which change with Windows versions.
I recommend using VMMap in such situations to detect large allocation sources.