Windows has triggered a breakpoint in xxx.exe

看到這個錯誤就可以推測是記憶體使用量錯了，但是這種錯誤很隱蔽。所以昨天花了一整天找到這個錯誤，最後發現是一個全域變數指標指向了一個非全域類執行個體的一個成員。當文檔關閉時，這個類就銷毀了，但是全域的指標還在，這個時候變成了野指標。而下一次開啟文檔時接著使用了，所以異常。

pageheap.exe工具幫了不少忙，在開啟它後錯誤基本就能定位到了。在沒用它之前，每次跳出異常的地方不確定，在各種new的地方都可能出現，讓人極其鬱悶。下面貼個pageheap.exe的使用說明。

 

推薦使用PageHeap.Exe和Gflags.Exe，主要的原因還是因為當有人問記憶體越界的錯誤如何查出來的時候，國外的朋友經常會推薦這兩個工具（highly recommend）。我用過之後，也覺得有些時候用用還是有好處的。

PageHeap.Exe將針對某個指定的應用程式啟用Page Heap標誌，從而自動監視所有的malloc、new和heapAlloc的記憶體配置，找出記憶體錯誤。

PageHeap.Exe的下載地點：

http://download.microsoft.com/download/vc60pro/utility/6.0/win98/en-us/pageheap1.exe

下面我們簡單地給出PageHeap使用步驟：

第一步：

在命令列中運行PageHeap.Exe。如果你以前設定過啟用Global Page Heap標誌，那麼你將看到一個列表，給出所有已經啟用了的應用程式的名字，不含路徑。

如下所示：

C:\>pageheap

pgh.exe                                  enabled

testSplit.exe                            enabled

第二步：

編譯一個小程式，其中有如下代碼：

void main()
{
  int m_len = 5;
  char *m_p = (char *)HeapAlloc (GetProcessHeap (),    HEAP_ZERO_MEMORY, m_len);
  m_p[m_len] = 0;
  HeapFree (GetProcessHeap (),0, m_p);
}

Build出一個Debug版本。運行之，你看不到有任何異常的報告。

但其實m_p[m_len]=0這句話就是越界寫了，因為只分配到了m_p[m_len-1]！這種情況就叫Dynamic memory overrun。用BoundsChecker是可以查到的。

這時，表面上看不出任何問題，但是一顆定時炸彈已經埋下了。

第三步：

在命令列中運行PageHeap /enable YourApplicationName.exe 0x01。

再運行一次不帶參數的PageHeap，察看上面的命令是否生效。你的應用程式應該在啟用的列表中。

注意：千萬不要在YourApplication.Exe前面加上路徑！！

0x01的含義在後面說明。

第四步：

再次運行你的程式。

你將會注意到在Output視窗的載入各種DLL之前，多了幾句話：

Loaded exports for 'C:\WINNT\System32\ntdll.dll'
Page heap: process 0x57C created heap @ 00130000 (00230000, flags 0x1)
Loaded 'C:\WINNT\system32\MFC42D.DLL', no matching symbolic information found.
..
Loaded 'C:\WINNT\system32\MSVCP60D.DLL', no matching symbolic information found.
Page heap: process 0x57C created heap @ 00470000 (00570000, flags 0x1)
Loaded exports for 'C:\WINNT\system32\imm32.dll'

這就是Page Heap的監視機制在發揮作用！他告訴你你的堆00470000被建立出來了。

然後程式退出後，Output視窗有這麼幾句話表明一定有什麼錯誤發生了：

Page heap: block @ 0015AFF8 is corrupted (reason 10) 
Page heap: reason: corrupted suffix pattern 
Page heap: process 0x57C destroyed heap @ 00471000 (00570000)
The thread 0x8A8 has exited with code 0 (0x0).

這說明在銷毀堆00470000時遇到了麻煩，就是資料區塊0015AFF8被誤用了，原因是誤用了下標文法。看，說得多麼清楚！也節省了許多翻來覆去查代碼的工作！

PageHeap的使用中有幾點值得注意：

1:啟用PageHeap不能夠影響正在運行中的應用程式。如果你需要啟用一些正在運行且不能重啟的程式的PageHeap，那請運行PageHeap啟用後，重新啟動機器。

2:要想查看PageHeap把資訊放到哪裡了，請開啟你的註冊表，來到HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options

你將會看到你的應用程式也在這個項下面。你的應用程式的GlobalFlag被設定為了0x02000000，PageHeapFlags被設定為了0x01。

3：PageHeap的原理是這樣，它在已指派的記憶體的後面放上幾個守護位元組（Guard Bytes），再跟上一個標記為PAGE_NOACCESS的記憶體頁。這樣，已指派記憶體的後面如果被重寫了，那麼守護位元組就會被改變，於是當記憶體被釋放時，PageHeap就會引發一個AV(Access Violation)。大體上就是這樣。所以只有最後釋放這塊問題記憶體時，才會有PageHeap的報告！這就是PageHeap的局限性吧。

參數0x01的含義：

FLAGS hex value (0x...) has the following structure:

    B7-B0   Bit flags    1 - enable page heap

   01 - enable page heap. If zero normal heap is used. In 99% of the cases you will want this to be set.
   02 - collect stack traces (default on checked builds)
   04 - minimize memory impact
   08 - minimize randomly(1)/based on size range(0)
   10 - catch backward overruns

看到了嗎？你還可以設定參數為0x10，從而可以檢查記憶體向前的越界寫！

Gflags.Exe是微軟的Debugging Tools裡面的工具。在Windows 2000的Resource Kit中也可以找得到。我們也可以用它來完成和PageHeap相同的任務。當然，Gflags.EXE還能做許許多多其他的事情。這裡我們就不介紹了，總之物超所值。

具體的使用辦法是：

1)     運行Gflags.Exe；

2)  你將看到一個對話方塊。在”Image File”的編輯框中寫下你的應用程式的名字，如YourApp.Exe。注意不要路徑！

3)  選擇”Image File Options”的單選鈕；

4)  這時，你會看到對話方塊的內容突然一變。選中“Place heap
allocations at ends of pages”前的複選框。

5)  點擊Apply按鈕。

這樣，就達到了PageHeap的效果。現在運行你的程式，overwrite你的堆，就應該產生一個AV了!

(請結合查看微軟KB：SAMPLE: PageHeap1.exe Finds Heap Corruption and Memory Errors (Q264471))

 

其他人也遇到過這個問題，貼一些他們的分享：

過程是這樣的,在vc debug的過程中,突然彈出了一個assert視窗:

Windows has triggered a breakpoint in cs.exe.

This may be due to a corruption of the heap, which indicates a bug in cs.exe or any of the DLLs it has loaded.

This may also be due to the user pressing F12 while cs.exe has focus.

查看output輸出:

Heap missing last entry in committed range near e6****630

Windows has triggered a breakpoint in cs.exe.

This may be due to a corruption of the heap, which indicates a bug in cs.exe or any of the DLLs it has loaded.

不廢話,直接查看該記憶體是什麼:

0×0E6****630 0e 00 0f 00 59 03 10 04 aa aa cd ab 00 10 72 85 38 00

看不出什麼,往上再看看:

0×0E6****60C 07 e2 04 00 a8 01 66 0e 01 00 cd cd fd fd fd fd….

看來這就是塊堆記憶體,實在看不出什麼,決定暫時忽略. 過了幾天,該錯誤沒有再出現過.

但就在交付程式前一天測試中,又出現了這個錯誤.看來一顆定時炸彈是埋藏在了程式中.必須找出來,否則後果很嚴重.

首先要做的就是要重現這個問題,如果每次碰巧遇到這個問題的話,實在無從下手.從癥狀來看,是個典型的Heap Corrupt.所以先使用工具:pageheap,以做到能夠百分百重現那個堆破壞.

page heap工具啟用的兩種方法：Full-page heap和Normal page heap

我先使用了Normal page heap 命令為pageheap /enable xx.exe /normal

然後通過windbg設定符號表:x:\symbols_folder;srv*x:\symbols_folder*http://msdl.microsoft.com/download/symbols

開始各種調試,幾乎用遍了<>這本書中指導的各種命令,(調試過程省略2000字)未果.幾乎崩潰時,突然看到書上的這麼一段話:

普通頁堆通過填充模式檢測堆塊破壞,需要再發生堆破壞之後再調用一次堆管理器.

完全頁堆除了特定的填充模式外,它還為每個堆塊增加了防護頁,防護頁是一個頁不可訪問的記憶體,它被放置在堆塊的起始位置和結束位置上.防止堆塊上下溢出.

我靠,直接pageheap /enable xx.exe /full 設定完全頁堆模式.重新運行程式.

瞬間程式崩掉,這個激動呀.還是第一次看見程式崩掉那麼激動,查看崩潰的代碼:

原來是把一個類指標強轉為另一個子類的指標,調用了子類的一個函數,但是該類不存在這個函數.同時這個子類函數裡面做了一次bool變數賦值,結果這個值就寫到了堆地址裡面去了.

總結

以後遇到類似問題,直接pageheap full 全開.