像微軟自己的 Debug Diagnostic Tool (DebugDiag) 有時也是不錯用的dump工具～
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 Files\DebugDiag\Logs 目錄下的所有檔案，
再執行 DebugDiag 開始做資料收集與分析，比較不會出現奇怪的問題～
也可以直接选择进程
要分析文件可以使用WinDbg工具