之前都是用 xperf 來查 memory leak（參閱這裡），

但是有時候會遇上莫名其妙的瓶頸…

例如最近常常分析完 stack 之後，xperf 給出來的結果是像下面這樣：

可以看到上面 12249 KB 的 memory leak 中，

ntdll.dll!RtlAllocateHeap 就佔了 12001 KB…

但…究竟是誰作了什麼事呼叫到 RtlAllocateHeap 了呢？

xperf 卻沒有列出詳細的 stack trace…

這個問題目前我還沒有找出答案…（若有人知道請告訴我 ^^）

因為上述問題，有時只好找別的工具來找 memory leak…

像微軟自己的 Debug Diagnostic Tool (DebugDiag) 有時也是不錯用的工具～

這邊就簡單記錄一下如何使用吧～

Step 1: 到 DebugDiag 的網頁 下載並安裝 DebugDiag

Step 2: 執行 DebugDiag，選擇 Native (non-.NET) Memory and Handle Leak

Step 3: 選擇要查 memory leak 的 process…

假設這邊我們要查的是 Everything-1.2.1.371.exe～

Step 4: 設定收集資料的的時間長短。這邊 DebugDiag 限定至少要 15 分鐘以上～

Step 5: 設定規則的名字，通常都直接確定就可以了。

Step 6: 若要立刻開始收集資料，就選擇 Activate the rule now（通常都是選這個啦）

Step 7: 如果是第一次執行 DebugDiag 的話，通常就會跳出下面的視窗，

詢問關於 symbol path 的設定，也可以之後再去設～這邊通常就是按 Yes～

Step 8: 全都設定好之後，可以看到如下的畫面～

這個畫面代表規則已經設定好，已經開始追蹤收集資料囉～

DebugDiag 通常會產生兩條規則，

第一條規則是根據設定的時間來追蹤，第二條規則是 process 如果掛掉的話也就停止追蹤。

可以開始做一些測試動作，好讓程式產生 memory leak～

Step 9: 等設定的時間到之後，DebugDiag 會自動產生 user dump file，並將狀態標示為 Completed～

Step 10: 在 Leak Rule 上面按滑鼠右鍵，選擇 Analyze Data 開始分析 memory leak～

Step 11: 分析完了之後，DebugDiag 會產生一個 .mht 檔，並自動用瀏覽器開啟它～

如果 DebugDiag 有找到 memory leak 的話，

通常可以在最上面的 Analysis Summary 那邊看到相關的 warning，

如果有正確的 symbol 的話也會列出相關的函式名稱～

這樣子的話，就可以針對被列出來的函式仔細檢查了，

當然也可以把整個報告都仔細先看過一次，看看 DebugDiag 是否有提供什麼其他的資訊～

Tip: 建議在執行 DebugDiag 之前，先停掉 Debug Diagnostic Service (DbgSvc) 這個服務，

並清除掉 C:Program FilesDebugDiagLogs 目錄下的所有檔案，

再執行 DebugDiag 開始做資料收集與分析，比較不會出現奇怪的問題～

這次的 DebugDiag 初步使用就到這邊囉～～ :)