基於WinDbg的內存泄漏分析

在前面 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的檢測列表中， 然后保存。

注: 我們這里用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)

我們可以看到排在第一位的是大小為0x 9c40 (0n40000)的內存，分配了1次， 第二位的是大小為 0x 14 (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]命令結合起來使用， 由前者打印泄漏地址，后者分析調用堆棧，以便 快速的定位問題。