heap leak: confused about !heap -stat result

Hi,

I have a x64 user mode program that consumes too much memory in heap. And I want to find out the root cause. The article here describes a nice way to do it.
http://www.codeproject.com/Articles/31382/Memory-Leak-Detection-Using-Windbg

Here is my problem. A “!heap -s” output confirms that the program indeed has a large heap (more than 600MB). But the following “!heap -stat -h 000000f6df7b0000” shows that the largest blocks only consumes 6401a0 bytes, 67% of the total (which means the total busy bytes are only 9MB).

Can someone explain why the largest memory occupation is only a fraction of total committed memory in the heap?

Detailed output below:

0:001> !heap -s

************************************************************************************************************************
NT HEAP STATS BELOW
************************************************************************************************************************
NtGlobalFlag enables following debugging aids for new heaps:
stack back traces
LFH Key : 0x5c04e58648294954
Termination on corruption : ENABLED
Heap Flags Reserv Commit Virt Free List UCR Virt Lock Fast
(k) (k) (k) (k) length blocks cont. heap

000000f6df7b0000 08000002 663988 655200 663884 456 71 45 1 0 LFH
000000f6ddd80000 08008000 64 4 64 2 1 1 0 0
000000f6df9e0000 08001002 164 64 60 1 4 1 0 0 LFH
000000f6e14e0000 08001002 1184 80 1080 19 5 2 0 0 LFH
000000f6e13c0000 08001002 164 28 60 0 2 1 0 0 LFH

0:001> !heap -stat -h 000000f6df7b0000
heap @ 000000f6df7b0000
group-by: TOTSIZE max-display: 20
size #blocks total ( %) (percent of total busy bytes)
c8034 8 - 6401a0 (66.98)
54 2322 - b8728 (7.72)
103 9ca - 9e75e (6.63)
5c 1539 - 7a07c (5.11)
ac 7fb - 55ca4 (3.59)
40 b2c - 2cb00 (1.87)
3c ac8 - 286e0 (1.69)
4c 479 - 153ec (0.89)
6334 3 - 1299c (0.78)
c334 1 - c334 (0.51)
100 c1 - c100 (0.50)
a534 1 - a534 (0.43)
44 137 - 529c (0.22)
30 195 - 4bf0 (0.20)
4a8 f - 45d8 (0.18)
4234 1 - 4234 (0.17)
1034 4 - 40d0 (0.17)
118 32 - 36b0 (0.14)
104c 3 - 30e4 (0.13)
9a0 5 - 3020 (0.13)

=======================
0:001> !heap -stat -h 000000f6df7b0000 -grp B
heap @ 000000f6df7b0000
group-by: BLOCKCOUNT max-display: 20
size #blocks total ( %) (percent of totalblocks)
54 2322 - b8728 (32.66)
5c 1539 - 7a07c (19.73)
40 b2c - 2cb00 (10.39)
3c ac8 - 286e0 (10.02)
103 9ca - 9e75e (9.10)
ac 7fb - 55ca4 (7.42)
4c 479 - 153ec (4.16)
30 195 - 4bf0 (1.47)
44 137 - 529c (1.13)
100 c1 - c100 (0.70)
50 58 - 1b80 (0.32)
20 41 - 820 (0.24)
118 32 - 36b0 (0.18)
74 24 - 1050 (0.13)
93 21 - 12f3 (0.12)
64 1e - bb8 (0.11)
94 16 - cb8 (0.08)
38 13 - 428 (0.07)
b4 11 - bf4 (0.06)
3e 11 - 41e (0.06)

I managed to use VC memory profiling to get the correct heap analysis.
It seems windbg is not entirely compatible with the codes developed by VC?