今天調試一個bug，用pageheap解決，在此記錄一下。

bug癥狀如下：

1：不確定性崩潰，用vs調試啟動每次崩潰地點都在crt分配或者釋放堆的位置
2：崩潰時vs看到的調用棧可能不同
3：output輸出HEAP: Free Heap block 388c58 modified at 388c88 after it was freed

問題分析：

根據vs的輸出，確定問題是在一塊堆上分配的內存在釋放后被改寫了。由于CRT只能在下次做堆操作檢查時才會暴露出問題，所以程序崩潰的調用棧是不確定的。
折騰了2個小時后，啟用pageheap縮小了程序出錯到崩潰之間的距離，解決了問題。過程如下：
1:啟動pageheap
pageheap /enable mybug.exe 0x01
2:調試啟動mybug.exe
現在程序崩潰的調用棧每次都相同，并且都在相同的線程中，根據調用棧信息很輕松的鎖定了bug。

由于上面的例子過于復雜，下面寫了一些小程序分析了pageheap的原理

char* buffer = new char[19];        // 1
buffer[19] = 0;                     // 2
delete [] buffer;                   // 3

這是一個很簡單的堆內存越界的例子，在未啟動pageheap的情況下，我們來看看buffer的內存情況：
buffer = 0x00388C80
第一行執(zhí)行后,buffer的內存

0x00388C80  cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd  ................
0x00388C90  cd cd cd fd fd fd fd ab ab ab ab ab ab ab ab fe  ................

簡單說明一下，調試模式下堆上未初始化的內存為cd，并且在內存結束處有4個fd的邊界，用于debug模式下crt做內存檢查，執(zhí)行第2行之后，buffer的內存為

0x00388C80  cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd  ................
0x00388C90  cd cd cd 00 fd fd fd ab ab ab ab ab ab ab ab fe  ................

可以看到4個fd的內存邊界中第一個fd被破壞了。但這個時候程序并沒有崩潰，繼續(xù)執(zhí)行第3行，程序崩潰，提示堆錯誤，可以看到，如果第2行和第3行之間有很長的代碼邏輯，那么也只能在第3行執(zhí)行之后程序才會崩潰。這給調式程序帶來了極大的不便。
如果第2行改為：buffer[24] = 0 程序同樣不會崩潰
如果啟用了pageheap，再來看看在debug模式下buffer的內存分配情況：
第一行分配內存后,buffer的內存情況：

0x01675FE8  cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd  ................
0x01675FF8  cd cd cd fd fd fd fd d0 ?? ?? ?? ?? ?? ?? ?? ??  ................

可以看到，和上面一樣，在內存結束加上了4個fd的邊界，d0是用于填補4字節(jié)對齊，注意buffer后面的地址(第一個??)為0x01675FF8+8 = 0x01676000,這是一個4k對齊的PAGE_NOACCESS頁面,這個時候我們執(zhí)行第2行代碼
buffer[19] = 0; 同樣不會崩潰，即使是修改buffer[19-23]的值(4個fd邊界和1個對齊d0)，和未啟動pageheap一樣，程序都只會在執(zhí)行第3行的時候崩潰。如果修改buffer[24]則程序會崩潰。

通過這個例子，可以得出一個結論：啟用pageheap后，堆內存分配在頁面的末尾，后面緊跟了一個4k的PAGE_NOACCESS屬性的頁面,這種情況下，啟用pageheap的好處是能在一定程度上檢查內存越界。

再來看一個例子

 char* buffer = new char[20];  // 1
 delete [] buffer;             // 2
 buffer[1] = 1;                // 3

這個例子演示了操作delete釋放后的內存，在未啟動pageheap的情況下，程序不會崩潰，原因同上一個例子，啟用pageheap后，buffer內存為：
第一行執(zhí)行后:

0x01675FE8  cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd  ................
0x01675FF8  cd cd cd cd fd fd fd fd ?? ?? ?? ?? ?? ?? ?? ??  ................

第2行執(zhí)行后：

0x01675FE8  ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??  ................
0x01675FF8  ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??  ................

可以看到，啟用pageheap后delete內存，分配該內存的整個頁面都被設置為PAGE_NOACCESS屬性，這樣操作delete后的任何內存程序馬上就會崩潰。

結論2：啟用pageheap很容易檢查操作delete后的內存的錯誤（包括2次delete）

總結：
1：啟用pageheap后，系統(tǒng)的堆管理器會把內存分配到4k頁面的末尾（注意需要4字節(jié)對齊，debug模式下還存在邊界檢查的4字節(jié)fd）
2：緊隨著的下一個頁面被設置為PAGE_NOACCESS屬性
3：啟用pageheap后，釋放內存把整個頁面設置為PAGE_NOACCESS屬性
4：內存越界和非法操作依靠非法訪問PAGE_NOACCESS屬性的頁面暴露問題
5：由于每塊內存都至少需要2個頁面（1個頁面分配，1個頁面PAGE_NOACCESS），在內存消耗較大的環(huán)境下會占用極大的內存資源。
6：把pageheap和crt的堆檢查函數結合起來，能夠更好的暴露堆相關bug

ps.pageheap的作用是在注冊表位置HKLM/SOFTWARE/Microsoft/Windows NT/CurrentVersion/Image File Execution Options下生成一個項