HEAP的概念

堆棧堆棧，在操作系統(tǒng)內(nèi)存中有兩種存儲(chǔ)空間，一個(gè)是堆，一個(gè)是棧。堆主要用于存儲(chǔ)用戶動(dòng)態(tài)分配的變量，而棧呢，則是存儲(chǔ)我們程序過程中的臨時(shí)變量。當(dāng)然棧的作用遠(yuǎn)不止用作存儲(chǔ)變量，但這不是我們這篇文章的討論內(nèi)容。

堆（HEAP）的分配，使用，回收都是通過微軟的API來管理的，最常見的API是malloc和new。在往底層走一點(diǎn)呢，這兩個(gè)函數(shù)都會(huì)調(diào)用HeapAlloc（RtlAllocateHeap）。同樣的相關(guān)函數(shù)還有HeapFree用來釋放堆，HeapCreate用來創(chuàng)建自己的私有堆。下面是這些函數(shù)的調(diào)用鏈：

HeapCreate->RtlCreateHeap->ZwAllocateVirtualMemory? (這里會(huì)直接申請(qǐng)一大片內(nèi)存,至于申請(qǐng)多大內(nèi)存,由進(jìn)程PEB結(jié)構(gòu)中的字段覺得，HeapSegmentReserve字段指出要申請(qǐng)多大的虛擬內(nèi)存，HeapSegmentCommit指明要提交多大內(nèi)存，對(duì)虛擬內(nèi)存的申請(qǐng)和提交概念不清楚的童鞋，請(qǐng)參見windows核心編程相關(guān)內(nèi)容~)

HeapAlloc->RtlAllocateHeap（至于這里申請(qǐng)的內(nèi)存，由于HeapCreate已經(jīng)申請(qǐng)了一大片內(nèi)存，堆管理器這片內(nèi)存中劃分一塊出來以滿足申請(qǐng)的需要。這一步申請(qǐng)操作是堆管理器自己維護(hù)的，僅當(dāng)申請(qǐng)內(nèi)存不夠的時(shí)候才會(huì)再次調(diào)用ZwAllocateVirtualMemory?）

HeapFree->RtlFreeHeap （對(duì)于釋放的內(nèi)存，堆管理器只是簡單的把這塊內(nèi)存標(biāo)志位已釋放讓后加入到空閑列表中，僅當(dāng)空閑的內(nèi)存達(dá)到一定閥值的時(shí)候會(huì)調(diào)用ZwFreeVirtualMeMory?）

HeapDestroy->RtlDestroyHeap->ZwFreeVirtualMeMory?? （銷毀我們申請(qǐng)的堆）

如何找到我們的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調(diào)試這個(gè)程序，在main函數(shù)下斷，緊接著執(zhí)行第五行語句，執(zhí)行結(jié)果如下

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執(zhí)行的返回值存放在eax處，這個(gè)函數(shù)返回了一個(gè)堆句柄：0x002c0000。用!heap命令查看可以看到第五個(gè)堆就是我們創(chuàng)建的堆句柄了。

每個(gè)進(jìn)程都存在多個(gè)堆，我們也可以通過PEB結(jié)構(gòu)來得到進(jìn)程中存在的堆，結(jié)果和!heap命令顯示的內(nèi)容是一樣的。

!peb 命令得到peb地址xxxx，dt _PEB XXXXX命令查看peb結(jié)構(gòu)

?? +0x018 ProcessHeap????? : 0x00300000 Void???????? ; 進(jìn)程的默認(rèn)堆
?? +0x068 NtGlobalFlag???? : 0?????????????????????????????????????? ; 這個(gè)標(biāo)志位記錄了當(dāng)前堆調(diào)試模式,0為普通調(diào)試模式
?? +0x078 HeapSegmentReserve : 0x100000????????? ; 進(jìn)程在新建堆的時(shí)候默認(rèn)申請(qǐng)的虛擬內(nèi)存大小
?? +0x07c HeapSegmentCommit : 0x2000?????????????? ; 進(jìn)程在每次申請(qǐng)?zhí)峤坏奶摂M內(nèi)存大小，在提交的內(nèi)存用完后，進(jìn)程會(huì)又在一次提交HeapSegmentCommit中指定的內(nèi)存大小
?? +0x080 HeapDeCommitTotalFreeThreshold : 0x10000??? ; 當(dāng)釋放的內(nèi)存大小大于這個(gè)閥值，就進(jìn)行內(nèi)存解除提交操作
?? +0x084 HeapDeCommitFreeBlockThreshold : 0x1000???? ;? 當(dāng)一次性釋放的塊大小超過這個(gè)閥值，就進(jìn)行內(nèi)存解除提交操作，只有當(dāng)滿足這兩個(gè)條件時(shí)才會(huì)調(diào)用ZwFreeVirtualMeMory 釋放物理內(nèi)存
?? +0x088 NumberOfHeaps??? : 5?????????????????????????????????????????????? ; 當(dāng)前進(jìn)程的堆數(shù)目,這個(gè)數(shù)目對(duì)應(yīng)著!heap命令的堆顯示個(gè)數(shù)
?? +0x08c MaximumNumberOfHeaps : 0x10????????????????????????? ; 進(jìn)程所能運(yùn)行的最大堆數(shù)目,若堆數(shù)目超過這個(gè)值估計(jì)HeapCreate就失敗了吧
?? +0x090 ProcessHeaps???? : 0x77498500? -> 0x00300000 Void ;存儲(chǔ)堆句柄的數(shù)組,這里我們可以得到進(jìn)程的所有堆句柄

我們可以輸入如下命令來查看現(xiàn)有的堆句柄

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

可以看得到這里面的內(nèi)容和!heap命令的輸出結(jié)果是一樣的

而堆句柄的存放范圍,從MaximumNumberOfHeaps 上來看,就是77498500-77498540這0x40個(gè)字節(jié)，因?yàn)槊總€(gè)堆句柄占4個(gè)字節(jié)，0x10個(gè)堆句柄的存放空間就是0x40。

HEAP的組織結(jié)構(gòu)

堆的管理，我們可以理解為一個(gè)內(nèi)存池，它申請(qǐng)一大塊空間，然后負(fù)責(zé)接管應(yīng)用程序的申請(qǐng)釋放等請(qǐng)求。只有在創(chuàng)建堆，釋放堆（注意！是釋放堆，不是堆中的空間！）在這之前，我們需要對(duì)堆有關(guān)的數(shù)據(jù)結(jié)構(gòu)做一些解釋

我這里觀察到的HEAP結(jié)構(gòu)，HEAP_SEGMENT結(jié)構(gòu)和HEAP_ENTRY結(jié)構(gòu)都和軟件調(diào)試?yán)锩婷枋龅牟灰粯?#xff0c;當(dāng)年奎哥寫軟件調(diào)試的時(shí)候估計(jì)還沒用上WIN7吧。。。我的演示系統(tǒng)是WIN7

HeapCreate函數(shù)返回的堆句柄其實(shí)就是一個(gè)指向堆管理結(jié)構(gòu)的指針，每個(gè)堆都會(huì)涉及到這樣三個(gè)結(jié)構(gòu)：HEAP,HEAP_SEGMENT,HEAP_ENTRY

HEAP_ENTRY結(jié)構(gòu)：

在堆管理中，每一塊申請(qǐng)下來的內(nèi)存都會(huì)有下面所示的固定模式：

HEAP_ENTRY（8 bytes）

我們new或malloc分配的空間

固定填充空間

這個(gè)結(jié)構(gòu)用來記錄所分配的空間的信息，包括用戶申請(qǐng)的空間，填充的空間，所在的段號(hào)等等信息。所以我們new或者malloc的地址減去8就指向該結(jié)構(gòu)。第三部分的固定填充空間是為了內(nèi)存對(duì)齊而生成的，當(dāng)然這部分空間還有一部分是用來額外記錄這塊內(nèi)存的其它信息，這里就不詳細(xì)做介紹了。

HEAP_SEGMENT結(jié)構(gòu)：

我們可以這么認(rèn)為，堆申請(qǐng)內(nèi)存的大小是以段為單位的，當(dāng)新建一個(gè)堆的時(shí)候，系統(tǒng)會(huì)默認(rèn)為這個(gè)堆分配一個(gè)段叫0號(hào)段，通過剛開始的new和malloc分配的空間都是在這個(gè)段上分配的，當(dāng)這個(gè)段用完的時(shí)候，如果當(dāng)初創(chuàng)建堆的時(shí)候指明了HEAP_GROWABLE這個(gè)標(biāo)志，那么系統(tǒng)會(huì)為這個(gè)堆在再分配一個(gè)段，這個(gè)時(shí)候新分配的段就稱為1號(hào)段了，以下以此類推。每個(gè)段的開始初便是HEAP_SEGMENT結(jié)構(gòu)的首地址，由于這個(gè)結(jié)構(gòu)也是申請(qǐng)的一塊內(nèi)存，所以它前面也會(huì)有個(gè)HEAP_ENTRY結(jié)構(gòu)：

HEAP_ENTRY（8 bytes）

HEAP_SEGMENT

HEAP_ENTRY（8 bytes）

我們new或malloc分配的空間

固定填充空間

HEAP_SEGMENT結(jié)構(gòu)會(huì)記錄段的一些基本信息，該段申請(qǐng)的大小，已經(jīng)提交內(nèi)存的大小，第一個(gè)HEAP_ENTRY結(jié)構(gòu)的入口點(diǎn)。（我觀察看貌似段申請(qǐng)的內(nèi)存并不會(huì)一次性全部提交，而是每次提交一個(gè)頁的大小，比如一個(gè)段大小2個(gè)頁，那么它會(huì)先提交一個(gè)頁內(nèi)存，若用完了再提交一個(gè)頁的內(nèi)存，若內(nèi)存還用完了那就新建一個(gè)段，這個(gè)新建的段也會(huì)是先提交一個(gè)頁內(nèi)存。）但是0號(hào)段很特別，這個(gè)段的起始地址就是堆句柄指針指向的值，也就是說，HeapCreate返回的堆句柄總是指向0號(hào)段，為什么呢？因?yàn)镠EAP結(jié)構(gòu)是HEAP_ENTRY,HEAP_SEGMENT的合體加長版~

HEAP結(jié)構(gòu)：

HEAP結(jié)構(gòu)則是記錄了這個(gè)堆的信息，這個(gè)結(jié)構(gòu)可以找到HEAP_SEGMENT鏈表入口，空閑內(nèi)存鏈表的入口，內(nèi)存分配粒度等等信息。HEAP的首地址便是堆句柄的值，但是堆句柄的值又是0號(hào)段的首地址也是堆句柄，何解？其實(shí)很簡單，0號(hào)段的HEAP_SEGMENT就在HEAP結(jié)構(gòu)里面，HEAP結(jié)構(gòu)類定義如這樣：

[c]?view plaincopy

struct?_HEAP??

??

{??

??

_HEAP_ENTRY?Entry?;?//HEAP_ENTRY結(jié)構(gòu)，用來描述存儲(chǔ)HEAP內(nèi)存塊大小等信息的??

??

_HEAP_SEGMENT?Segment?;??//0號(hào)段的首地址??

??

……??//對(duì)于該HEAP的描述信息??

??

}?;??

在我們看來，內(nèi)存組織結(jié)構(gòu)應(yīng)該如下所示：

HEAP_ENTRY（8 bytes）

HEAP_SEGMENT

HEAP

更確切的說，HEAP結(jié)構(gòu)中本身就包含了HEAP_ENTRY和HEAP_SEGMENT，HEAP_ENTRY結(jié)構(gòu)是HEAP的第一個(gè)數(shù)據(jù)成員，HEAP_SEGMENT是它第二個(gè)數(shù)據(jù)成員。而對(duì)于HEAP_SEGMENT,它的第一個(gè)數(shù)據(jù)成員便是HEAP_ENTRY。這里為了方便理解，才在內(nèi)存組織結(jié)構(gòu)中把它們拆開展示。（注：這里是win7的情況，和軟件調(diào)試這本書中所描述的有一些差異，也屬正?，F(xiàn)象，畢竟這部分結(jié)構(gòu)微軟并未公開）

用WINDBG觀察HEAP結(jié)構(gòu)

在之前已經(jīng)演示了如何從PEB結(jié)構(gòu)中找到所有的堆句柄，可以看到002c0000便是我們創(chuàng)建的句柄。然后我們執(zhí)示例程序的第7行代碼。執(zhí)行完后結(jié)果如下：

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。我們通過兩種途徑來觀察我們申請(qǐng)的內(nèi)存，通過!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.

這個(gè)命令分別提煉出了HEAP, HEAP_SEGMENT和HEAP_ENTRY結(jié)構(gòu)中的信息。雖然在灰色區(qū)域中，我們找不到2c0590，但是找到了一個(gè)2c0588，這個(gè)正是2c0590-8的結(jié)果，也就是說最右邊的地址是每個(gè)HEAP_ENTRY的首地址，接著00588這個(gè)字段表示了前面一個(gè)HEAP_ENTRY所占用的大小，后面的0088表示這個(gè)內(nèi)存塊的總大小，即我們申請(qǐng)的內(nèi)存+HEAP_ENTRY（128+8=0x80+0x8=0x88），[101]是這塊內(nèi)存的標(biāo)志位，最右邊一位為1表示該內(nèi)存塊被占用。然后busy（80）就是解釋說這塊內(nèi)存是被占用的（非空閑的），它申請(qǐng)的內(nèi)存為0x80，轉(zhuǎn)化成十進(jìn)制正好就是我們申請(qǐng)的128字節(jié)大小。

dt _HEAP_ENTRY 2c0588命令查看對(duì)應(yīng)的結(jié)構(gòu)信息

通過DT命令觀察

同樣的，已知HEAP的首地址，那么先從HEAP下手好了，dt _HEAP 002c0000可以顯示HEAP的數(shù)據(jù)結(jié)構(gòu)

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
就如本文前面所述的，第一個(gè)字段是HEAP_ENTRY結(jié)構(gòu)，接著應(yīng)該是HEAP_SEGMENT，這里只不過把HEAP_SEGMENT結(jié)構(gòu)的字段展開了，可以dt _HEAP_SEGMENT來觀察下這個(gè)結(jié)構(gòu)的字段

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結(jié)構(gòu)中灰色部分是和HEAP_SEGMENT結(jié)構(gòu)中的字段是重復(fù)的，也就是說灰色部分字段便是HEAP_SEGMENT結(jié)構(gòu)。在HEAP_SEGMENT結(jié)構(gòu)中，我們可以找到FirstEntry字段，這里指的便是我們的分配的內(nèi)存，不過HEAP_ENTRY結(jié)構(gòu)無法觀察，這里便沒辦法枚舉出所有的HEAP_ENTRY結(jié)構(gòu)了，但是說一下思路：

每個(gè)HEAP_ENTRY和它對(duì)應(yīng)的內(nèi)存我們可以稱為一個(gè)內(nèi)存塊，計(jì)算下一個(gè)內(nèi)存塊需要用到現(xiàn)有內(nèi)存塊中的2個(gè)字段，Size和UnsedBytes，Size的值乘上粒度（就是0:000> !heap -a 2c0000命令顯示的信息中的Granularity: 8 bytes字段，這里是8字節(jié)），下一個(gè)內(nèi)存塊地址就是?本內(nèi)存塊地址+Size*8+UnsedBytes。當(dāng)然這里的粒度可以通過HEAP字段中的AlignMask 字段算出來。

HEAP的分配粒度

在HEAP結(jié)構(gòu)中指明了分配粒度，這個(gè)分配粒度是說每次堆分配的時(shí)候，都以這個(gè)粒度為最小單位，這里看到粒度為8字節(jié)。所以這里就有了第二次分配內(nèi)存的實(shí)驗(yàn)，我們讓程序執(zhí)行第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.

這里可以看出多出了一個(gè)占用塊，大小是0x79（121） bytes，但是實(shí)際分配的大小還是0x 88 （128）bytes，這是因?yàn)橄到y(tǒng)是以8 bytes為粒度分配的，所以為這塊121 bytes的內(nèi)存自動(dòng)填充了7個(gè)字節(jié)，可見申請(qǐng)121 bytes和申請(qǐng)128 bytes所使用的空間是一樣的。

HEAP的釋放和銷毀

執(zhí)行了11行和12行的代碼后，堆中的內(nèi)容分別如下：

執(zhí)行11行代碼的堆情況

FreeList[ 00 ] at 002c00c4: 002c06a0 . 002c0590??
??? 002c0588: 00588 . 00088 [100] – free???；空閑列表中多出了一塊內(nèi)存
??? 002c0698: 00088 . 00948 [100] – free???；空閑內(nèi)存，空閑空間為948

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

執(zhí)行12行代碼的堆情況

FreeList[ 00 ] at 005c00c4: 005c0590 . 005c0590??
??? 005c0588: 00588 . 00a58 [100] – free?；回收了buffer1的內(nèi)存后，由于由于空閑內(nèi)存是連續(xù)的，所以直接合并成一塊內(nèi)存?？梢钥吹街皟?nèi)存free空間是948，現(xiàn)在合并了以后便是948+88+88=a58,也就是當(dāng)前內(nèi)存大小

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.

最后執(zhí)行14行代碼,對(duì)堆進(jìn)行釋放,釋放后我們通過!heap也可以看到只有4個(gè)堆了,我們申請(qǐng)的堆被釋放了.

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

至于HEAP_ENTRY結(jié)構(gòu)的問題,有時(shí)間在調(diào)試看看是怎么回事吧~另外，這里說明下，new和malloc內(nèi)部都會(huì)調(diào)用HeapAlloc來申請(qǐng)內(nèi)存，但是堆句柄從哪來呢？它會(huì)檢測(cè)_crtheap變量是否為空，若不為空則拿_crtheap變量來作為自己的堆句柄去調(diào)用HeapAlloc

此文會(huì)涉及到一些普通堆的知識(shí)，這些內(nèi)容可以參見我之前的文章?WINDBG的堆調(diào)試--了解HEAP組織

堆破壞

所謂的堆破壞，是說沒控制好自己的指針，把不屬于你分配的那塊內(nèi)存給寫覆蓋了。這塊內(nèi)存可能是你程序的數(shù)據(jù)，也可能是堆的管理結(jié)構(gòu)。那么這個(gè)會(huì)導(dǎo)致怎樣的后果呢？可能的情況我們來yy下

把程序里的計(jì)算結(jié)果覆蓋了，這也許會(huì)讓你重復(fù)看了N次代碼，校驗(yàn)了N次計(jì)算邏輯也搞不明白為何計(jì)算結(jié)果還是有問題

堆管理結(jié)構(gòu)被破壞了，new/delete，或者malloc/free操作失敗

等等等等~

堆破壞較為理想的情況是被修改的數(shù)據(jù)會(huì)馬上導(dǎo)致程序crash，最差的情況是你的堆數(shù)據(jù)莫名其妙在今天被改了，但明天才crash。這個(gè)時(shí)候在去分析crash，就如我們的警察叔叔現(xiàn)在接手一樁10年前的案子一般----無從下手。老外稱之為heap corruption是很貼切的，有時(shí)候咱堆數(shù)據(jù)被意外篡改是無聲無息的，你也許沒法從界面甚至日志文件中看到它被篡改的一點(diǎn)跡象，當(dāng)?shù)侥骋粋€(gè)時(shí)刻，這種錯(cuò)誤會(huì)暴露出來，然而這個(gè)時(shí)候查看堆信息也許會(huì)是毫無頭緒。所以對(duì)于堆破壞，咱的策略是盡早發(fā)現(xiàn)我們的堆被篡改了，最好能夠在堆數(shù)據(jù)被意外篡改的那一時(shí)刻誘發(fā)一個(gè)異常來提醒我們----兄弟，你的堆被腐蝕了。

微軟提供了一些方案，來幫助我們?cè)\斷堆破壞。一般來說，堆破壞往往都是寫數(shù)據(jù)越界造成的（yy的第二種情況，如果是第一種情況其實(shí)還簡單，下個(gè)內(nèi)存斷點(diǎn)就好），所以微軟在堆分配上，給程序員門額外提供了2種堆分配模式--完全頁堆（full page heap），準(zhǔn)頁堆(normal page heap)，用來檢測(cè)堆被寫越界的情況。

完全頁堆（full page heap）

檢測(cè)原理

完全頁堆的檢測(cè)基本思路是通過分配相鄰的一個(gè)頁，并將其設(shè)為不可訪問屬性，然后用戶數(shù)據(jù)塊會(huì)被分配到內(nèi)存頁的最末端，從而實(shí)現(xiàn)越界訪問的檢測(cè)。當(dāng)我們對(duì)堆中分配的內(nèi)存讀寫越界后便會(huì)訪問到那個(gè)不可讀的頁，系統(tǒng)捕獲到改次異常后會(huì)試圖中斷執(zhí)行并將該異常上報(bào)給debugger，或者崩潰。具體的內(nèi)存組織結(jié)構(gòu)如下圖

摘自《軟件調(diào)試》

?

與普通堆不同的是，內(nèi)存塊前面的HEAP_ENTRY結(jié)構(gòu)被DPH_BLOCK_INFORMATION結(jié)構(gòu)取代，這個(gè)結(jié)構(gòu)內(nèi)部記錄了頁堆模式下這個(gè)內(nèi)存塊的一些基本信息。如果用戶數(shù)據(jù)區(qū)前面的數(shù)據(jù)，也就是DPH_BLOCK_INFORMATION結(jié)構(gòu)被破壞了，那么在釋放內(nèi)存塊的時(shí)候系統(tǒng)會(huì)報(bào)錯(cuò)，如果編程者對(duì)這塊內(nèi)存塊讀寫越界了，當(dāng)然，這里越界有幾種情況：

讀越界，但只是訪問了塊尾填充部分?jǐn)?shù)據(jù)，那么系統(tǒng)不會(huì)報(bào)錯(cuò)

寫越界，但只篡改了圖中塊尾填充的部分，那么在堆塊釋放的時(shí)候會(huì)報(bào)錯(cuò)

讀越界，且超過了塊尾填充的部分，訪問到了柵欄頁，那么系統(tǒng)會(huì)立即拋出一個(gè)異常并中斷執(zhí)行

寫越界，且超過了塊尾填充部分，寫到了柵欄頁，那么系統(tǒng)會(huì)立即拋出一個(gè)異常并中斷執(zhí)行

這里需要注意的還是塊尾填充不一定存在，塊尾填充是因?yàn)橐獫M足堆內(nèi)存的最小分配粒度，如果本身內(nèi)存塊的分配粒度就已經(jīng)是最小分配粒度的倍數(shù)了，那么塊尾填充就不存在了，比如堆內(nèi)存分配粒度是是8 bytes，那么如果申請(qǐng)了14 bytes的話會(huì)有2 bytes的大徐小的塊尾填充塊，如果申請(qǐng)了24bytes，那么就沒有塊尾填充了，因?yàn)?4正好是8的倍數(shù)。

?

示例

開啟全頁堆（用windbg目錄下的gflags或者裝一個(gè)appverifier都可以開啟），通過自己寫的一個(gè)heap.exe來看一下如何使用全頁堆檢測(cè)堆破壞情況heap.exe代碼如下：

[c]?view plaincopy

#include?"windows.h"??

??

int?main()??

{??

????HANDLE?heap_handle?=?HeapCreate(?NULL?,?1024?,?0?)?;??

????char?*temp?=?NULL?;??

??

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

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

????temp?=?buffer?;??

??

????for(?int?i?=?0?;?i?<?138?;?++i?)??

????{??

????????????*(temp++)?=?'a'?;??

????}??

??

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

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

????HeapDestroy(?heap_handle)?;??

????return?0?;??

}??

在第14行向buffer寫入138字節(jié)，這顯然越界了，然后在用windbg啟動(dòng)heap.exe，直接運(yùn)行，會(huì)發(fā)現(xiàn)報(bào)錯(cuò)如下

0:000> g
(1f50.1f54): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=00000080 ebx=00000000 ecx=02596000 edx=02596000 esi=00000001 edi=00193374
eip=00191068 esp=0016fdc8 ebp=0016fddc iopl=0???????? nv up ei ng nz ac pe cy
cs=001b? ss=0023? ds=0023? es=0023? fs=003b? gs=0000???????????? efl=00010297
heap!main+0x68:
00191068 c60161????????? mov???? byte ptr [ecx],61h???????? ds:0023:02596000=??

報(bào)了一個(gè)內(nèi)存訪問錯(cuò)誤，然后看一下調(diào)用堆棧

0:000> kb
ChildEBP RetAddr? Args to Child??????????????
0016fddc 0019120f 00000001 023fbfd0 0239df48 heap!main+0x68 [d:\projects\heap\main.cpp @ 14]
0016fe20 765b1114 7ffd3000 0016fe6c 778eb429 heap!__tmainCRTStartup+0x10f [f:\dd\vctools\crt_bld\self_x86\crt\src\crtexe.c @ 582]
0016fe2c 778eb429 7ffd3000 757369d8 00000000 kernel32!BaseThreadInitThunk+0xe
0016fe6c 778eb3fc 00191357 7ffd3000 00000000 ntdll!__RtlUserThreadStart+0x70
0016fe84 00000000 00191357 7ffd3000 00000000 ntdll!_RtlUserThreadStart+0x1b

可以看到是第14行報(bào)的錯(cuò)，但是14行的代碼運(yùn)行了那么多次，我們?cè)倏匆幌逻@個(gè)時(shí)候變量i的值是多少

0:000> dv i
????????????? i = 0n128

顯然，在填充第128字節(jié)的時(shí)候，我們的temp指針訪問到了柵欄頁，從而報(bào)出了一個(gè)內(nèi)存違規(guī)的異常。

這里順帶看一下如果我們分配的內(nèi)存不是8 bytes的情況（一般堆內(nèi)存分配粒度是8 bytes，所以申請(qǐng)128 bytes的內(nèi)存時(shí)是不會(huì)有塊尾填充部分的）

那我們接下來看另外一段代碼

我們把第10行的temp = buffer改成temp = buffer1

因?yàn)閎uffer1申請(qǐng)了121 bytes，也就是說它有7 bytes的填充字節(jié)

0:000> g
(1ba0.1ba4): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=00000080 ebx=00000000 ecx=024c8000 edx=024c8000 esi=00000001 edi=00033374
eip=00031068 esp=002cfb80 ebp=002cfb94 iopl=0???????? nv up ei ng nz ac pe cy
cs=001b? ss=0023? ds=0023? es=0023? fs=003b? gs=0000???????????? efl=00010297
heap!main+0x68:
00031068 c60161????????? mov???? byte ptr [ecx],61h???????? ds:0023:024c8000=??
0:000> dv i
????????????? i = 0n128

可以看到變量i還是128，也就是說我們還是在訪問到第128字節(jié)后才引發(fā)訪問異常，而不是我們期望的121字節(jié)后就引發(fā)異常。

這里也就是說如果我們的代碼中對(duì)申請(qǐng)的堆內(nèi)存寫越界了，寫數(shù)據(jù)覆蓋塊尾填充部分的時(shí)候并不會(huì)引發(fā)異常！

但是，這并不代表我們的寫越界問題不會(huì)被發(fā)現(xiàn)。塊尾填充部分是會(huì)被填充上固定數(shù)據(jù)的，系統(tǒng)在適合的時(shí)機(jī)（比如銷毀堆的時(shí)候）會(huì)校驗(yàn)塊尾填充塊，如果發(fā)現(xiàn)塊尾填充塊數(shù)據(jù)有變，那么便會(huì)報(bào)一個(gè)verifier異常，比如我們把代碼中的for循環(huán)次數(shù)改為124

[c]?view plaincopy

for(?int?i?=?0?;?i?<?124?;?++i?)??

那么windbg會(huì)中斷在第19行

[c]?view plaincopy

HeapDestroy(?heap_handle)?;??

提示內(nèi)容如下
=======================================
VERIFIER STOP 0000000F: pid 0x1E3C: Corrupted suffix pattern for heap block.

????025A1000?: Heap handle used in the call.
????025A7F80?: Heap block involved in the operation.
??? 00000079 : Size of the heap block.
????025A7FF9?: Corruption address.

=======================================
This verifier stop is not continuable. Process will be terminated?
when you use the `go' debugger command.

=======================================

(1e3c.143c): Break instruction exception - code 80000003 (first chance)
eax=6c75e994 ebx=6c75cf58 ecx=00000002 edx=002bf461 esi=00000000 edi=000001ff
eip=6c753c38 esp=002bf6b4 ebp=002bf8b8 iopl=0???????? nv up ei pl nz na po nc
cs=001b? ss=0023? ds=0023? es=0023? fs=003b? gs=0000???????????? efl=00000202
vrfcore!VerifierStopMessageEx+0x543:
6c753c38 cc????????????? int???? 3

提示說的很清楚了，appverifier指出了堆和具體的內(nèi)存塊，我們這個(gè)時(shí)候查看buffer1的值是0x025a7f80?，正好就是出問題的堆塊，出問題的地址是0x025a7ff79，正好就是buffer1內(nèi)存塊的邊界，錯(cuò)誤原因是Corrupted suffix pattern for heap block，也就是說咱塊尾填充部分（suffix pattern for heap block）被破壞（corrupted）了

結(jié)論：只要寫越界，系統(tǒng)都能夠檢測(cè)出來，只不過如果寫越界寫到了柵欄頁會(huì)理解觸發(fā)異常中斷，而寫越界只寫了塊尾填充部分，那么系統(tǒng)在適當(dāng)時(shí)機(jī)（比如堆被銷毀，或者這塊內(nèi)存被重新分配等時(shí)機(jī)）會(huì)對(duì)塊尾填充部分做完整性檢測(cè)，如果發(fā)現(xiàn)被破壞了，就會(huì)報(bào)錯(cuò)。當(dāng)然，你可以根據(jù)錯(cuò)誤號(hào)（藍(lán)色字體部分）信息去appverifier的幫助文檔中查找更詳細(xì)的錯(cuò)誤說明。

結(jié)構(gòu)詳解

這次咱來倒敘，先從最基本的內(nèi)存堆塊結(jié)構(gòu)DPH_BLOCK_INFORMATION開始介紹，DPH_BLOCK_INFORMATION結(jié)構(gòu)微軟也有對(duì)應(yīng)文檔介紹

（摘自MSDN）

?

其中prefix start magic和prefix end magic是校驗(yàn)塊，用來檢測(cè)DPH_BLOCK_INFORMATION是否被破壞，這些檢測(cè)部分屬于DPH_BLOCK_INFORMATION結(jié)構(gòu)。我們先來用windbg探究下DPH_BLOCK_INFORMATION這個(gè)最基本的結(jié)構(gòu).再一次,我們打開windbg調(diào)試heap.exe.運(yùn)行到第10行,這個(gè)時(shí)候變量的值是

0:000> dv heap_handle
??? heap_handle =?0x024a0000
0:000> dv buffer
???????? buffer =?0x024a5f80?"???"
0:000> dv buffer1
??????? buffer1 =?0x024a7f80?"???"

這里可以看到一個(gè)很有趣的現(xiàn)象,buffer1和buffer的地址正好相差8K,也就是兩個(gè)頁的大小.這當(dāng)然是因?yàn)轫摱训脑蚶?其實(shí)這兩塊內(nèi)存分配是相鄰著的,虛擬內(nèi)存結(jié)構(gòu)如下圖所示

buffer內(nèi)存塊（4K）

柵欄頁（4K）

buffer1內(nèi)存塊(4K)

柵欄頁(4K)

?

由于buffer和buffer1分配的大小是一樣的（buffer1加上尾部填充塊和buffer的大小相同），所以這兩塊內(nèi)存正好相差8K

而DPH_BLOCK_INFORMATION就在我們申請(qǐng)的內(nèi)存塊指針的前0x20字節(jié)處，用dt命令看的結(jié)果如下:

0:000> dt _DPH_BLOCK_INFORMATION 0x024a5f80-0x20
verifier!_DPH_BLOCK_INFORMATION
?? +0x000 StartStamp?????? : 0xabcdbbbb
?? +0x004 Heap???????????? : 0x024a1000 Void
?? +0x008 RequestedSize??? : 0x80
?? +0x00c ActualSize?????? : 0x1000
?? +0x010 Internal???????? : _DPH_BLOCK_INTERNAL_INFORMATION
?? +0x018 StackTrace?????? : 0x003d9854 Void
?? +0x01c EndStamp???????? : 0xdcbabbbb

?

0x024a5f80-0x20就是DPH_BLOCK_INFORMATION結(jié)構(gòu)的地址。DPH_BLOCK_INFORMATION結(jié)構(gòu)在已分配和已釋放的狀態(tài)下，StartStamp和EndStamp（也就是MSDN圖中的prefix start magic和prefix end magic）是不同的，顯然dt輸出的結(jié)果看來，這個(gè)內(nèi)存塊是已分配狀態(tài)。StackTrace記錄了分配這個(gè)內(nèi)存塊時(shí)的調(diào)用棧，可以用dds來看一下這個(gè)內(nèi)存塊被分配時(shí)候的調(diào)用棧

0:000> dds 0x003d9854?
003d9854? 00000000
003d9858? 00004001
003d985c? 00090000
003d9860? 5b3b8e89 verifier!AVrfDebugPageHeapAllocate+0x229
003d9864? 776d5c4e ntdll!RtlDebugAllocateHeap+0x30
003d9868? 77697e5e ntdll!RtlpAllocateHeap+0xc4
003d986c? 776634df ntdll!RtlAllocateHeap+0x23a
003d9870? 003b1030 heap!main+0x30 [d:\projects\heap\main.cpp @ 8]
003d9874? 003b120c heap!__tmainCRTStartup+0x10f [f:\dd\vctools\crt_bld\self_x86\crt\src\crtexe.c @ 582]
003d9878? 76451114 kernel32!BaseThreadInitThunk+0xe
003d987c? 7766b429 ntdll!__RtlUserThreadStart+0x70
003d9880? 7766b3fc ntdll!_RtlUserThreadStart+0x1b

輸出結(jié)果我們可以看到這個(gè)內(nèi)存塊是在main.cpp,也就是我們的示例代碼的第8行分配的，第8行是char *buffer = (char*)HeapAlloc(heap_handle , NULL , 128) 正好就是分配buffer內(nèi)存的那條語句。這個(gè)結(jié)構(gòu)的其它字段，顧名思義，ActualSize指明了實(shí)際分配字節(jié)數(shù)，0x1000 bytes也就是4K大小，Internal這個(gè)字段保存了個(gè)內(nèi)部結(jié)構(gòu)，用windbg也看不出這個(gè)結(jié)構(gòu)信息。

當(dāng)然為了防止內(nèi)存塊前面的數(shù)據(jù)被沖刷掉，除了DPH_BLOCK_INFORMATION外，系統(tǒng)還通過DPH_HEAP_BLOCK保存了所分配內(nèi)存塊的信息，

通過!heap –p –h [address] 可以查看到頁堆的信息

0:000> !heap -p -h?0x024a0000??????????????????????????? //heap_handle的值
??? _DPH_HEAP_ROOT @ 24a1000
??? Freed and decommitted blocks
????? DPH_HEAP_BLOCK : VirtAddr VirtSize
??? Busy allocations
????? DPH_HEAP_BLOCK : UserAddr? UserSize - VirtAddr VirtSize
????????024a1f6c?: 024a5f80 00000080 - 024a5000 00002000
??????? 024a1f38 : 024a7f80 00000079 - 024a7000 00002000

可以看到，buffer內(nèi)存塊對(duì)應(yīng)的DPH_HEAP_BLOCK結(jié)構(gòu)地址是024a1f6c

0:000> dt _DPH_HEAP_BLOCK 024a1f6c
verifier!_DPH_HEAP_BLOCK
?? +0x000 NextFullPageHeapDelayedNode : 0x024a1020 _DPH_HEAP_BLOCK
?? +0x004 DelayQueueEntry? : _DPH_DELAY_FREE_QUEUE_ENTRY
?? +0x000 LookasideEntry?? : _LIST_ENTRY [ 0x24a1020 - 0x0 ]
?? +0x000 UnusedListEntry? : _LIST_ENTRY [ 0x24a1020 - 0x0 ]
?? +0x000 VirtualListEntry : _LIST_ENTRY [ 0x24a1020 - 0x0 ]
?? +0x000 FreeListEntry??? : _LIST_ENTRY [ 0x24a1020 - 0x0 ]
?? +0x000 TableLinks?????? : _RTL_BALANCED_LINKS
?? +0x010 pUserAllocation? : 0x024a5f80? "???"
?? +0x014 pVirtualBlock??? : 0x024a5000? "???"
?? +0x018 nVirtualBlockSize : 0x2000
?? +0x01c Flags??????????? : _DPH_HEAP_BLOCK_FLAGS
?? +0x020 nUserRequestedSize : 0x80
?? +0x024 AdjacencyEntry?? : _LIST_ENTRY [ 0x24a1f5c - 0x24a1fc4 ]
?? +0x02c ThreadId???????? : 0x3f4
?? +0x030 StackTrace?????? : 0x003d9854 Void

從dt的數(shù)據(jù)看來，這個(gè)結(jié)構(gòu)大小為0x34，buffer和buffer1的DPH_HEAP_BLOCK結(jié)構(gòu)首地址正好也是相差0x34，說明這兩個(gè)結(jié)構(gòu)是緊挨著的，下一步在讓我們來看看DPH_HEAP_BLOCK結(jié)構(gòu)是如何組織的。

摘自《軟件調(diào)試》

?

這個(gè)是整個(gè)的頁堆結(jié)構(gòu)圖，我們先來說說DPH_HEAP_BLOCK的組織吧，在圖中0x16d00000是頁堆的首地址，也就是頁堆的句柄，我們調(diào)試器中，頁堆首地址則是0x024a0000，為了數(shù)據(jù)統(tǒng)一，我還是拿0x024a0000作為堆句柄來講解。我們的DPH_HEAP_BLOCK其實(shí)就在堆塊節(jié)點(diǎn)池里邊，我們可以近似把這個(gè)節(jié)點(diǎn)池看成一個(gè)大型的DPH_HEAP_BLOCK數(shù)組，但有個(gè)地方在軟件調(diào)試中沒有提到，就是在win7下，運(yùn)行時(shí)這些DPH_HEAP_BLOCK結(jié)構(gòu)都是以二叉平衡數(shù)的結(jié)構(gòu)來組織的，這個(gè)樹的結(jié)構(gòu)的入口正是在TableLinks字段內(nèi)，這么做的原因也大概是因?yàn)槟軌蛟诜峙鋾r(shí)更快的索。我們?cè)倏纯碊PH_HEAP_ROOT結(jié)構(gòu)，這個(gè)結(jié)構(gòu)儲(chǔ)存了整個(gè)頁堆的必要信息，它就相當(dāng)于普通堆的_HEAP結(jié)構(gòu)。

0:000> dt _dph_heap_root 24a1000
verifier!_DPH_HEAP_ROOT
?? +0x000 Signature??????? : 0xffeeddcc
?? +0x004 HeapFlags??????? : 0x1002
?? +0x008 HeapCritSect???? : 0x024a16cc _RTL_CRITICAL_SECTION
?? +0x00c NodesCount?????? : 0x2c
?? +0x010 VirtualStorageList : _LIST_ENTRY [ 0x24a1fa0 - 0x24a1fa0 ]
?? +0x018 VirtualStorageCount : 1
?? +0x01c PoolReservedLimit : 0x024a5000 Void
?? +0x020?BusyNodesTable?? : _RTL_AVL_TABLE
?? +0x058 NodeToAllocate?? : (null)?
?? +0x05c nBusyAllocations : 2
?? +0x060 nBusyAllocationBytesCommitted : 0x4000
?? +0x064 pFreeAllocationListHead : (null)?
?? +0x068 FullPageHeapDelayedListTail : (null)?
?? +0x06c DelayFreeQueueHead : (null)?
?? +0x070 DelayFreeQueueTail : (null)?
?? +0x074 DelayFreeCount?? : 0
?? +0x078 LookasideList??? : _LIST_ENTRY [ 0x24a1078 - 0x24a1078 ]
?? +0x080 LookasideCount?? : 0
?? +0x084 UnusedNodeList?? : _LIST_ENTRY [ 0x24a1ed0 - 0x24a16e4 ]
?? +0x08c UnusedNodeCount? : 0x28
?? +0x090 nBusyAllocationBytesAccessible : 0x2000
?? +0x094 GeneralizedFreeList : _LIST_ENTRY [ 0x24a1f04 - 0x24a1f04 ]
?? +0x09c FreeCount??????? : 1
?? +0x0a0 PoolCommitLimit? : 0x024a2000 Void
?? +0x0a4 NextHeap???????? : _LIST_ENTRY [ 0x5b3e9a58 - 0x23a10a4 ]
?? +0x0ac ExtraFlags?????? : 3
?? +0x0b0 Seed???????????? : 0xfed6f13a
?? +0x0b4 NormalHeap?????? : 0x027d0000 Void
?? +0x0b8 CreateStackTrace : 0x003d9824 _RTL_TRACE_BLOCK
?? +0x0bc ThreadInHeap???? : (null)?
?? +0x0c0 BusyListHead???? : _LIST_ENTRY [ 0x24a10c0 - 0x24a10c0 ]
?? +0x0c8 SpecializedFreeList : [64] _LIST_ENTRY [ 0x24a10c8 - 0x24a10c8 ]
?? +0x2c8 DelayFreeListLookup : [257] (null)?
?? +0x6cc HeapCritSectionStorage : _RTL_CRITICAL_SECTION

這里邊維護(hù)了很多運(yùn)行時(shí)信息，比如說DPH_BLOCK_INFORMATION中的那個(gè)二叉樹入口其實(shí)就是保存在BusyNodesTable?字段，這里面記錄了所有被分配了的內(nèi)存塊所對(duì)應(yīng)的DPH_BLOCK_INFORMATION。當(dāng)然，這里面一些信息軟件調(diào)試?yán)锩娑加薪榻B，很多看名字也能夠猜到大概意思，看名字猜不到啥意思的字段，其實(shí)我也猜不到。。。-_-|||在創(chuàng)建頁堆后，所有內(nèi)存分配都分配在頁堆中，通過分配的地址也能看得出來（我們分配的內(nèi)存都是024a打頭），而非普通頁堆中，普通頁堆也僅僅只是保存一些系統(tǒng)內(nèi)部使用的數(shù)據(jù)。一般來說，堆塊節(jié)點(diǎn)池加上DPH_HEAP_ROOT結(jié)構(gòu)大小正好是4個(gè)內(nèi)存頁，也就是16K。

優(yōu)缺點(diǎn)

缺點(diǎn)：消耗大量虛擬內(nèi)存，每塊內(nèi)存的分配粒度是2個(gè)頁（8K），

優(yōu)點(diǎn)：能夠立即捕獲越界讀寫操作，通過調(diào)用棧就可以追溯到問題源頭。能夠快速定位問題代碼。

使用建議：32位下不適宜跑配置文件結(jié)構(gòu)比較復(fù)雜的軟件，讓我們來假設(shè)一個(gè)xml配置文件下有3000個(gè)節(jié)點(diǎn)，每個(gè)節(jié)點(diǎn)有5個(gè)字符串描述屬性，如果把這些配置文件信息轉(zhuǎn)化為stl結(jié)構(gòu)來保存，那么每個(gè)節(jié)點(diǎn)則需要為此分配5*8K的空間，3000項(xiàng)配置則需要3000*5*8K=117MB虛擬內(nèi)存，如果每個(gè)節(jié)點(diǎn)信息再多一些呢？這樣會(huì)導(dǎo)致虛擬內(nèi)存耗盡從而出現(xiàn)一系列內(nèi)存問題（比如，new失敗）。當(dāng)然64位就不存在這種問題了7T的虛擬內(nèi)存空間，現(xiàn)在看來應(yīng)該是夠用了。

?

對(duì)于調(diào)試堆破壞來說，其實(shí)我們只要了解DPH_BLOCK_INFORMATION結(jié)構(gòu)和DPH_HEAP_BLOCK中的基本字段就差不多了，這樣更方便我們定位出錯(cuò)源頭。比如在appverifier報(bào)錯(cuò)后（或者你程序自己莫名其妙崩潰或者數(shù)據(jù)被篡改后，要知道appverifier并不總是可信的），我們可以自己手動(dòng)調(diào)試出錯(cuò)的堆塊結(jié)構(gòu)（DPH_BLOCK_INFORMATION，DPH_HEAP_BLOCK和DPH_HEAP_ROOT），檢測(cè)以下這些點(diǎn)：

檢測(cè)堆塊管理結(jié)構(gòu)的校驗(yàn)字段是否完整

是否塊尾填充部分有被修改過

檢測(cè)到未釋放或者重復(fù)釋放堆資源時(shí)，查看問題的堆塊被分配時(shí)的調(diào)用棧

其實(shí)頁堆還好，它有較強(qiáng)的實(shí)時(shí)性，所以并不需要太多手工調(diào)試的操作，越界讀寫都會(huì)立即觸發(fā)異常并且中斷，所以從這點(diǎn)看來，它是一些軟件用來檢測(cè)堆資源是否正確使用的必備良藥~ 但是相對(duì)于頁堆，準(zhǔn)頁堆的調(diào)試則需要更好的去了解準(zhǔn)頁堆工作原理了，因?yàn)樗峁┑亩褖K檢測(cè)不是實(shí)時(shí)的，所以發(fā)現(xiàn)問題后，需要咱“精湛的調(diào)試內(nèi)功“去找出源頭，關(guān)于準(zhǔn)頁堆的東西，下回再說吧，敬請(qǐng)期待~

總結(jié)

以上是生活随笔為你收集整理的windbg调试HEAP的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。