基於WinDbg的記憶體洩漏分析
阿新 • • 發佈：2018-12-27
在前面C++中基於Crt的記憶體洩漏檢測一文中提到的方法已經可以解決我們的大部分記憶體洩露問題了，但是該方法是有前提的，那就是一定要有原始碼，而且還只能是Debug版本除錯模式下。實際上很多時候我們的程式會用到第三方沒有原始碼的模組，有些情況下我們甚至懷疑係統模組有記憶體洩露，但是有沒有證據，我們該怎麼辦？ 這時我們就要依靠無所不能的WinDbg了。
WinDbg的!heap命令非常強大，結合AppVerifier可以對堆(heap)記憶體進行詳細的跟蹤和分析， 我們接下來對下面的程式碼進行記憶體洩漏的分析：
// MemLeakTest.cpp : Defines the entry point for the console application.
#include "stdafx.h"
#include <Windows.h>
#include <stdio.h>
int _tmain(int argc, _TCHAR* argv[])
{
char* p1 = new char;
printf("%p\n", p1);
char* pLargeMem = new char[40000];
for(int i=0; i<1000; ++i)
{
char* p = new char[20];
}
system("pause");
return 0;
}
首先下載安裝AppVerifier， 可到
注: 我們這裡用AppVerifier主要是為了開啟頁堆(page heap)除錯功能，你也可以用系統工具 gflags.exe 來做同樣的事。
雙擊執行我們要除錯的MemLeakTest.exe, 效果如下：
然後將WinDbg Attach上去， 輸入命令 !heap -p -a 0x02FC1FF8，結果如下：
0:001> !heap -p -a 0x02FC1FF8
address 02fc1ff8 found in
_DPH_HEAP_ROOT @ 2f01000
in busy allocation ( DPH_HEAP_BLOCK: UserAddr UserSize - VirtAddr VirtSize)
2f02548: 2fc1ff8 1 - 2fc1000 2000
5a8c8e89 verifier!AVrfDebugPageHeapAllocate+0x00000229
77485c4e ntdll!RtlDebugAllocateHeap+0x00000030
77447e5e ntdll!RtlpAllocateHeap+0x000000c4
774134df ntdll!RtlAllocateHeap+0x0000023a
5b06a65d vrfcore!VfCoreRtlAllocateHeap+0x00000016
5a92f9ea vfbasics!AVrfpRtlAllocateHeap+0x000000e2
72893db8 MSVCR90!malloc+0x00000079
72893eb8 MSVCR90!operator new+0x0000001f
012c1008 MemLeakTest!wmain+0x00000008 [f:\test\memleaktest\memleaktest\memleaktest.cpp @ 11]
77331114 kernel32!BaseThreadInitThunk+0x0000000e
7741b429 ntdll!__RtlUserThreadStart+0x00000070
7741b3fc ntdll!_RtlUserThreadStart+0x0000001b怎麼樣， 神奇吧？我們當分配該地址記憶體時的堆疊(stack)被完整地列印了出來。
當然有人很快會說：這是你知道記憶體地址的情況， 很多情況下我們是不知道該地址的，該如何分析？
對於這種情況， 我們首先需要明確一些概念， 我們new出來的記憶體是分配在堆上， 那一個程序裡究竟有多少個堆， 每個模組都有自己單獨的堆嗎？實際上一個程序可以有任意多個堆，我們可以通過CreateHeap建立自己單獨的堆， 然後通過HeapAlloc分配記憶體。 我們new出來的記憶體是crt(C執行庫)分配的， 那就涉及到crt究竟有多少個堆了？ crt有多少個堆由你編譯每個模組(Dll/Exe)時的編譯選項決定， 如果你執行庫選項用的是/MD, 那就和其他模組共享一個堆; 如果用/MT， 那就是自己單獨的堆。大部分情況下我們會用/MD，這樣我們在一個模組裡new記憶體, 另一個模組裡delete不會有問題， 因為大家共享一個堆。
明確這些概念之後， 我們看看我們的測試程式有多少個堆， 輸入!heap -p
0:001> !heap -p
Active GlobalFlag bits:
vrf - Enable application verifier
hpa - Place heap allocations at ends of pages
StackTraceDataBase @ 00160000 of size 01000000 with 00000034 traces
PageHeap enabled with options:
ENABLE_PAGE_HEAP
COLLECT_STACK_TRACES
active heaps:
+ 1160000
ENABLE_PAGE_HEAP COLLECT_STACK_TRACES
NormalHeap - 1300000
HEAP_GROWABLE
+ 1400000
ENABLE_PAGE_HEAP COLLECT_STACK_TRACES
NormalHeap - 16b0000
HEAP_GROWABLE HEAP_CLASS_1
+ 2360000
ENABLE_PAGE_HEAP COLLECT_STACK_TRACES
NormalHeap - 1280000
HEAP_GROWABLE HEAP_CLASS_1
+ 2f00000
ENABLE_PAGE_HEAP COLLECT_STACK_TRACES
NormalHeap - 31d0000
HEAP_GROWABLE HEAP_CLASS_1 可以看到我們的測試程式一共有4 個堆。
接下來我們的問題就是確定哪個是我們的crt堆， 也就是我們需要分析每個堆建立時的堆疊(stack)情況.
我們接下來分析最後一個堆， handle是2f00000， 輸入!heap -p -h 02f00000 分析該堆的記憶體分配情況
0:001> !heap -p -h 02f00000
_DPH_HEAP_ROOT @ 2f01000
Freed and decommitted blocks
DPH_HEAP_BLOCK : VirtAddr VirtSize
02f01f04 : 02f09000 00002000
02f02e38 : 02f69000 00002000
037e2548 : 03892000 00002000
037e2514 : 03894000 00002000
Busy allocations
DPH_HEAP_BLOCK : UserAddr UserSize - VirtAddr VirtSize
02f01f6c : 02f05de8 00000214 - 02f05000 00002000
02f01f38 : 02f07800 00000800 - 02f07000 00002000
02f01ed0 : 02f0bde0 00000220 - 02f0b000 00002000
02f01e9c : 02f0df50 000000ac - 02f0d000 00002000
02f01e68 : 02f0ffe0 0000001f - 02f0f000 00002000
02f01e34 : 02f11fd8 00000028 - 02f11000 00002000
02f01e00 : 02f13fe0 0000001d - 02f13000 00002000
02f01dcc : 02f15fc0 0000003a - 02f15000 00002000
....可以看到該堆 _DPH_HEAP_ROOT 結構的地址是 2f01000，通過dt命令列印該結構地址
0:001> dt ntdll!_DPH_HEAP_ROOT CreateStackTrace 2f01000
+0x0b8 CreateStackTrace : 0x0017cbe4 _RTL_TRACE_BLOCK可以看到StackTrace的地址是 0x0017cbe4， 通過dds命令列印該地址內的符號
0:001> dds 0x0017cbe4
0017cbe4 00178714
0017cbe8 00007001
0017cbec 000f0000
0017cbf0 5a8c8969 verifier!AVrfDebugPageHeapCreate+0x439
0017cbf4 7743a9e8 ntdll!RtlCreateHeap+0x41
0017cbf8 5a930109 vfbasics!AVrfpRtlCreateHeap+0x56
0017cbfc 755fdda2 KERNELBASE!HeapCreate+0x55
0017cc00 72893a4a MSVCR90!_heap_init+0x1b
0017cc04 72852bb4 MSVCR90!__p__tzname+0x2a
0017cc08 72852d5e MSVCR90!_CRTDLL_INIT+0x1e
0017cc0c 5a8dc66d verifier!AVrfpStandardDllEntryPointRoutine+0x99
0017cc10 5b069164 vrfcore!VfCoreStandardDllEntryPointRoutine+0x121
0017cc14 5a92689c vfbasics!AVrfpStandardDllEntryPointRoutine+0x9f
0017cc18 7741af58 ntdll!LdrpCallInitRoutine+0x14
0017cc1c 7741fd6f ntdll!LdrpRunInitializeRoutines+0x26f
0017cc20 774290c6 ntdll!LdrpInitializeProcess+0x137e
0017cc24 77428fc8 ntdll!_LdrpInitialize+0x78
0017cc28 7741b2f9 ntdll!LdrInitializeThunk+0x10
0017cc2c 00000000
0017cc30 00009001現在我們可以看到該堆被Create時的完整堆疊了， 通過堆疊，我們可以看到該堆正是由crt建立的， 也就是說我們new的記憶體都分配在該堆內。
如果你覺得上面跟蹤堆建立的過程太複雜，可以先忽略， 下面我們分析堆狀態， 輸入!heap -stat -h 0，它會分析所有堆的當前使用狀態， 我們著重關注我們的crt堆02f00000：
Allocations statistics for
heap @ 02f00000
group-by: TOTSIZE max-display: 20
size #blocks total ( %) (percent of total busy bytes)
9c40 1 - 9c40 (52.66)
14 3ea - 4e48 (26.38)
1000 1 - 1000 (5.39)
800 2 - 1000 (5.39)
490 1 - 490 (1.54)
248 1 - 248 (0.77)
220 1 - 220 (0.72)
214 1 - 214 (0.70)
ac 2 - 158 (0.45)
82 2 - 104 (0.34)
6a 2 - d4 (0.28)
50 2 - a0 (0.21)
28 4 - a0 (0.21)
98 1 - 98 (0.20)
94 1 - 94 (0.19)
8a 1 - 8a (0.18)
2e 3 - 8a (0.18)
41 2 - 82 (0.17)
80 1 - 80 (0.17)
7c 1 - 7c (0.16)我們可以看到排在第一位的是大小為0x9c40 (0n40000)的記憶體，分配了1次， 第二位的是大小為 0x14 (0n20) 的記憶體，分配了3ea (0n1002)次.
回頭再看我們的測試程式，怎麼樣？ 是不是感覺很熟悉了。
輸入!heap -flt s 0x9c40， 讓WinDbg列出所有大小為0x9c40的記憶體：
0:001> !heap -flt s 0x9c40
_DPH_HEAP_ROOT @ 1161000
Freed and decommitted blocks
DPH_HEAP_BLOCK : VirtAddr VirtSize
Busy allocations
DPH_HEAP_BLOCK : UserAddr UserSize - VirtAddr VirtSize
_HEAP @ 1300000
_DPH_HEAP_ROOT @ 1401000
Freed and decommitted blocks
DPH_HEAP_BLOCK : VirtAddr VirtSize
Busy allocations
DPH_HEAP_BLOCK : UserAddr UserSize - VirtAddr VirtSize
_HEAP @ 16b0000
_DPH_HEAP_ROOT @ 2361000
Freed and decommitted blocks
DPH_HEAP_BLOCK : VirtAddr VirtSize
Busy allocations
DPH_HEAP_BLOCK : UserAddr UserSize - VirtAddr VirtSize
_HEAP @ 1280000
_DPH_HEAP_ROOT @ 2f01000
Freed and decommitted blocks
DPH_HEAP_BLOCK : VirtAddr VirtSize
Busy allocations
DPH_HEAP_BLOCK : UserAddr UserSize - VirtAddr VirtSize
02f024e0 : 02fc63c0 00009c40 - 02fc6000 0000b000
_HEAP @ 31d0000
可以看到， WinDbg幫我們找到了一個符合要求的分配， 它的UserAddr是02fc63c0， 該地址實際上就是程式碼char* pLargeMem = new char[40000]分配的地址， 按照開頭的方法， 輸入!heap -p -a 02fc63c0
0:001> !heap -p -a 02fc63c0
address 02fc63c0 found in
_DPH_HEAP_ROOT @ 2f01000
in busy allocation ( DPH_HEAP_BLOCK: UserAddr UserSize - VirtAddr VirtSize)
2f024e0: 2fc63c0 9c40 - 2fc6000 b000
5a8c8e89 verifier!AVrfDebugPageHeapAllocate+0x00000229
77485c4e ntdll!RtlDebugAllocateHeap+0x00000030
77447e5e ntdll!RtlpAllocateHeap+0x000000c4
774134df ntdll!RtlAllocateHeap+0x0000023a
5b06a65d vrfcore!VfCoreRtlAllocateHeap+0x00000016
5a92f9ea vfbasics!AVrfpRtlAllocateHeap+0x000000e2
72893db8 MSVCR90!malloc+0x00000079
72893eb8 MSVCR90!operator new+0x0000001f
012c101e MemLeakTest!wmain+0x0000001e [f:\test\memleaktest\memleaktest\memleaktest.cpp @ 13]
77331114 kernel32!BaseThreadInitThunk+0x0000000e
7741b429 ntdll!__RtlUserThreadStart+0x00000070
7741b3fc ntdll!_RtlUserThreadStart+0x0000001b
可以看到該堆疊就是我們new char[40000]的堆疊， 用同樣的方法， 我們可以分析出上面程式碼for迴圈中的1000次記憶體洩漏。
最後， 總結一下， 通過WinDbg結合AppVerifier， 我們可以詳細的跟蹤堆中new出來的每一塊記憶體。 很多時候在沒有原始碼的Release版本中，在程式執行一段時間後，如果我們發現有大塊記憶體或是大量同樣大小的小記憶體一直沒有釋放， 我們就可以用上面的方法進行分析。有些情況下，我們甚至可以將 _CrtDumpMemoryLeaks()和WinDbg的!heap -p -a [address]命令結合起來使用， 由前者列印洩漏地址，後者分析呼叫堆疊，以便快速的定位問題。
posted on 2013-02-27 14:35 Richard Wei 閱讀(14616) 評論(10) 編輯 收藏 引用 所屬分類: windbg
WinDbg的!heap命令非常強大，結合AppVerifier可以對堆(heap)記憶體進行詳細的跟蹤和分析， 我們接下來對下面的程式碼進行記憶體洩漏的分析：
// MemLeakTest.cpp : Defines the entry point for the console application.
#include "stdafx.h"
#include <Windows.h>
#include <stdio.h>
int _tmain(int argc, _TCHAR* argv[])
{
char* p1 = new char;
printf("%p\n", p1);
char* pLargeMem = new char[40000];
for(int i=0; i<1000; ++i)
{
char* p = new char[20];
}
system("pause");
return 0;
}
首先下載安裝AppVerifier， 可到
注: 我們這裡用AppVerifier主要是為了開啟頁堆(page heap)除錯功能，你也可以用系統工具 gflags.exe 來做同樣的事。
雙擊執行我們要除錯的MemLeakTest.exe, 效果如下：
然後將WinDbg Attach上去， 輸入命令 !heap -p -a 0x02FC1FF8，結果如下：
0:001> !heap -p -a 0x02FC1FF8
address 02fc1ff8 found in
_DPH_HEAP_ROOT @ 2f01000
in busy allocation ( DPH_HEAP_BLOCK: UserAddr UserSize - VirtAddr VirtSize)
2f02548: 2fc1ff8 1 - 2fc1000 2000
5a8c8e89 verifier!AVrfDebugPageHeapAllocate+0x00000229
77485c4e ntdll!RtlDebugAllocateHeap+0x00000030
77447e5e ntdll!RtlpAllocateHeap+0x000000c4
774134df ntdll!RtlAllocateHeap+0x0000023a
5b06a65d vrfcore!VfCoreRtlAllocateHeap+0x00000016
5a92f9ea vfbasics!AVrfpRtlAllocateHeap+0x000000e2
72893db8 MSVCR90!malloc+0x00000079
72893eb8 MSVCR90!operator new+0x0000001f
012c1008 MemLeakTest!wmain+0x00000008 [f:\test\memleaktest\memleaktest\memleaktest.cpp @ 11]
77331114 kernel32!BaseThreadInitThunk+0x0000000e
7741b429 ntdll!__RtlUserThreadStart+0x00000070
7741b3fc ntdll!_RtlUserThreadStart+0x0000001b怎麼樣， 神奇吧？我們當分配該地址記憶體時的堆疊(stack)被完整地列印了出來。
當然有人很快會說：這是你知道記憶體地址的情況， 很多情況下我們是不知道該地址的，該如何分析？
對於這種情況， 我們首先需要明確一些概念， 我們new出來的記憶體是分配在堆上， 那一個程序裡究竟有多少個堆， 每個模組都有自己單獨的堆嗎？實際上一個程序可以有任意多個堆，我們可以通過CreateHeap建立自己單獨的堆， 然後通過HeapAlloc分配記憶體。 我們new出來的記憶體是crt(C執行庫)分配的， 那就涉及到crt究竟有多少個堆了？ crt有多少個堆由你編譯每個模組(Dll/Exe)時的編譯選項決定， 如果你執行庫選項用的是/MD, 那就和其他模組共享一個堆; 如果用/MT， 那就是自己單獨的堆。大部分情況下我們會用/MD，這樣我們在一個模組裡new記憶體, 另一個模組裡delete不會有問題， 因為大家共享一個堆。
明確這些概念之後， 我們看看我們的測試程式有多少個堆， 輸入!heap -p
0:001> !heap -p
Active GlobalFlag bits:
vrf - Enable application verifier
hpa - Place heap allocations at ends of pages
StackTraceDataBase @ 00160000 of size 01000000 with 00000034 traces
PageHeap enabled with options:
ENABLE_PAGE_HEAP
COLLECT_STACK_TRACES
active heaps:
+ 1160000
ENABLE_PAGE_HEAP COLLECT_STACK_TRACES
NormalHeap - 1300000
HEAP_GROWABLE
+ 1400000
ENABLE_PAGE_HEAP COLLECT_STACK_TRACES
NormalHeap - 16b0000
HEAP_GROWABLE HEAP_CLASS_1
+ 2360000
ENABLE_PAGE_HEAP COLLECT_STACK_TRACES
NormalHeap - 1280000
HEAP_GROWABLE HEAP_CLASS_1
+ 2f00000
ENABLE_PAGE_HEAP COLLECT_STACK_TRACES
NormalHeap - 31d0000
HEAP_GROWABLE HEAP_CLASS_1 可以看到我們的測試程式一共有4 個堆。
接下來我們的問題就是確定哪個是我們的crt堆， 也就是我們需要分析每個堆建立時的堆疊(stack)情況.
我們接下來分析最後一個堆， handle是2f00000， 輸入!heap -p -h 02f00000 分析該堆的記憶體分配情況
0:001> !heap -p -h 02f00000
_DPH_HEAP_ROOT @ 2f01000
Freed and decommitted blocks
DPH_HEAP_BLOCK : VirtAddr VirtSize
02f01f04 : 02f09000 00002000
02f02e38 : 02f69000 00002000
037e2548 : 03892000 00002000
037e2514 : 03894000 00002000
Busy allocations
DPH_HEAP_BLOCK : UserAddr UserSize - VirtAddr VirtSize
02f01f6c : 02f05de8 00000214 - 02f05000 00002000
02f01f38 : 02f07800 00000800 - 02f07000 00002000
02f01ed0 : 02f0bde0 00000220 - 02f0b000 00002000
02f01e9c : 02f0df50 000000ac - 02f0d000 00002000
02f01e68 : 02f0ffe0 0000001f - 02f0f000 00002000
02f01e34 : 02f11fd8 00000028 - 02f11000 00002000
02f01e00 : 02f13fe0 0000001d - 02f13000 00002000
02f01dcc : 02f15fc0 0000003a - 02f15000 00002000
....可以看到該堆 _DPH_HEAP_ROOT 結構的地址是 2f01000，通過dt命令列印該結構地址
0:001> dt ntdll!_DPH_HEAP_ROOT CreateStackTrace 2f01000
+0x0b8 CreateStackTrace : 0x0017cbe4 _RTL_TRACE_BLOCK可以看到StackTrace的地址是 0x0017cbe4， 通過dds命令列印該地址內的符號
0:001> dds 0x0017cbe4
0017cbe4 00178714
0017cbe8 00007001
0017cbec 000f0000
0017cbf0 5a8c8969 verifier!AVrfDebugPageHeapCreate+0x439
0017cbf4 7743a9e8 ntdll!RtlCreateHeap+0x41
0017cbf8 5a930109 vfbasics!AVrfpRtlCreateHeap+0x56
0017cbfc 755fdda2 KERNELBASE!HeapCreate+0x55
0017cc00 72893a4a MSVCR90!_heap_init+0x1b
0017cc04 72852bb4 MSVCR90!__p__tzname+0x2a
0017cc08 72852d5e MSVCR90!_CRTDLL_INIT+0x1e
0017cc0c 5a8dc66d verifier!AVrfpStandardDllEntryPointRoutine+0x99
0017cc10 5b069164 vrfcore!VfCoreStandardDllEntryPointRoutine+0x121
0017cc14 5a92689c vfbasics!AVrfpStandardDllEntryPointRoutine+0x9f
0017cc18 7741af58 ntdll!LdrpCallInitRoutine+0x14
0017cc1c 7741fd6f ntdll!LdrpRunInitializeRoutines+0x26f
0017cc20 774290c6 ntdll!LdrpInitializeProcess+0x137e
0017cc24 77428fc8 ntdll!_LdrpInitialize+0x78
0017cc28 7741b2f9 ntdll!LdrInitializeThunk+0x10
0017cc2c 00000000
0017cc30 00009001現在我們可以看到該堆被Create時的完整堆疊了， 通過堆疊，我們可以看到該堆正是由crt建立的， 也就是說我們new的記憶體都分配在該堆內。
如果你覺得上面跟蹤堆建立的過程太複雜，可以先忽略， 下面我們分析堆狀態， 輸入!heap -stat -h 0，它會分析所有堆的當前使用狀態， 我們著重關注我們的crt堆02f00000：
Allocations statistics for
heap @ 02f00000
group-by: TOTSIZE max-display: 20
size #blocks total ( %) (percent of total busy bytes)
9c40 1 - 9c40 (52.66)
14 3ea - 4e48 (26.38)
1000 1 - 1000 (5.39)
800 2 - 1000 (5.39)
490 1 - 490 (1.54)
248 1 - 248 (0.77)
220 1 - 220 (0.72)
214 1 - 214 (0.70)
ac 2 - 158 (0.45)
82 2 - 104 (0.34)
6a 2 - d4 (0.28)
50 2 - a0 (0.21)
28 4 - a0 (0.21)
98 1 - 98 (0.20)
94 1 - 94 (0.19)
8a 1 - 8a (0.18)
2e 3 - 8a (0.18)
41 2 - 82 (0.17)
80 1 - 80 (0.17)
7c 1 - 7c (0.16)我們可以看到排在第一位的是大小為0x9c40 (0n40000)的記憶體，分配了1次， 第二位的是大小為 0x14 (0n20) 的記憶體，分配了3ea (0n1002)次.
回頭再看我們的測試程式，怎麼樣？ 是不是感覺很熟悉了。
輸入!heap -flt s 0x9c40， 讓WinDbg列出所有大小為0x9c40的記憶體：
0:001> !heap -flt s 0x9c40
_DPH_HEAP_ROOT @ 1161000
Freed and decommitted blocks
DPH_HEAP_BLOCK : VirtAddr VirtSize
Busy allocations
DPH_HEAP_BLOCK : UserAddr UserSize - VirtAddr VirtSize
_HEAP @ 1300000
_DPH_HEAP_ROOT @ 1401000
Freed and decommitted blocks
DPH_HEAP_BLOCK : VirtAddr VirtSize
Busy allocations
DPH_HEAP_BLOCK : UserAddr UserSize - VirtAddr VirtSize
_HEAP @ 16b0000
_DPH_HEAP_ROOT @ 2361000
Freed and decommitted blocks
DPH_HEAP_BLOCK : VirtAddr VirtSize
Busy allocations
DPH_HEAP_BLOCK : UserAddr UserSize - VirtAddr VirtSize
_HEAP @ 1280000
_DPH_HEAP_ROOT @ 2f01000
Freed and decommitted blocks
DPH_HEAP_BLOCK : VirtAddr VirtSize
Busy allocations
DPH_HEAP_BLOCK : UserAddr UserSize - VirtAddr VirtSize
02f024e0 : 02fc63c0 00009c40 - 02fc6000 0000b000
_HEAP @ 31d0000
可以看到， WinDbg幫我們找到了一個符合要求的分配， 它的UserAddr是02fc63c0， 該地址實際上就是程式碼char* pLargeMem = new char[40000]分配的地址， 按照開頭的方法， 輸入!heap -p -a 02fc63c0
0:001> !heap -p -a 02fc63c0
address 02fc63c0 found in
_DPH_HEAP_ROOT @ 2f01000
in busy allocation ( DPH_HEAP_BLOCK: UserAddr UserSize - VirtAddr VirtSize)
2f024e0: 2fc63c0 9c40 - 2fc6000 b000
5a8c8e89 verifier!AVrfDebugPageHeapAllocate+0x00000229
77485c4e ntdll!RtlDebugAllocateHeap+0x00000030
77447e5e ntdll!RtlpAllocateHeap+0x000000c4
774134df ntdll!RtlAllocateHeap+0x0000023a
5b06a65d vrfcore!VfCoreRtlAllocateHeap+0x00000016
5a92f9ea vfbasics!AVrfpRtlAllocateHeap+0x000000e2
72893db8 MSVCR90!malloc+0x00000079
72893eb8 MSVCR90!operator new+0x0000001f
012c101e MemLeakTest!wmain+0x0000001e [f:\test\memleaktest\memleaktest\memleaktest.cpp @ 13]
77331114 kernel32!BaseThreadInitThunk+0x0000000e
7741b429 ntdll!__RtlUserThreadStart+0x00000070
7741b3fc ntdll!_RtlUserThreadStart+0x0000001b
可以看到該堆疊就是我們new char[40000]的堆疊， 用同樣的方法， 我們可以分析出上面程式碼for迴圈中的1000次記憶體洩漏。
最後， 總結一下， 通過WinDbg結合AppVerifier， 我們可以詳細的跟蹤堆中new出來的每一塊記憶體。 很多時候在沒有原始碼的Release版本中，在程式執行一段時間後，如果我們發現有大塊記憶體或是大量同樣大小的小記憶體一直沒有釋放， 我們就可以用上面的方法進行分析。有些情況下，我們甚至可以將 _CrtDumpMemoryLeaks()和WinDbg的!heap -p -a [address]命令結合起來使用， 由前者列印洩漏地址，後者分析呼叫堆疊，以便快速的定位問題。
posted on 2013-02-27 14:35 Richard Wei 閱讀(14616) 評論(10) 編輯 收藏 引用 所屬分類: windbg