前言：windbg大家都很熟悉，它是做windows系統客戶端測試的QA人員很應該掌握的定位程序崩潰原因的工具，
網上也有很多資料，但是真正適合QA閱讀和實用的資料不多，我把我認為最重要最應該掌握的結合以前的使用經驗分享一下：
基礎篇
1、 打開windbg，打開dmp文件，File——〉open crash dump（其實有更方便的方法，后面會說）
2、 設置符號下載路徑和加載路徑，File——〉symbol file path，輸入srv*d:\symbolslocal*http://msdl.microsoft.com/download/symbols，中間這個路徑可以隨意設置，如果有其他符號路徑，比如產品的模塊PDB，加分號分隔即可。
符號是可以定位到具體函數，甚至具體錯在哪一行代碼的。在分析過程中只要dmp中牽涉到相關的微軟模塊的pdb都會被下載和加載。網上也有“集合版”的pdb，可以自行搜索，但是符號對應模塊的版本不一定適合。
3、 彈出一個workspace的對話框，選什么都無所謂，yes、no都一樣，不需要關注
4、 打開dump以后可以看到命令行窗口，如下圖打開一個IE的dump文件:
5、 上圖最下方的輸入窗口就是用來輸入調試命令的
6、 第一條命令: !analyze –v，回車，這條命令是萬金油，可以自動分析大概是誰導致的崩潰，那么它執行后要關注什么內容？看下圖
7、 上圖應該怎么看？從下往上看！這里面就是崩潰時內存里面的模塊的執行過程。注意看“Following XXX”，字面意思是接下來的段可以錯了，程序在這里崩潰了的意思，因為是從下往上走的，所以“Following XXX”上方的內容就是崩潰后的東西，而“Following XXX”下方的內容就是導致崩潰的“原因”，越接近“Following XXX”的越代表有可能是導致崩潰的直接模塊，但是這不一定。如果抓到的dmp時機太遲，會出現堆棧破壞的情景，那么“Following XXX”得到的內容可能就是錯誤的了，那么這個dmp意義就不大，當然QA可以不關注這個，要關注的是如何讓自己抓dmp的時機更及時。
8、 第二條命令：kb，回車，這條命令是上面的補充，用來顯示當前線程call stack（調用棧）的內容，它可以查看更詳細的內存信息，更好的定位崩潰原因，比如上圖內容看不到360相關的東西，是不是說這個崩潰和360沒關系呢？不一定！看kb的內容
9、 記住從下往上看！上圖可以看到是IE調用了safemon.dll的函數后才開始創建dmp的，是不是有理由懷疑這個崩潰和網盾有關了？提BUG吧！
10、 可惜我們只看到和網盾有關，但是具體是網盾什么函數、什么參數導致的都看不到，如何看？這時就看出符號文件的重要性了！
Ps：還有一個命令是~*kb ，它用來顯示dump中所有線程的call stack， 一般用到它說明這個dump已經比較難看了，可以從命令結果中搜索KiUserExceptionDispatcher等關鍵字，一般可以認為存在KiUserExceptionDispatcher的線程就是導致崩潰的線程。
高級篇
1、 設置DMP類型文件關聯用windbg打開
a) cmd到windbg目錄運行windbg –IA
2、 手動抓DMP的方法：
a) 如果程序崩潰后沒有DMP文件生成可采取下面方法轉存DUM。
b) 當程序崩潰還沒有退出的時候，開啟WINDEBUGGER程序，在FILE——執行attach to a process——選擇崩潰的進程。
c) 再執行.dump /ma C:\testdump.dmp（如果沒有/ma，dump大小比較小）
3、自動抓DMP的方法：
a) cmd到windbg目錄運行 windbg -IS
b) 進行導致崩潰的操作
c) 即可抓到dmp，執行.dump /ma C:\testdump.dmp
4、 使用windbg調起進程調試
a) 開啟WINDEBUGGER程序，在FILE——執行Open Executable——選擇要進行調試的進程文件
b) 當進程沒有自保護或者沒有反調試時，在input框輸入g，回車，即可打開進程，此時如果進程發生崩潰，會被立即捕捉到。這種方法拿到的dmp比第二種更好。
5、 設置Global Flags，自動attach進程。Global Flags（簡稱gflags），設置它之后，目標進程啟動時會立即被attach，主要用於調試一些系統進程，或“有依賴的”進程，這些進程不能直接由方法4打開，只能由其他進程調用，而調用用立即崩潰，所以也不能用方法2。這個方法同時可以設置很多檢查項。
