首先先了解一下使用率最高的命令：
查看調(diào)用棧：k[b|p|v]
kb顯示三個參數(shù)蠢涝；
kp或kP顯示所有參數(shù)；
kv顯示FPO與調(diào)用約定话侄；
查看數(shù)據(jù)：d{a|b|c|d|D|f|p|q|u|v|w|W}
da: ASCII, du: unicode
dv: 局部變量
dc: DWORD&ASCII
dd: DWORD
dp: 按指針大小值，取決于是x86還是x64
詳細參考https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/d--da--db--dc--dd--dd--df--dp--dq--du--dw--dw--dyb--dyd--display-memor
設置斷點：b
可以針對某個符號下斷點：
bu MyApp!SomeFunction
使用bm的話還支持匹配表達式：
bm user32!CreateWindow*
還有數(shù)據(jù)斷點（指定內(nèi)存被訪問時觸發(fā)）：
ba w4 0x0483def（w為寫操作，4指監(jiān)控訪問位置字節(jié)數(shù)）
設置斷點還有很多高級用法疾牲，具體可參考https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/bp--bu--bm--set-breakpoint-
修改內(nèi)存地址：e
類似于d命令，后面也可以加類型后綴
查看所有模塊信息：lmf衙解，查看某個模塊的詳細信息：lmvm，切換棧幀：.frame舌剂，反匯編指定地址：u
不必多說
在內(nèi)存中搜索符號：dds, dps
這個東西還是有點有用的，特別是調(diào)試某些棧出了問題導致的崩潰問題時暑椰。
https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/dds--dps--dqs--display-words-and-symbols-
現(xiàn)在就看個簡單例子吧霍转，前天同事扔了個minidump給我一汽，讓我看看還能不能搶救一下，用vs看不到啥有用的信息岩喷，就下圖：
雖然vs一般夠用但是這種時候就顯示出無奈了均驶，打開WinDBG設置好符號路徑，將dmp打開爬虱，看一下能不能看到更詳細的調(diào)用棧：
可以看出這個棧就比VS靠譜多了跑筝，不過還是有一些亂七八糟的東西瞒滴，什么Sogoupy都來了妓忍，并不像是真正的崩潰原因。不過可以看到有UnhandledExceptionHandler這個函數(shù)定罢，這個函數(shù)熟悉win32開發(fā)的應該都了解旁瘫，可以幫助在程序發(fā)生異常時捕獲到祖凫，然后做一些事情，比如說寫個dump之類的酬凳。這個函數(shù)的參數(shù)是一個EXCEPTION_POINTERS的結構體宁仔，里面保存了一些系統(tǒng)所捕獲到的異常相關的信息，比如異常代碼完箩，寄存器的值等等拉队，所以可以考慮一下看下這個東西還能不能讀得到：
點一下藍色的02粱快，跳轉(zhuǎn)到UnhandledExceptionHandler所在的棧幀：
可以看到windbg自動幫我們把棧幀內(nèi)的局部變量都顯示出來了，再看一下這個結構體里面有啥東西瓜富，還能不能讀到：
可以看到里面的值基本上還是正常的与柑，并不像是有受過什么破壞的樣子蓄坏。
這個時候來學習一下另外一個知識點涡戳，關于C++編譯器一般情況下對寄存器的使用：
EBP：指向當前棧幀的棧基址
ESP：指向整個棧的椙妒海基址
EIP：指向CPU將執(zhí)行的下一句代碼的地址
ECX：很有可能會指向this指針宝惰，不過由于編譯器優(yōu)化乳丰，并不一定準確
可以看到棧里還保存著另外一套寄存器的信息产园，又知道ESP指向整個棧夜郁，所以嘗試一下能不能在esp的地址中找到一些符號竞端，就用之前介紹的dps命令：
這才是真正的問題出現(xiàn)時的調(diào)用棧事富，與同事確認了應該確實是真正的崩潰原因，收工~
