首先先了解一下使用率最高的命令：
查看調用棧：k[b|p|v]
kb顯示三個參數；
kp或kP顯示所有參數；
kv顯示FPO與調用約定；
查看數據：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*
還有數據斷點（指定內存被訪問時觸發）：
ba w4 0x0483def（w為寫操作，4指監控訪問位置字節數）
設置斷點還有很多高級用法，具體可參考https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/bp--bu--bm--set-breakpoint-
修改內存地址：e
類似于d命令，后面也可以加類型后綴
查看所有模塊信息：lmf，查看某個模塊的詳細信息：lmvm，切換棧幀：.frame，反匯編指定地址：u
不必多說
在內存中搜索符號：dds, dps
這個東西還是有點有用的，特別是調試某些棧出了問題導致的崩潰問題時。
https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/dds--dps--dqs--display-words-and-symbols-
現在就看個簡單例子吧，前天同事扔了個minidump給我，讓我看看還能不能搶救一下，用vs看不到啥有用的信息，就下圖：
雖然vs一般夠用但是這種時候就顯示出無奈了，打開WinDBG設置好符號路徑，將dmp打開，看一下能不能看到更詳細的調用棧：
可以看出這個棧就比VS靠譜多了，不過還是有一些亂七八糟的東西，什么Sogoupy都來了，并不像是真正的崩潰原因。不過可以看到有UnhandledExceptionHandler這個函數，這個函數熟悉win32開發的應該都了解，可以幫助在程序發生異常時捕獲到，然后做一些事情，比如說寫個dump之類的。這個函數的參數是一個EXCEPTION_POINTERS的結構體，里面保存了一些系統所捕獲到的異常相關的信息，比如異常代碼，寄存器的值等等，所以可以考慮一下看下這個東西還能不能讀得到：
點一下藍色的02，跳轉到UnhandledExceptionHandler所在的棧幀：
可以看到windbg自動幫我們把棧幀內的局部變量都顯示出來了，再看一下這個結構體里面有啥東西，還能不能讀到：
可以看到里面的值基本上還是正常的，并不像是有受過什么破壞的樣子。
這個時候來學習一下另外一個知識點，關于C++編譯器一般情況下對寄存器的使用：
EBP：指向當前棧幀的棧基址
ESP：指向整個棧的?；?br> EIP：指向CPU將執行的下一句代碼的地址
ECX：很有可能會指向this指針，不過由于編譯器優化，并不一定準確
可以看到棧里還保存著另外一套寄存器的信息，又知道ESP指向整個棧，所以嘗試一下能不能在esp的地址中找到一些符號，就用之前介紹的dps命令：
這才是真正的問題出現時的調用棧，與同事確認了應該確實是真正的崩潰原因，收工~
