在前面一 文中提到的方法已经可以解决我们的大部分内存泄露问题了，但是该方法是有前提的，那就是一定要有源代码，而且还只能是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的检测列表中， 然后保存。
注: 我们这里用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 001787140017cbe8 000070010017cbec 000f00000017cbf0 5a8c8969 verifier!AVrfDebugPageHeapCreate+0x4390017cbf4 7743a9e8 ntdll!RtlCreateHeap+0x410017cbf8 5a930109 vfbasics!AVrfpRtlCreateHeap+0x560017cbfc 755fdda2 KERNELBASE!HeapCreate+0x550017cc00 72893a4a MSVCR90!_heap_init+0x1b0017cc04 72852bb4 MSVCR90!__p__tzname+0x2a0017cc08 72852d5e MSVCR90!_CRTDLL_INIT+0x1e0017cc0c 5a8dc66d verifier!AVrfpStandardDllEntryPointRoutine+0x990017cc10 5b069164 vrfcore!VfCoreStandardDllEntryPointRoutine+0x1210017cc14 5a92689c vfbasics!AVrfpStandardDllEntryPointRoutine+0x9f0017cc18 7741af58 ntdll!LdrpCallInitRoutine+0x140017cc1c 7741fd6f ntdll!LdrpRunInitializeRoutines+0x26f0017cc20 774290c6 ntdll!LdrpInitializeProcess+0x137e0017cc24 77428fc8 ntdll!_LdrpInitialize+0x780017cc28 7741b2f9 ntdll!LdrInitializeThunk+0x100017cc2c 000000000017cc30 00009001 现在我们可以看到该堆被Create时的完整堆栈了， 通过堆栈，我们可以看到该堆正是由crt创建的， 也就是说我们new的内存都分配在该堆内。如果你觉得上面跟踪堆创建的过程太复杂，可以先忽略， 下面我们分析堆状态， 输入!heap -stat -h 0，它会分析所有堆的当前使用状态， 我们着重关注我们的crt堆02f00000：
Allocations statistics for heap @ 02f00000group-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]命令结合起来使用， 由前者打印泄漏地址，后者分析调用堆栈，以便快速的定位问题。
原文 http://www.cppblog.com/weiym/archive/2013/02/27/198109.html