MemProof（內存清道夫）是AutomatedQA出品的一款非常不錯的檢測內存洩漏和資源洩漏的免費調試工具，適合於WIN32平台下使用DELPHI/C++ BUILDER開發的應用程序。
利 用它可以方便的查找出 一些忘記釋放的指針以及資源。它通過在調試模式下運行目標程序，監視程序的創建和釋放操作，以達到檢測資源洩漏的效果。監測過程中它會根據資源類型計數， 每次創建後增加計數，釋放則遞減計數，最後程序結束根據計數即可判斷出資源的洩漏。
MemProof的原作者是Atanas Stoyanov，後加盟了AutomatedQA公司，他目前是大名鼎鼎的AQTIME軟件的主力開發者。MemProof已經很久沒有更新了，作者在AutomatedQA的官方網站上也推薦大家使用AQTIME（http://www.automatedqa.com/products/aqtime/memproofusers.asp），因為AQTIME包含了MemProof的所有功能，並且擁有很多MemProof所不具備的特性，如：更好的COM支持，結合MSDN獲 取幫助，平台測試等等。雖然有這麼多好處，但是AQTIME畢竟是收費的商業軟件，價格不 菲，而且體積相對龐大。對於我來說，更願意選擇MemProof。輕佻的體積，簡單的操 作，還是免費的（這條最關鍵～～）。當然，對於大的企業用戶來說，AQTIME也是個非常不錯的選擇。
l 下載
官方網站上的最新版本為 (Build 0.950 July 19, 2004)
下載地址：http://www.automatedqa.com/products/memproof/index.asp
l 安裝
MemProof是一個綠色軟件，下載完成後解壓，運行MemProof.exe即可。
l 准備
MemProof要求目標程序帶有完整的調試信息。打開工程選項（Project-Options）
1、 Compiler面板
l 去掉Optimization（代碼優化）選項
l 選擇Stack Frames（為所有過程函數強制生成調用堆棧）選項
l 選擇Debug information (在DCU文件中生成調試信息)選項
l 選擇Use Debug DCUS（編譯時鏈接帶有調試信息的VCL DCU文件）選項
2、 Linker面板
l 選擇Detailed（生成完整的MAP文 件，包含模塊、單元、過程等地址信息）選項
l 選擇Include TD32 debug info（將調試信息生成到可執行文件）選項
該選項會導致可執行文件體積增大，但不會影響運行效率以及內存占用， 建議在正式發布時不要帶上該選項。
l 開始
一切准備就緒，現在可以開始調試了。
下面是用於調試的一段測試程序：
新建一個空白工程，在OnCreate事件中加入以下代碼：
procedure TForm1.FormCreate(Sender: TObject);
begin
TFont.Create; //創 建一個TFONT對象，但不釋放
CloseHandle(0); //關 閉一個不存在的句柄
end;
再根據上面的介紹設置好工程選項。打開MemProof：
Resources – 資源的類型，包括Error(錯誤)、Pointers(指針)、Memory（內存）、GDI（畫布資源）、User（系 統對象）、Kernel（核心對象）、Registry（注冊表）。
Resources Count – 資源數目，Current#代表當前數目，Peak#代表峰值數目
Resources Size – 資源大小，Current#代表當前大小，Peak#代表峰值大小
選擇File-Open 打開要調試的 執行文件，再選擇Run-Run 開始運行，再正常退出目標程序，如果有資源洩漏MemProof會自動打開Resources Details面板：
MemProof共列出5個內存洩漏，我們可以看到每個內存洩漏都有詳細的調用棧情況，以及相對應的源碼位置。
有時它會提示我們找不到對應的源碼，這是應為沒有指定源碼搜索路徑 的原因。MemProof有兩個位置可以設置源碼搜索路徑，一個在Configure- Search Directories，一個在Projects-Search Directories。前者是設置全局路徑，後者是設置當前路徑。一般建議在前者中設置DELPHI的VCL以及共用庫代碼的路徑，後者 設置工程本身源碼的路徑。MemProof還為用戶提供了快捷搜索VCL源 碼路徑的按鈕Get Default for ，使用這個按鈕可以快捷的獲取DELPHI的Libray Path（有的用戶 安裝了VC覆蓋了默認調試工具選項，所以有可能得到的是VC的Libray Path，這種情況可以直接到DELPHI的Libray Path中去拷貝即可）。
另外MemProof還可以記錄上次的測試結果方便用戶做比較，以及過濾等功能。
如果需要測試動態連接庫，可以選擇Project-Parameters，在Host Applications中 選擇主體程序，如果需要帶命令行，則在Parameters中輸入命令行，然後就可以開始測試了，和DELPHI中調試的方法是一樣的。
MemProof不支持Attach Process的 調試方式，這是一個不足的地方。
使用其實非常簡單，一看就明白了，下面介紹些調試中的經驗技巧。
l 漸進式測 試，從最易發現的錯誤開始解決
一個大型的軟件可能會有 很多洩漏或者錯誤，這個時候可以漸進式的來測試，第一次測試可以直接運行後立即退出，檢測在加載的過程中是否存在洩漏，然後逐一更正。再分功能模塊進行測 試，比如只針對某個功能進行操作，然後退出檢測該模塊是否存在洩漏，如果存在，更正。最後再進行整體測試。這樣可以避免一些關聯性錯誤導致重復測試，而且 可以節省測試時間，可以使測試更有針對性。
l 分模塊測 試，從單個的模塊開始解決
和上一條原則一樣，為了 縮小測試面。在Projects的Moudle Configers中 選擇測試的模塊，開始每次只選擇一個模塊針對性測試，最後再選擇所有模塊測試。
注意：不要選擇一些如：Ole32.dll、kernel32.dll等系統模塊。
l 錯誤優 先，發現錯誤與洩漏並存時，優先解決錯誤
測試過程中，
代表錯誤，這些錯誤往往是由於錯誤的使用系統API導 致，如：釋放不存在的句柄，訪問權限不夠的資源，傳遞了錯誤的調用參數等。這些錯誤往往會導致代碼沒有按照預計的方式運行，觸發一些內存洩漏。所以，需要 優先修正這些位置。
l 系統資源 優先，發現有GDI、User、Kernel、Registry等存在洩漏時優先 解決
系統資源洩漏往往是由於窗體、畫布等資源 沒有及時釋放，這些錯誤非常明顯，而且這種錯誤往往會帶有很多的Pointers、Memory洩漏，所以，優先修正。
l 經過實際 證明，下列錯誤是可以忽略的
1、 VirtualAlloc(00000000,4096,4096,64) VirtualAlloc kernel32.dll
這是有名的4096字節內存洩漏問題，任何使用DELPHI的VCL編寫的WIN32程序都會存在，這是由 於在Classes單元中的MakeObjectInstance方法中使用VirtualAlloc分配了4096字節的內存，並沒有釋放。 這不是BUG，不釋放是有原因的，請參考這篇文章：
http://www.thedelphimagazine.com/samples/1328/article.htm
2、OpenFileMapping
OpenFileMapping(4,0,”SMBuffer”) 導致的錯誤是由於BDE數據庫引擎激活時，嘗試OpenFileMapping和Sql Monitor建立鏈接， 但是當Sql Monitor未運行時，這個mapping 並不存在，所以會導致錯誤。這個錯誤已經被VCL所捕獲處理。所以可以忽略。
3、 LoadCursor
VCL並不是完美的，有時運行程序出現很多LoadCursor錯誤也可以忽略。
4、 其他
還有更多的關於DELPHI和C++Builder本身導致的內存洩漏可以參見：
http://www.automatedqa.com/support/leaksd6.asp
l 發現洩漏 的位置在VCL單元中的時候，不要去考究VCL的 代碼，找到調用棧中涉及到的外部單元去檢查。相信VCL吧，絕大多數情況些它是不會導致內存 洩漏的。
MemProof盡管非常優秀，同 樣存在不少缺陷。如上面提到的不能Attach Process，這樣就不能夠調試ISAPI、服務程序等；還有，當程序由於訪問保護內存、或強制結束進程等原因導致非正常退出時，MemProof將不會有任何結果報告；另外，MemProof的機制決定它不可能實現遠程調試；最後，MemProof是個免費性質的軟件，在幫 助支持方面做得不夠，連一個像樣的幫助都沒有，同類的商業軟件BoundCheker在這方面 做得非常不錯，每個錯誤都可以在幫助中得到詳細的解釋，MemProof的這個缺點導致新 手不容易上手。
關於MemProof就介紹到這裡了。 總之，瑕不掩瑜，MemProof依然是廣大DELPHI/C++BUILER愛好者的開發利器。
