We have a windows program that was written in C++ that has a memory leak. We collected a couple of dumps in order to determine where the leak is. My standard method of doing this is to use WinDbg using the
!heap -s on the two dumps to find out which heap is growing, then use !heap
-stat -h . The problem is that while I can see a specific heap growing, none of the allocations are growing when I run !heap -stat -h. Historically, this methodology has helped me find out where my memory is leaking, but now it seems to have failed me.Where do I go from here?
What I have tried:
Here is the output of the dump file from the first dump:
0:000> !heap -s
************************************************************************************************************************
NT HEAP STATS BELOW
************************************************************************************************************************
LFH Key : 0x7230554a
Termination on corruption : DISABLED
Heap Flags Reserv Commit Virt Free List UCR Virt Lock Fast
(k) (k) (k) (k) length blocks cont. heap
-----------------------------------------------------------------------------
005b0000 00000002 8284 5896 8176 137 148 5 6 b LFH
00830000 00001002 1188 204 1080 27 8 2 0 0 LFH
02bd0000 00001002 1188 128 1080 24 6 2 0 0 LFH
02b90000 00041002 60 4 60 0 1 1 0 0
03100000 00001002 1188 128 1080 22 6 2 0 0 LFH
05cc0000 00001003 60 8 60 6 1 1 0 N/A
05dc0000 00001003 1080 124 1080 77 24 2 0 N/A
05f10000 00001003 60 4 60 2 1 1 0 N/A
05ef0000 00001003 60 4 60 2 1 1 0 N/A
060b0000 00001003 60 4 60 2 1 1 0 N/A
062a0000 00001003 60 4 60 2 1 1 0 N/A
05d60000 00001003 60 4 60 2 1 1 0 N/A
06080000 00001003 60 4 60 2 1 1 0 N/A
05e70000 00001003 60 4 60 2 1 1 0 N/A
064a0000 00001003 60 4 60 2 1 1 0 N/A
05c90000 00001003 60 4 60 2 1 1 0 N/A
05c50000 00001003 60 4 60 2 1 1 0 N/A
-----------------------------------------------------------------------------
Here is the output of the second file:
0:000> !heap -s
************************************************************************************************************************
NT HEAP STATS BELOW
************************************************************************************************************************
LFH Key : 0x7230554a
Termination on corruption : DISABLED
Heap Flags Reserv Commit Virt Free List UCR Virt Lock Fast
(k) (k) (k) (k) length blocks cont. heap
-----------------------------------------------------------------------------
005b0000 00000002 81224 68308 81116 1676 474 9 6 15 LFH
00830000 00001002 1188 260 1080 34 6 2 0 0 LFH
02bd0000 00001002 1188 148 1080 28 6 2 0 0 LFH
02b90000 00041002 60 4 60 0 1 1 0 0
03100000 00001002 1188 148 1080 27 6 2 0 0 LFH
05cc0000 00001003 60 8 60 6 1 1 0 N/A
05dc0000 00001003 1080 124 1080 62 57 2 0 N/A
05f10000 00001003 60 4 60 2 1 1 0 N/A
05ef0000 00001003 60 4 60 2 1 1 0 N/A
060b0000 00001003 60 4 60 2 1 1 0 N/A
062a0000 00001003 60 4 60 2 1 1 0 N/A
05d60000 00001003 60 4 60 2 1 1 0 N/A
06080000 00001003 60 4 60 2 1 1 0 N/A
05e70000 00001003 60 4 60 2 1 1 0 N/A
064a0000 00001003 60 4 60 2 1 1 0 N/A
05c90000 00001003 60 4 60 2 1 1 0 N/A
05c50000 00001003 60 4 60 2 1 1 0 N/A
21430000 00001002 1188 80 1080 18 8 2 0 0 LFH
-----------------------------------------------------------------------------
As you can see, the heap at 005b0000 has grown quite a bit. Now, when I use
!heap -stat -h 005b0000 the first dump returns the following:
0:000> !heap -stat -h 005b0000
heap @ 005b0000
group-by: TOTSIZE max-display: 20
size #blocks total ( %) (percent of total busy bytes)
27c9 25 - 5c00d (24.26)
2680 11 - 28e80 (10.78)
17b0c 1 - 17b0c (6.25)
3bc 35 - c5ec (3.26)
c da5 - a3bc (2.70)
c4 ca - 9aa8 (2.55)
a0 e4 - 8e80 (2.35)
8000 1 - 8000 (2.11)
30 27f - 77d0 (1.97)
c80 9 - 7080 (1.85)
24 2d7 - 663c (1.68)
1000 5 - 5000 (1.32)
4e20 1 - 4e20 (1.29)
4a20 1 - 4a20 (1.22)
40 10d - 4340 (1.11)
1048 4 - 4120 (1.07)
208 20 - 4100 (1.07)
4040 1 - 4040 (1.06)
4000 1 - 4000 (1.05)
2000 2 - 4000 (1.05)
And this is from the second dump file:
0:000> !heap -stat -h 005b0000
heap @ 005b0000
group-by: TOTSIZE max-display: 20
size #blocks total ( %) (percent of total busy bytes)
27c9 25 - 5c00d (23.73)
2680 11 - 28e80 (10.55)
17b0c 1 - 17b0c (6.11)
3bc 32 - bab8 (3.01)
c e09 - a86c (2.71)
c4 ca - 9aa8 (2.49)
a0 e6 - 8fc0 (2.32)
8000 1 - 8000 (2.06)
30 283 - 7890 (1.94)
c80 9 - 7080 (1.81)
24 2d8 - 6660 (1.65)
40 153 - 54c0 (1.37)
1000 5 - 5000 (1.29)
4e20 1 - 4e20 (1.26)
4a20 1 - 4a20 (1.19)
1048 4 - 4120 (1.05)
4040 1 - 4040 (1.04)
4000 1 - 4000 (1.03)
2000 2 - 4000 (1.03)
208 1f - 3ef8 (1.02)