Find resource leakage in Windbg

Reference: http://hi.baidu.com/xingxing/item/f834ffeae93fcf2d5b7cfb9a

 

After a program has been running for a period of time, the memory usage increases linearly and remains unchanged.

Debug windbg dynamically to determine the cause.

First, check the initial heap status:

 

0: 007>! Heap-s

NtGlobalFlag enables following debugging aids for new heaps:

Stack back traces

LFH Key: 0x34d21697

Termination on Termination uption: DISABLED

Heap Flags Reserv Commit Virt Free List UCR Virt Lock Fast

(K) length blocks cont. heap

-----------------------------------------------------------------------------

0023000008000002 1024 544 1024 17 14 1 0 0 LFH

00010000 08008000 64 4 64 2 1 0 0

01a30000 08001002 1088 80 1088 4 3 2 0 0 LFH

02d10000 08001002 1088 932 98 38 2 0 0 LFH

02ca0000 08001002 256 60 256 1 4 1 0 0 LFH

02f10000 08001002 256 172 256 3 1 0 0

04340000 08001002 64 4 64 2 1 0 0

02e60000 08001002 64 4 64 2 1 1 0 0

044c0000 08011002 256 4 256 1 2 1 0 0

04690000 08001002 256 4 256 1 2 1 0 0

-----------------------------------------------------------------------------

0: 007> g

(504. c9c): Break instruction exception-code 80000003 (first chance)

Eax = 7ffd7000 ebx = 00000000 ecx = 00000000 edx = 7709f125 esi = 00000000 edi = 00000000

Eip = 770340f0 esp = 0317ff5c ebp = 0317ff88 iopl = 0 nv up ei pl zr na pe nc

Cs = 001b ss = 0023 ds = 0023 es = 0023 fs = 003b gs = 0000 efl = 00000246

Ntdll! DbgBreakPoint:

770340f0 cc int 3

After running for a short period of time, let's look at it again. Compared with the previous one, we found that a stack has grown significantly:

0: 007>! Heap-s

NtGlobalFlag enables following debugging aids for new heaps:

Stack back traces

LFH Key: 0x34d21697

Termination on Termination uption: DISABLED

Heap Flags Reserv Commit Virt Free List UCR Virt Lock Fast

(K) length blocks cont. heap

-----------------------------------------------------------------------------

0023000008000002 2048 1868 2048 17 17 2 0 0 LFH

00010000 08008000 64 4 64 2 1 0 0

01a30000 08001002 1088 80 1088 4 3 2 0 0 LFH

02d10000 08001002 1088 980 1088 40 2 0 0 LFH

02ca0000 08001002 256 60 256 1 4 1 0 0 LFH

02f10000 08001002 256 172 256 3 1 0 0

04340000 08001002 64 4 64 2 1 0 0

02e60000 08001002 64 4 64 2 1 1 0 0

044c0000 08011002 256 4 256 1 2 1 0 0

04690000 08001002 256 4 256 1 2 1 0 0

-----------------------------------------------------------------------------

Count the memory allocation in the heap and find that the memory allocation of 1000 bytes accounts for 86.97%, and the target is locked.

0: 007>! Heap-stat-h 00230000

Heap @ 00230000

Group-by: TOTSIZE max-display: 20

Size # blocks total (%) (percent of total busy bytes)

1000 158-158000 (86.97)

494 16-64b8 (1.59)

20 2fd-5fa0 (1.51)

34 161-47b4 (1.13)

3980 1 to 3980 (0.91)

D0 30-2700 (0.62)

1034, 2-2068 (0.51)

78 39-1ab8 (0.42)

C88 2-1910 (0.40)

10 131-1310 (0.30)

11f8 1-11f8 (0.28)

208 7-e38 (0.22)

248 6-db0 (0.22)

58 23-c08 (0.19)

400 3-c00 (0.19)

80 15-a80 (0.17)

A28 1-a28 (0.16)

960 1 to 960 (0.15)

928 1 to 928 (0.14)

22 39-792 (0.12)

Let's take a look at the heap applications:

0: 007>! Heap-flt s 1000

_ HEAP @ 230000

HEAP_ENTRY Size Prev Flags UserPtr UserSize-state

0027b810 0203 0000 [00] 0027b828 01000-(busy)

0027c900 0203 0203 [00] 0027c918 01000-(busy)

00285670 0203 0203 [00] 00285688 01000-(busy)

00286688 0203 0203 [00] 002866a0 01000-(busy)

002876a0 0203 0203 [00] 002876b8 01000-(busy)

002886b8 0203 0203 [00] 002886d0 01000-(busy)

002896d0 0203 0203 [00] 002896e8 01000-(busy)

0028a6e8 0203 0203 [00] 0028a700 01000-(busy)

0028bf10 0203 0203 [00] 0028bf28 01000-(busy)

0028cf28 0203 0203 [00] 0028cf40 01000-(busy)

0028df40 0203 0203 [00] 0028df58 01000-(busy)

....

....

....

 

 

_ HEAP @ 10000

_ HEAP @ 1a30000

_ HEAP @ 2d10000

_ HEAP @ 2ca0000

_ HEAP @ 2f10000

_ HEAP @ 4340000

_ HEAP @ 2e60000

_ HEAP @ 44c0000

_ HEAP @ 4690000

Just pick a few addresses and check the call Stack:

0: 007>! Heap-p-a 0303aec0

Address 0303aec0 found in

_ HEAP @ 230000

HEAP_ENTRY Size Prev Flags UserPtr UserSize-state

0303aec0 0221 0000 [00] 0303aed8 01000-(busy)

7707dd6c ntdll! RtlAllocateHeap + 0x00000274

7541f947 KERNELBASE! FindNextFileW + 0x00000090

...

...

771a3c45 kernel32! BaseThreadInitThunk + 0x0000000e

770637f5 ntdll! _ RtlUserThreadStart + 0x00000070

770637c8 ntdll! _ RtlUserThreadStart + 0x0000001b

Combined with the source code, it is determined that after FindNextFileW completes file traversal, FindClose is not called to close the handle, resulting in the resource not being released.

Before using the preceding Method for debugging, open the Create user mode stack trace database

 

0: 004>! Gflag + ust

Current NtGlobalFlag contents: 0x00001000

Ust-Create user mode stack trace database