windbg調試HEAP

HEAP的概念

堆棧堆棧，在操作系統內存中有兩種存儲空間，一個是堆，一個是棧。堆主要用於存儲用戶動態分配的變量，而棧呢，則是存儲我們程序過程中的臨時變量。當然棧的作用遠不止用作存儲變量，但這不是我們這篇文章的討論內容。

堆（HEAP）的分配，使用，回收都是通過微軟的API來管理的，最常見的API是malloc和new。在往底層走一點呢，這兩個函數都會調用HeapAlloc（RtlAllocateHeap）。同樣的相關函數還有HeapFree用來釋放堆，HeapCreate用來創建自己的私有堆。下面是這些函數的調用鏈：

HeapCreate->RtlCreateHeap->ZwAllocateVirtualMemory (這裏會直接申請一大片內存,至於申請多大內存,由進程PEB結構中的字段覺得，HeapSegmentReserve字段指出要申請多大的虛擬內存，HeapSegmentCommit指明要提交多大內存，對虛擬內存的申請和提交概念不清楚的童鞋，請參見windows核心編程相關內容~)

HeapAlloc->RtlAllocateHeap（至於這裏申請的內存，由於HeapCreate已經申請了一大片內存，堆管理器這片內存中劃分一塊出來以滿足申請的需要。這一步申請操作是堆管理器自己維護的，僅當申請內存不夠的時候纔會再次調用ZwAllocateVirtualMemory ）

HeapFree->RtlFreeHeap （對於釋放的內存，堆管理器只是簡單的把這塊內存標誌位已釋放讓後加入到空閒列表中，僅當空閒的內存達到一定閥值的時候會調用ZwFreeVirtualMeMory ）

HeapDestroy->RtlDestroyHeap->ZwFreeVirtualMeMory （銷燬我們申請的堆）

如何找到我們的HEAP信息？

WINDBG觀察堆

源碼：

#include "windows.h"

int main()
{
	HANDLE heap_handle = HeapCreate( NULL , 0x1000 , 0x2000 ) ;

	char *buffer = (char*)HeapAlloc(heap_handle , NULL , 128) ;

	char *buffer1 = (char*)HeapAlloc(heap_handle , NULL , 121) ;

	HeapFree(heap_handle, 0 , buffer ) ;
	HeapFree(heap_handle, 0 , buffer1 ) ;

	HeapDestroy( heap_handle) ;
	return 0 ;
}

該源碼生成編譯生成heap.exe，然後用windbg調試這個程序，在main函數下斷，緊接着執行第五行語句，執行結果如下

0:000> p
eax=002e1ca0 ebx=00000000 ecx=6d29b6f0 edx=00000000 esi=00000001 edi=01033374
eip=01031012 esp=0022fe8c ebp=0022feac iopl=0         nv up ei pl nz na po nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000             efl=00000202
heap!main+0x12:
01031012 ff150c200301    call    dword ptr [heap!_imp__HeapCreate (0103200c)] ds:0023:0103200c={kernel32!HeapCreateStub (769a29d7)}

0:000> p
eax=002c0000 ebx=00000000 ecx=77429897 edx=77498500 esi=00000001 edi=01033374
eip=01031018 esp=0022fe98 ebp=0022feac iopl=0         nv up ei pl nz na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000             efl=00000206
heap!main+0x18:
01031018 8945fc          mov     dword ptr [ebp-4],eax ss:0023:0022fea8=6d222201
0:000> !heap
Index   Address Name      Debugging options enabled
1:   00300000
2:   00010000
3:   00020000
4:   002e0000
5:   002c0000

HeapCreate執行的返回值存放在eax處，這個函數返回了一個堆句柄：0x002c0000。用!heap命令查看可以看到第五個堆就是我們創建的堆句柄了。

每個進程都存在多個堆，我們也可以通過PEB結構來得到進程中存在的堆，結果和!heap命令顯示的內容是一樣的。

!peb 命令得到peb地址xxxx，dt _PEB XXXXX命令查看peb結構

   +0x018 ProcessHeap      : 0x00300000 Void         ; 進程的默認堆
   +0x068 NtGlobalFlag     : 0                                       ; 這個標誌位記錄了當前堆調試模式,0爲普通調試模式
   +0x078 HeapSegmentReserve : 0x100000          ; 進程在新建堆的時候默認申請的虛擬內存大小
   +0x07c HeapSegmentCommit : 0x2000               ; 進程在每次申請提交的虛擬內存大小，在提交的內存用完後，進程會又在一次提交HeapSegmentCommit中指定的內存大小
   +0x080 HeapDeCommitTotalFreeThreshold : 0x10000    ; 當釋放的內存大小大於這個閥值，就進行內存解除提交操作
   +0x084 HeapDeCommitFreeBlockThreshold : 0x1000     ; 當一次性釋放的塊大小超過這個閥值，就進行內存解除提交操作，只有當滿足這兩個條件時纔會調用ZwFreeVirtualMeMory 釋放物理內存
   +0x088 NumberOfHeaps    : 5                                               ; 當前進程的堆數目,這個數目對應着!heap命令的堆顯示個數
   +0x08c MaximumNumberOfHeaps : 0x10                          ; 進程所能運行的最大堆數目,若堆數目超過這個值估計HeapCreate就失敗了吧
   +0x090 ProcessHeaps     : 0x77498500 -> 0x00300000 Void ;存儲堆句柄的數組,這裏我們可以得到進程的所有堆句柄

我們可以輸入如下命令來查看現有的堆句柄

0:000> dd 0x77498500
77498500  00300000 00010000 00020000 002e0000
77498510  002c0000 00000000 00000000 00000000
77498520 00000000 00000000 00000000 00000000
77498530 00000000 00000000 00000000 00000000
77498540 00000000 77498340 7749bb08 77498220
77498550 00000000 00000000 00000000 00000000
77498560 77498220 00317bd0 00000000 00000000
77498570 00000000 00000000 00000000 00000000

可以看得到這裏面的內容和!heap命令的輸出結果是一樣的

而堆句柄的存放範圍,從MaximumNumberOfHeaps 上來看,就是77498500-77498540這0x40個字節，因爲每個堆句柄佔4個字節，0x10個堆句柄的存放空間就是0x40。

HEAP的組織結構

堆的管理，我們可以理解爲一個內存池，它申請一大塊空間，然後負責接管應用程序的申請釋放等請求。只有在創建堆，釋放堆（注意！是釋放堆，不是堆中的空間！）在這之前，我們需要對堆有關的數據結構做一些解釋

我這裏觀察到的HEAP結構，HEAP_SEGMENT結構和HEAP_ENTRY結構都和軟件調試裏面描述的不一樣，當年奎哥寫軟件調試的時候估計還沒用上WIN7吧。。。我的演示系統是WIN7

HeapCreate函數返回的堆句柄其實就是一個指向堆管理結構的指針，每個堆都會涉及到這樣三個結構：HEAP,HEAP_SEGMENT,HEAP_ENTRY

HEAP_ENTRY結構：

在堆管理中，每一塊申請下來的內存都會有下面所示的固定模式：

HEAP_ENTRY（8 bytes）

我們new或malloc分配的空間

固定填充空間

這個結構用來記錄所分配的空間的信息，包括用戶申請的空間，填充的空間，所在的段號等等信息。所以我們new或者malloc的地址減去8就指向該結構。第三部分的固定填充空間是爲了內存對齊而生成的，當然這部分空間還有一部分是用來額外記錄這塊內存的其它信息，這裏就不詳細做介紹了。

HEAP_SEGMENT結構：

我們可以這麼認爲，堆申請內存的大小是以段爲單位的，當新建一個堆的時候，系統會默認爲這個堆分配一個段叫0號段，通過剛開始的new和malloc分配的空間都是在這個段上分配的，當這個段用完的時候，如果當初創建堆的時候指明瞭HEAP_GROWABLE這個標誌，那麼系統會爲這個堆在再分配一個段，這個時候新分配的段就稱爲1號段了，以下以此類推。每個段的開始初便是HEAP_SEGMENT結構的首地址，由於這個結構也是申請的一塊內存，所以它前面也會有個HEAP_ENTRY結構：

HEAP_ENTRY（8 bytes）

HEAP_SEGMENT

HEAP_ENTRY（8 bytes）

我們new或malloc分配的空間

固定填充空間

HEAP_SEGMENT結構會記錄段的一些基本信息，該段申請的大小，已經提交內存的大小，第一個HEAP_ENTRY結構的入口點。（我觀察看貌似段申請的內存並不會一次性全部提交，而是每次提交一個頁的大小，比如一個段大小2個頁，那麼它會先提交一個頁內存，若用完了再提交一個頁的內存，若內存還用完了那就新建一個段，這個新建的段也會是先提交一個頁內存。）但是0號段很特別，這個段的起始地址就是堆句柄指針指向的值，也就是說，HeapCreate返回的堆句柄總是指向0號段，爲什麼呢？因爲HEAP結構是HEAP_ENTRY,HEAP_SEGMENT的合體加長版~

HEAP結構：

HEAP結構則是記錄了這個堆的信息，這個結構可以找到HEAP_SEGMENT鏈表入口，空閒內存鏈表的入口，內存分配粒度等等信息。HEAP的首地址便是堆句柄的值，但是堆句柄的值又是0號段的首地址也是堆句柄，何解？其實很簡單，0號段的HEAP_SEGMENT就在HEAP結構裏面，HEAP結構類定義如這樣：

struct _HEAP

{

_HEAP_ENTRY Entry ; //HEAP_ENTRY結構，用來描述存儲HEAP內存塊大小等信息的

_HEAP_SEGMENT Segment ;  //0號段的首地址

……  //對於該HEAP的描述信息

} ;

在我們看來，內存組織結構應該如下所示：

HEAP_ENTRY（8 bytes）

HEAP_SEGMENT

HEAP

更確切的說，HEAP結構中本身就包含了HEAP_ENTRY和HEAP_SEGMENT，HEAP_ENTRY結構是HEAP的第一個數據成員，HEAP_SEGMENT是它第二個數據成員。而對於HEAP_SEGMENT,它的第一個數據成員便是HEAP_ENTRY。這裏爲了方便理解，纔在內存組織結構中把它們拆開展示。（注：這裏是win7的情況，和軟件調試這本書中所描述的有一些差異，也屬正常現象，畢竟這部分結構微軟並未公開）

用WINDBG觀察HEAP結構

在之前已經演示瞭如何從PEB結構中找到所有的堆句柄，可以看到002c0000便是我們創建的句柄。然後我們執示例程序的第7行代碼。執行完後結果如下：

0:000> p
eax=002c0000 ebx=00000000 ecx=77429897 edx=77498500 esi=00000001 edi=01033374
eip=01031026 esp=0022fe8c ebp=0022feac iopl=0         nv up ei pl nz na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000             efl=00000206
heap!main+0x26:
01031026 ff1500200301    call    dword ptr [heap!_imp__HeapAlloc (01032000)] ds:0023:01032000={ntdll!RtlAllocateHeap (774120b5)}
0:000> p
eax=002c0590 ebx=00000000 ecx=774134b4 edx=002c0180 esi=00000001 edi=01033374
eip=0103102c esp=0022fe98 ebp=0022feac iopl=0         nv up ei pl zr na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000             efl=00000246
heap!main+0x2c:
0103102c 8945f0          mov     dword ptr [ebp-10h],eax ss:0023:0022fe9c={heap!envp (0103301c)}

可以看到EAX保存的返回值爲002c0590。我們通過兩種途徑來觀察我們申請的內存，通過!heap命令觀察和通過dt命令觀察

通過!HEAP命令觀察

0:000> !heap -a 2c0000
Index   Address Name      Debugging options enabled
5:   002c0000
    Segment at 002c0000 to 002c2000 (00001000 bytes committed)
    Flags:                00001000
    ForceFlags:           00000000
    Granularity:          8 bytes
    Segment Reserve:      00100000
    Segment Commit:       00002000
    DeCommit Block Thres: 00000200
    DeCommit Total Thres: 00002000
    Total Free Size:      0000013a
    Max. Allocation Size: 7ffdefff
    Lock Variable at:     002c0138
    Next TagIndex:        0000
    Maximum TagIndex:     0000
    Tag Entries:          00000000
    PsuedoTag Entries:    00000000
    Virtual Alloc List:   002c00a0
    Uncommitted ranges:   002c0090
            002c1000: 00001000 (4096 bytes)
    FreeList[ 00 ] at 002c00c4: 002c0618 . 002c0618
        002c0610: 00088 . 009d0 [100] - free

    Segment00 at 002c0000:
        Flags:           00000000
        Base:            002c0000
        First Entry:     002c0588
        Last Entry:      002c2000
        Total Pages:     00000002
        Total UnCommit: 00000001
        Largest UnCommit:00000000
        UnCommitted Ranges: (1)

    Heap entries for Segment00 in Heap 002c0000
        002c0000: 00000 . 00588 [101] - busy (587)
        002c0588: 00588 . 00088 [101] - busy (80)
        002c0610: 00088 . 009d0 [100]
        002c0fe0: 009d0 . 00020 [111] - busy (1d)
        002c1000:      00001000      - uncommitted bytes.

這個命令分別提煉出了HEAP, HEAP_SEGMENT和HEAP_ENTRY結構中的信息。雖然在灰色區域中，我們找不到2c0590，但是找到了一個2c0588，這個正是2c0590-8的結果，也就是說最右邊的地址是每個HEAP_ENTRY的首地址，接着00588這個字段表示了前面一個HEAP_ENTRY所佔用的大小，後面的0088表示這個內存塊的總大小，即我們申請的內存+HEAP_ENTRY（128+8=0x80+0x8=0x88），[101]是這塊內存的標誌位，最右邊一位爲1表示該內存塊被佔用。然後busy（80）就是解釋說這塊內存是被佔用的（非空閒的），它申請的內存爲0x80，轉化成十進制正好就是我們申請的128字節大小。

dt _HEAP_ENTRY 2c0588命令查看對應的結構信息

通過DT命令觀察

同樣的，已知HEAP的首地址，那麼先從HEAP下手好了，dt _HEAP 002c0000可以顯示HEAP的數據結構

ntdll!_HEAP
   +0x000 Entry            : _HEAP_ENTRY
   +0x008 SegmentSignature : 0xffeeffee
   +0x00c SegmentFlags     : 0
   +0x010 SegmentListEntry : _LIST_ENTRY [ 0x2c00a8 - 0x2c00a8 ]
   +0x018 Heap             : 0x002c0000 _HEAP
   +0x01c BaseAddress      : 0x002c0000 Void
   +0x020 NumberOfPages    : 2
   +0x024 FirstEntry       : 0x002c0588 _HEAP_ENTRY
   +0x028 LastValidEntry   : 0x002c2000 _HEAP_ENTRY
   +0x02c NumberOfUnCommittedPages : 1
   +0x030 NumberOfUnCommittedRanges : 1
   +0x034 SegmentAllocatorBackTraceIndex : 0
   +0x036 Reserved         : 0
   +0x038 UCRSegmentList   : _LIST_ENTRY [ 0x2c0ff0 - 0x2c0ff0 ]
   +0x040 Flags            : 0x1000
   +0x044 ForceFlags       : 0
   +0x048 CompatibilityFlags : 0
   +0x04c EncodeFlagMask   : 0x100000
   +0x050 Encoding         : _HEAP_ENTRY
   +0x058 PointerKey       : 0x17c06e63
   +0x05c Interceptor      : 0
   +0x060 VirtualMemoryThreshold : 0xfe00
   +0x064 Signature        : 0xeeffeeff
   +0x068 SegmentReserve   : 0x100000
   +0x06c SegmentCommit    : 0x2000
   +0x070 DeCommitFreeBlockThreshold : 0x200
   +0x074 DeCommitTotalFreeThreshold : 0x2000
   +0x078 TotalFreeSize    : 0x13a
   +0x07c MaximumAllocationSize : 0x7ffdefff
   +0x080 ProcessHeapsListIndex : 5
   +0x082 HeaderValidateLength : 0x138
   +0x084 HeaderValidateCopy : (null)
   +0x088 NextAvailableTagIndex : 0
   +0x08a MaximumTagIndex : 0
   +0x08c TagEntries       : (null)
   +0x090 UCRList          : _LIST_ENTRY [ 0x2c0fe8 - 0x2c0fe8 ]
   +0x098 AlignRound       : 0xf
   +0x09c AlignMask        : 0xfffffff8
   +0x0a0 VirtualAllocdBlocks : _LIST_ENTRY [ 0x2c00a0 - 0x2c00a0 ]
   +0x0a8 SegmentList      : _LIST_ENTRY [ 0x2c0010 - 0x2c0010 ]
   +0x0b0 AllocatorBackTraceIndex : 0
   +0x0b4 NonDedicatedListLength : 0
   +0x0b8 BlocksIndex      : 0x002c0150 Void
   +0x0bc UCRIndex         : (null)
   +0x0c0 PseudoTagEntries : (null)
   +0x0c4 FreeLists        : _LIST_ENTRY [ 0x2c0618 - 0x2c0618 ]
   +0x0cc LockVariable     : 0x002c0138 _HEAP_LOCK
   +0x0d0 CommitRoutine    : 0x17c06e63     long +17c06e63
   +0x0d4 FrontEndHeap     : (null)
   +0x0d8 FrontHeapLockCount : 0
   +0x0da FrontEndHeapType : 0 ''
   +0x0dc Counters         : _HEAP_COUNTERS
   +0x130 TuningParameters : _HEAP_TUNING_PARAMETERS
就如本文前面所述的，第一個字段是HEAP_ENTRY結構，接着應該是HEAP_SEGMENT，這裏只不過把HEAP_SEGMENT結構的字段展開了，可以dt _HEAP_SEGMENT來觀察下這個結構的字段

0:000> dt _heap_segment
ntdll!_HEAP_SEGMENT
   +0x000 Entry            : _HEAP_ENTRY
   +0x008 SegmentSignature : Uint4B
   +0x00c SegmentFlags     : Uint4B
   +0x010 SegmentListEntry : _LIST_ENTRY
   +0x018 Heap             : Ptr32 _HEAP
   +0x01c BaseAddress      : Ptr32 Void
   +0x020 NumberOfPages    : Uint4B
   +0x024 FirstEntry       : Ptr32 _HEAP_ENTRY
   +0x028 LastValidEntry   : Ptr32 _HEAP_ENTRY
   +0x02c NumberOfUnCommittedPages : Uint4B
   +0x030 NumberOfUnCommittedRanges : Uint4B
   +0x034 SegmentAllocatorBackTraceIndex : Uint2B
   +0x036 Reserved         : Uint2B
   +0x038 UCRSegmentList   : _LIST_ENTRY

可以看到HEAP結構中灰色部分是和HEAP_SEGMENT結構中的字段是重複的，也就是說灰色部分字段便是HEAP_SEGMENT結構。在HEAP_SEGMENT結構中，我們可以找到FirstEntry字段，這裏指的便是我們的分配的內存，不過HEAP_ENTRY結構無法觀察，這裏便沒辦法枚舉出所有的HEAP_ENTRY結構了，但是說一下思路：

每個HEAP_ENTRY和它對應的內存我們可以稱爲一個內存塊，計算下一個內存塊需要用到現有內存塊中的2個字段，Size和UnsedBytes，Size的值乘上粒度（就是0:000> !heap -a 2c0000命令顯示的信息中的Granularity: 8 bytes字段，這裏是8字節），下一個內存塊地址就是本內存塊地址+Size*8+UnsedBytes。當然這裏的粒度可以通過HEAP字段中的AlignMask 字段算出來。

HEAP的分配粒度

在HEAP結構中指明瞭分配粒度，這個分配粒度是說每次堆分配的時候，都以這個粒度爲最小單位，這裏看到粒度爲8字節。所以這裏就有了第二次分配內存的實驗，我們讓程序執行第9行，然後用!heap -a 002c0000觀察分配情況

Heap entries for Segment00 in Heap 002c0000
    002c0000: 00000 . 00588 [101] - busy (587)
    002c0588: 00588 . 00088 [101] - busy (80)
    002c0610: 00088 . 00088 [101] - busy (79)
    002c0698: 00088 . 00948 [100]
    002c0fe0: 00948 . 00020 [111] - busy (1d)
    002c1000:      00001000      - uncommitted bytes.

這裏可以看出多出了一個佔用塊，大小是0x79（121） bytes，但是實際分配的大小還是0x 88 （128）bytes，這是因爲系統是以8 bytes爲粒度分配的，所以爲這塊121 bytes的內存自動填充了7個字節，可見申請121 bytes和申請128 bytes所使用的空間是一樣的。

HEAP的釋放和銷燬

執行了11行和12行的代碼後，堆中的內容分別如下：

執行11行代碼的堆情況

FreeList[ 00 ] at 002c00c4: 002c06a0 . 002c0590
    002c0588: 00588 . 00088 [100] – free   ；空閒列表中多出了一塊內存
    002c0698: 00088 . 00948 [100] – free   ；空閒內存，空閒空間爲948

Heap entries for Segment00 in Heap 002c0000
002c0000: 00000 . 00588 [101] - busy (587)
002c0588: 00588 . 00088 [100] ；原先的這塊內存釋放掉了
002c0610: 00088 . 00088 [101] - busy (79)
002c0698: 00088 . 00948 [100] ; 空閒內存
002c0fe0: 00948 . 00020 [111] - busy (1d)
002c1000: 00001000 - uncommitted bytes.

執行12行代碼的堆情況

FreeList[ 00 ] at 005c00c4: 005c0590 . 005c0590
005c0588: 00588 . 00a58 [100] – free ；回收了buffer1的內存後，由於由於空閒內存是連續的，所以直接合併成一塊內存。可以看到之前內存free空間是948，現在合併了以後便是948+88+88=a58,也就是當前內存大小

Heap entries for Segment00 in Heap 005c0000
    005c0000: 00000 . 00588 [101] - busy (587)
    005c0588: 00588 . 00a58 [100]
    005c0fe0: 00a58 . 00020 [111] - busy (1d)
    005c1000:      00001000      - uncommitted bytes.

最後執行14行代碼,對堆進行釋放,釋放後我們通過!heap也可以看到只有4個堆了,我們申請的堆被釋放了.

0:000> !heap
Index Address Name Debugging options enabled
1: 00300000
2: 00010000
3: 00020000
4: 002e0000

至於HEAP_ENTRY結構的問題,有時間在調試看看是怎麼回事吧~另外，這裏說明下，new和malloc內部都會調用HeapAlloc來申請內存，但是堆句柄從哪來呢？它會檢測_crtheap變量是否爲空，若不爲空則拿_crtheap變量來作爲自己的堆句柄去調用HeapAlloc

windbg調試堆

windbg調試HEAP

HEAP的概念

如何找到我們的HEAP信息？

HEAP的組織結構

用WINDBG觀察HEAP結構

通過!HEAP命令觀察

通過DT命令觀察

HEAP的分配粒度

HEAP的釋放和銷燬

快速移除RBD中的Image數據

python Windows下修改pip安裝的鏡像源

C#操作firebird數據庫大全

堆介紹

windbg調試堆

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結