windbg 查看结构体_用WinDbg进行调试
通往WinDbg的捷徑(一)
windbg的使用詳細(xì):
http://wenku.baidu.com/view/f576c31e650e52ea55189832.html
導(dǎo)言
你鐘情什么樣的調(diào)試器？如果你問我這個問題，我會回答是“Visual?Studio?+?WinDbg”。我比較喜歡Visual?Studio那樸實(shí)無華且易操作的接口，更喜歡它能迅速把我需要的信息以可視的形式展示出來。但遺憾的是，Visual?Studio調(diào)試器無法獲取某些信息。例如，假設(shè)我想知道哪個線程正在占用特殊的臨界區(qū)？或者是哪個函數(shù)占用了大部分的棧空間？不用擔(dān)心，有WinDbg呢。它的命令能回答這些問題，以及調(diào)試過程中出現(xiàn)的其它有趣的問題。甚至不退出Visual?Studio，WinDbg就可以附上目標(biāo)應(yīng)用程序――謝謝WinDbg支持入侵模式的調(diào)試(本文后面會詳細(xì)討論)，我們可以把Visual?Studio?GUI和WinDbg的命令行結(jié)合起來使用。
唯一的問題是WinDbg不太好用。需要花些時(shí)間適應(yīng)它的用戶界面，而掌握它的命令則要花更多的時(shí)間。但是假設(shè)你現(xiàn)在就需要它，馬上用它調(diào)試緊急的問題？有什么快速簡便的方法嗎？當(dāng)然。WinDbg的小弟CDB，功能和WinDbg差不多；因?yàn)樗腔诿钚械?#xff0c;所以用起來更簡單一些。在這篇文章里，我將把CDB作為Visual?Studio調(diào)試器的補(bǔ)充，介紹怎樣使用CDB。在這篇文章里，你將會看到怎樣配置CDB，怎樣用它解決實(shí)際的問題。另外，我還會提供一些批處理文件，它們可以隱藏CDB命令行接口的大部分復(fù)雜性，也讓你少打幾個字。
安裝與配置
安裝
當(dāng)然，在使用CDB前，必須先安裝并配置它。WinDbg和CDB是Debugging?Tools?for?Windows的一部分，可以從這里下載。安裝很簡單，你可以用默認(rèn)設(shè)置安裝，除非你準(zhǔn)備用WinDbg?SDK開發(fā)應(yīng)用程序。(如果你準(zhǔn)備用SDK，需要選擇定制安裝，并啟用SDK安裝；推薦你把它安裝在不包含空格的目錄名的目錄中)。安裝完成后，安裝目錄里將包含所有必需的文件，包括WinDbg(windbg.exe)和CDB(cdb.exe)。
調(diào)試工具也支持“xcopy”類型的安裝。也就是說，在一臺機(jī)器上安裝后，如果你想在其它的機(jī)器上使用，不用再安裝，直接把已經(jīng)安裝的目錄直接拷過去就行了。
符號文件服務(wù)器路徑
如果不能訪問操作系統(tǒng)DLL的最新的符號文件，有些重要的WinDbg命令將不能正常工作。在以往，我們可以從微軟的FTP服務(wù)器上下載巨大的符號文件包，然后從中找出需要的符號文件。這非常浪費(fèi)時(shí)間，而且在操作系統(tǒng)更新或升級后，符號文件就過時(shí)了(因此也就變得毫無用處)。幸運(yùn)的是，現(xiàn)在有更簡便的方法來獲得符號文件――符號文件服務(wù)器。WinDbg和Visual?Studio都支持這個方法，在需要時(shí)直接從微軟維護(hù)的服務(wù)上下載最新的符號文件。有了符號文件服務(wù)器，我們再也不用下載整個符號文件包了(那實(shí)在是太大了)，因?yàn)檎{(diào)試器知道需要用到哪個DLLs，所以直接下載單個符號文件就行了。如果符號文件在操作系統(tǒng)更新或升級以后過時(shí)了，調(diào)試器會注意到這種情形，并再次下載必需的符號文件。
為了使符號文件服務(wù)器起作用，我們應(yīng)該讓調(diào)試器知道符號文件服務(wù)器的路徑。最簡單的方法是在_NT_SYMBOL_PATH環(huán)境變量里指定符號文件服務(wù)器的路徑。可以用如下的路徑：
"srv*c:\symbolcache*http://msdl.microsoft.com/download/symbols"
(c:\symbolcache目錄將被用來保存從符號文件服務(wù)器下載下來的符號文件；當(dāng)然，你可以用任何有效的本地或網(wǎng)絡(luò)路徑)。例如：
set?_NT_SYMBOL_PATH=srv*c:\symbols*http://msdl.microsoft.com/download/symbols
在你設(shè)置_NT_SYMBOL_PATH環(huán)境變量之后，就可以使用符號文件服務(wù)器了。關(guān)于符號文件服務(wù)器的更多信息，相關(guān)設(shè)置，以及可能會用到的排除故障的小技巧，可以從WinDbg的文檔中找到(Debuggers?|?Symbols?section)。
如果你需要從一臺需登錄的代理服務(wù)器后訪問符號文件服務(wù)器。參見本篇文章中CDB?and?proxy?servers部分，以了解更多信息。
CDB?命令行基礎(chǔ)介紹
啟動調(diào)試會話
當(dāng)我們使用新的調(diào)試器時(shí)，第一個問題通常是：怎樣開始調(diào)試會話呢？像大多數(shù)調(diào)試器一樣，CDB允許我們調(diào)試應(yīng)用程序的新實(shí)例，或者附上一個已經(jīng)運(yùn)行的過程。啟動新實(shí)例就象下面一樣簡單：
cdb?c:\myapp.exe
如果我們想附上已經(jīng)運(yùn)行的過程，可能會用上下列某個選項(xiàng)：
----------------------------------------------------------------------------------------------------------------------
選項(xiàng)????????????????描述????????????????????????????????????????????????????????????????????????????例子
----------------------------------------------------------------------------------------------------------------------
-p?Pid??????????????這個選項(xiàng)允許CDB附上指定進(jìn)程ID的進(jìn)程。可以用任務(wù)管理器或類似的工具得到進(jìn)程ID。???cdb?-p?1034
----------------------------------------------------------------------------------------------------------------------
-pn?ExeName?????????這個選項(xiàng)允許CDB用指定的可執(zhí)行文件名(.exe)附上進(jìn)程。這個選項(xiàng)比“-p?Pid”更
方便，因?yàn)槲覀兺ǔＶ缊?zhí)行的程序名，不必在任務(wù)管理器中尋找進(jìn)程的ID。但是如果
多個進(jìn)程使用同一個名字(CDB將報(bào)錯)，就不能用這個選項(xiàng)了。???????????????????????cdb?-pn?myapp.exe
----------------------------------------------------------------------------------------------------------------------
-psn?ServiceName????這個選項(xiàng)允許CDB附上指定服務(wù)的進(jìn)程。例如，假如你想附上Windows?Management
Instrumentation服務(wù)，應(yīng)該用WinMgmt作為服務(wù)名。??????????????????????????????????cdb?-psn?MyService
----------------------------------------------------------------------------------------------------------------------
CDB也可以分析故障轉(zhuǎn)儲。用-z選項(xiàng)打開故障轉(zhuǎn)儲：
cdb?-z?DumpFile
例如：
cdb?-z?c:\myapp.dmp
結(jié)束調(diào)試會話
啟動新的調(diào)試會話后，CDB會顯示它自己的命令行提示符。你可以在這個提示符下執(zhí)行CDB支持的任何命令。
??
'q'命令結(jié)束調(diào)試會話并退出CDB：
0:000>?q
quit:
>
警告：當(dāng)你結(jié)束調(diào)試會話，退出CDB時(shí)，操作系統(tǒng)也將終止被調(diào)試的程序。如果你想退出CDB并保持被調(diào)試程序，可以用.detach命令(Windows?XP或更新的操作系統(tǒng)才支持)，或者用非入侵的模式(下面討論)。
運(yùn)行命令
雖然可以在CDB命令行提示符下執(zhí)行調(diào)試器命令，但在命令行里指定需要的命令通常更快一些，用-c選項(xiàng)。
cdb?-pn?myapp.exe?-c?"command1;command2"
(用分號分隔多個命令)
例如，下列命令行將把CDB附上我們的應(yīng)用程序，顯示已加載的模塊，然后退出：
cdb?-pn?myapp.exe?-c?"lm;q"
注意，在命令列表的結(jié)尾加上'q'命令――將在所有的調(diào)試器命令執(zhí)行后關(guān)閉CDB。
入侵模式調(diào)試
在默認(rèn)情況下，當(dāng)我們用CDB調(diào)試一個已經(jīng)運(yùn)行的進(jìn)程時(shí)，它通常作為全功能的調(diào)試器附上進(jìn)程(使用Win32?Debugging?API)。在這種模式下，可以設(shè)置斷點(diǎn)，單步調(diào)試代碼，得到各種調(diào)試事件的通知(例如，異常，加載/卸載模塊，啟動/退出線程，等等)。Visual?Studio也可以做到這些，并提供更友好的用戶界面。另外，每個進(jìn)程每次只能被一個調(diào)試器附上。這是否意味著如果我們用Visual?Studio調(diào)試器調(diào)試應(yīng)用程序，就不能再用CDB得到它的附加信息了？不，不完全是這樣，因?yàn)槌巳δ苷{(diào)試模式外，CDB還支持入侵調(diào)試模式。
CDB以入侵模式附上目標(biāo)進(jìn)程時(shí)，并沒有使用Win32?Debugging?API，而是先暫停目標(biāo)進(jìn)程的所有線程，執(zhí)行用戶指定的命令。在所有的命令執(zhí)行之后，CDB退出之前，恢復(fù)暫停的線程。因此，目標(biāo)進(jìn)程可以繼續(xù)運(yùn)行，好像什么事也沒發(fā)生一樣。即使像Visual?Studio之類的全功能調(diào)試器正在調(diào)試目標(biāo)進(jìn)程，CDB仍可以用入侵模式附上它，并獲得所需要的信息。在CDB完成任務(wù)并分離附上的進(jìn)程后，我們可以繼續(xù)用Visual?Studio調(diào)試器調(diào)試這個應(yīng)用程序。
怎么啟用CDB的入侵模式？用-pv命令行選項(xiàng)。例如，下列命令行將以入侵模式附上應(yīng)用程序，顯示已加載模塊的列表，然后退出。在CDB退出之后，應(yīng)用程序?qū)⒗^續(xù)運(yùn)行。
cdb?-pv?-pn?myapp.exe?-c?"lm;q"
把輸出內(nèi)容保存到日志文件
有些CDB命令的輸出內(nèi)容可能會很長，從控制臺窗口閱讀十分不便。因此，把輸出內(nèi)容保存到日志文件，再用其它的編輯器查看會更好一些，CDB允許我們用-loga和-logo選項(xiàng)來實(shí)現(xiàn)('-loga?'把輸出內(nèi)容追加到指定文件的結(jié)尾；而'-logo?'將覆蓋原有的文件，如果文件已經(jīng)存在的話)。
在我們的例子命令(列出目標(biāo)進(jìn)程里的模塊)里增加記錄功能，把輸出內(nèi)容保存到當(dāng)前目錄的out.txt文件里：
cdb?-pv?-pn?myapp.exe?-logo?out.txt?-c?"lm;q"
源行號信息
CDB支持的另外一個重要選項(xiàng)是-lines。這個選項(xiàng)打開源行號信息支持，例如，當(dāng)報(bào)告調(diào)用棧時(shí)，允許CDB顯示源文件及源行號。(在默認(rèn)情況下，源行號支持是關(guān)閉的，CDB不顯示源文件/行號信息)。
CDB?和代理服務(wù)器
如果你在需要登錄的代理服務(wù)器后用CDB，在默認(rèn)情況下，將不能訪問符號文件服務(wù)器。原因是在默認(rèn)配置下，當(dāng)CDB嘗試連接符號文件服務(wù)器時(shí)，不顯示代理服務(wù)器的登錄提示。為了更改這個行為，使我們可以訪問符號文件服務(wù)器，需要在命令行之前加上兩條命令：
!sym?prompts;.reload
例如：
cdb?-pv?-pn?myapp.exe?-logo?out.txt?-c?"!sym?prompts;.reload;lm;q"
啟動消息
當(dāng)CDB調(diào)試新應(yīng)用程序，附上已經(jīng)存在的進(jìn)程，或打開故障轉(zhuǎn)儲時(shí)，將顯示一系列的啟動消息。CBD命令(可以用-c選項(xiàng)指定，或手動輸入)的輸出內(nèi)容跟在這些消息之后。通常情況下，啟動消息只顯示一些無關(guān)緊要信息；但是如果在執(zhí)行時(shí)出錯了，它將包含這個問題的描述，有時(shí)候也會提供解決方法。
例如，下列輸出內(nèi)容通知我們沒有設(shè)置符號路徑，因此，有些調(diào)試器命令不能工作：
D:\Progs\DbgTools>cdb?myapp.exe
Microsoft?(R)?Windows?Debugger??Version?6.5.0003.7
Copyright?(c)?Microsoft?Corporation.?All?rights?reserved.
CommandLine:?myapp.exe
Symbol?search?path?is:?***?Invalid?***
****************************************************************************
*?Symbol?loading?may?be?unreliable?without?a?symbol?search?path.???????????*
*?Use?.symfix?to?have?the?debugger?choose?a?symbol?path.???????????????????*
*?After?setting?your?symbol?path,?use?.reload?to?refresh?symbol?locations.?*
****************************************************************************
總結(jié)
這里是一些常見的CDB命令行模板，本篇文章的剩下部分將會用到它們(我們總是用同樣的模板，然后根據(jù)我們要解決的問題，改變-c選項(xiàng)內(nèi)部的命令行列表)。
用入侵模式附上運(yùn)行的進(jìn)程(通常是進(jìn)程ID)，執(zhí)行一組命令，并把輸出內(nèi)容保存在out.txt文件里：
cdb?-pv?-p?-logo?out.txt?-lines?-c?"command1;command2;...;commandN;q"
用入侵模式附上運(yùn)行的進(jìn)程(用可執(zhí)行文件名)，執(zhí)行一組命令，并把輸出內(nèi)容保存在out.txt文件里：
cdb?-pv?-pn?-logo?out.txt?-lines?-c?"command1;command2;...;commandN;q"
用入侵模式附上運(yùn)行的進(jìn)程(通常是服務(wù)名)，執(zhí)行一組命令，并把輸出內(nèi)容保存在out.txt文件里：
cdb?-pv?-psn?-logo?out.txt?-lines?-c?"command1;command2;...;commandN;q"
打開故障轉(zhuǎn)儲文件，執(zhí)行一組命令，并把輸出內(nèi)容保存在out.txt文件里：
cdb?-z?-logo?out.txt?-lines?-c?"command1;command2;...;commandN;q"
如果我們在需要登錄的代理服務(wù)器后使用CDB，要訪問符號文件服務(wù)器，需要增加兩條命令。例如：
cdb?-pv?-pn?-logo?out.txt?-lines?-c?"!sym?prompts;.reload;command1;command2;...;commandN;q"
好像要打好多字？其實(shí)不是這樣，稍后，我將提供一些批處理文件，它們將為我們隱藏重復(fù)的命令行選項(xiàng)，把要我們輸入的內(nèi)容減至最小。
解決實(shí)際的問題
調(diào)試死鎖問題
當(dāng)我們的應(yīng)用程序掛起或停止響應(yīng)時(shí)，最自然的問題是：它現(xiàn)在正在做什么？它在哪里被困住了？當(dāng)然，我們可以用Visual?Studio調(diào)試器附上應(yīng)用程序，檢查所有線程的調(diào)用棧。但我們同樣可以用CDB，而且會更快一些。下列命令將使CDB以入侵模式附上應(yīng)用程序，打印所有的調(diào)用棧，把結(jié)果保存在日志文件里，然后退出：
cdb?-pv?-pn?myapp.exe?-logo?out.txt?-lines?-c?"~*kb;q"
('kb'命令要求CDB打印當(dāng)前線程的調(diào)用棧；'~*'前綴要求CDB在進(jìn)程所有已存在的線程里重復(fù)執(zhí)行'kb'命令)。
[/URL]?DeadLockDemo.cpp是一個演示典型的死鎖問題的例子。如果你編譯并運(yùn)行，它的工作線程馬上會被困住，如果我們運(yùn)行上述的命令來查看應(yīng)用程序的線程正在做什么，將看到下列類似的內(nèi)容(在這，以及后面，我們將省略啟動消息)：
.??0??Id:?6fc.4fc?Suspend:?1?Teb:?7ffdf000?Unfrozen
ChildEBP?RetAddr??Args?to?Child
0012fdf8?7c90d85c?7c8023ed?00000000?0012fe2c?ntdll!KiFastSystemCallRet
0012fdfc?7c8023ed?00000000?0012fe2c?0012ff54?ntdll!NtDelayExecution+0xc
0012fe54?7c802451?0036ee80?00000000?0012ff54?kernel32!SleepEx+0x61
0012fe64?004308a9?0036ee80?a0f63080?01c63442?kernel32!Sleep+0xf
0012ff54?00432342?00000001?003336e8?003337c8?DeadLockDemo!wmain+0xd9
[c:\tests\deadlockdemo\deadlockdemo.cpp?@?154]
0012ffb8?004320fd?0012fff0?7c816d4f?a0f63080?DeadLockDemo!__tmainCRTStartup+0x232
[f:\rtm\vctools\crt_bld\self_x86\crt\src\crt0.c?@?318]
0012ffc0?7c816d4f?a0f63080?01c63442?7ffdd000?DeadLockDemo!wmainCRTStartup+0xd
[f:\rtm\vctools\crt_bld\self_x86\crt\src\crt0.c?@?187]
0012fff0?00000000?0042e5aa?00000000?78746341?kernel32!BaseProcessStart+0x23
1??Id:?6fc.3d8?Suspend:?1?Teb:?7ffde000?Unfrozen
ChildEBP?RetAddr??Args?to?Child
005afc14?7c90e9c0?7c91901b?000007d4?00000000?ntdll!KiFastSystemCallRet
005afc18?7c91901b?000007d4?00000000?00000000?ntdll!ZwWaitForSingleObject+0xc
005afca0?7c90104b?004a0638?00430b7f?004a0638?ntdll!RtlpWaitForCriticalSection+0x132
005afca8?00430b7f?004a0638?005afe6c?005afe78?ntdll!RtlEnterCriticalSection+0x46
005afd8c?00430b15?005aff60?005afe78?003330a0?DeadLockDemo!CCriticalSection::Lock+0x2f
[c:\tests\deadlockdemo\deadlockdemo.cpp?@?62]
005afe6c?004309f1?004a0638?f3d065d5?00334fc8?DeadLockDemo!CCritSecLock::CCritSecLock+0x35
[c:\tests\deadlockdemo\deadlockdemo.cpp?@?90]
005aff6c?004311b1?00000000?f3d06511?00334fc8?DeadLockDemo!ThreadOne+0xa1
[c:\tests\deadlockdemo\deadlockdemo.cpp?@?182]
005affa8?00431122?00000000?005affec?7c80b50b?DeadLockDemo!_callthreadstartex+0x51
[f:\rtm\vctools\crt_bld\self_x86\crt\src\threadex.c?@?348]
005affb4?7c80b50b?003330a0?00334fc8?00330001?DeadLockDemo!_threadstartex+0xa2
[f:\rtm\vctools\crt_bld\self_x86\crt\src\threadex.c?@?331]
005affec?00000000?00431080?003330a0?00000000?kernel32!BaseThreadStart+0x37
2??Id:?6fc.284?Suspend:?1?Teb:?7ffdc000?Unfrozen
ChildEBP?RetAddr??Args?to?Child
006afc14?7c90e9c0?7c91901b?000007d8?00000000?ntdll!KiFastSystemCallRet
006afc18?7c91901b?000007d8?00000000?00000000?ntdll!ZwWaitForSingleObject+0xc
006afca0?7c90104b?004a0620?00430b7f?004a0620?ntdll!RtlpWaitForCriticalSection+0x132
006afca8?00430b7f?004a0620?006afe6c?006afe78?ntdll!RtlEnterCriticalSection+0x46
006afd8c?00430b15?006aff60?006afe78?003332e0?DeadLockDemo!CCriticalSection::Lock+0x2f
[c:\tests\deadlockdemo\deadlockdemo.cpp?@?62]
006afe6c?00430d11?004a0620?f3e065d5?00334fc8?DeadLockDemo!CCritSecLock::CCritSecLock+0x35
[c:\tests\deadlockdemo\deadlockdemo.cpp?@?90]
006aff6c?004311b1?00000000?f3e06511?00334fc8?DeadLockDemo!ThreadTwo+0xa1
[c:\tests\deadlockdemo\deadlockdemo.cpp?@?202]
006affa8?00431122?00000000?006affec?7c80b50b?DeadLockDemo!_callthreadstartex+0x51
[f:\rtm\vctools\crt_bld\self_x86\crt\src\threadex.c?@?348]
006affb4?7c80b50b?003332e0?00334fc8?00330001?DeadLockDemo!_threadstartex+0xa2
[f:\rtm\vctools\crt_bld\self_x86\crt\src\threadex.c?@?331]
006affec?00000000?00431080?003332e0?00000000?kernel32!BaseThreadStart+0x37
調(diào)用棧(和源行號)暗示ThreadOne正在占用臨界區(qū)CritSecOne并等待臨界區(qū)CritSecTwo，然而ThreadTwo正占用臨界區(qū)CritSecTwo并等待臨界區(qū)CritSecOne。這是典型的“l(fā)ock?acquisition?order”死鎖例子，在那里，兩個線程需要得到同一組同步的對象，以不同的順序使用。如果你想避免這種類型的死鎖，必須保證所有的線程以相同的順序得到所需的同步對象(在這個例子里，ThreadOne和ThreadTwo能同意首先得到CritSecOne，然后得到CritSecTwo來避免死鎖)。
在默認(rèn)情況下，'kb'命令只顯示調(diào)用棧的前20幀。如果你想查看更多的棧幀，你可以顯式指明顯示的棧幀數(shù)量(例如，'kb100'命令要求調(diào)試器顯示100幀)。在WinDbg會話里，可以用.kframes命令改變隨后命令的默認(rèn)限制。
我們的例子只包含了三個簡單的線程，很容易看出哪個線程應(yīng)該為死鎖負(fù)責(zé)。在大應(yīng)用程序里，很難找出可疑的線程并進(jìn)行驗(yàn)證。那我們應(yīng)該怎么做呢？在大部分情況下，我們應(yīng)該知道那個沒有正常運(yùn)轉(zhuǎn)的線程(否則，我們怎么會注意到應(yīng)用程序出現(xiàn)異常了呢？)。通常，這個線程是在等待同步對象，這個對象因?yàn)槟承┰驎簳r(shí)不可用。這個對象為什么不可用呢？如果我們知道哪個線程正在占用這個對象(擁有它，換句話說)，應(yīng)該能答出這個問題。如果這個對象碰巧在臨界區(qū)，!locks命令應(yīng)該能幫助我們識別出它的當(dāng)前所有者。當(dāng)不帶參數(shù)使用時(shí)，這條命令顯示應(yīng)用程序線程正在占用的臨界區(qū)的列表。輸出的內(nèi)容不包括已釋放的臨界區(qū)。
讓我看看實(shí)際使用中的!locks命令：
cdb?-pv?-pn?myapp.exe?-logo?out.txt?-lines?-c?"!locks;q"
下面是這條命令的輸出內(nèi)容(同樣以DeadLockDemo.cpp為例)：
CritSec?DeadLockDemo!CritSecOne+0?at?004A0620
LockCount??????????1
RecursionCount?????1
OwningThread???????3d8
EntryCount?????????1
ContentionCount????1
***?Locked
CritSec?DeadLockDemo!CritSecTwo+0?at?004A0638
LockCount??????????1
RecursionCount?????1
OwningThread???????284
EntryCount?????????1
ContentionCount????1
***?Locked
仔細(xì)查看了40個臨界區(qū)
查看!locks命令的輸出(尤其是OwningThread字段)，我們可以推斷出臨界區(qū)CritSecOne被ID為0x3d8的線程占用，臨界區(qū)CritSecTwo被ID為0x284的線程占用。我們可以在'kb'命令的輸出內(nèi)容(在前面的輸出里)里找出這些IDs對應(yīng)的線程。
如果應(yīng)用程序使用其它種類的同步對象(例如，互斥)，識別它們的所有者將更難一些(需要內(nèi)核調(diào)試器)，我準(zhǔn)備在以后的文章中再介紹這部分內(nèi)容。
調(diào)試CPU高消耗的問題
對大多數(shù)軟件來說，太高的CPU消耗率(根據(jù)任務(wù)管理器的顯示，在單CPU上接近100%)明顯指出軟件中有bug。通常意味著應(yīng)用程序的某個線程陷入了死循環(huán)。當(dāng)然，調(diào)試這個問題的、最普通的方法是用Visual?Studio調(diào)試器附上這個進(jìn)程，查找哪個線程在搗亂。但是我們應(yīng)該檢查哪個線程呢？CDB為我們提供了簡便的方法――!runaway命令。當(dāng)不帶參數(shù)使用時(shí)，這條命令顯示應(yīng)用程序每個線程執(zhí)行用戶模式代碼時(shí)所花的時(shí)間(使用另外的參數(shù)，可以顯示在內(nèi)核模式下所花的時(shí)間，自線程啟動后占用的時(shí)間等)。
如下是在CDB下使用這條命令的示例：
cdb?-pv?-pn?myapp.exe?-logo?out.txt?-c?"!runaway;q"
下面是!runaway命令的輸出示例：
0:000>?!runaway
User?Mode?Time
Thread???????Time
1:358???????0?days?0:00:47.408
2:150???????0?days?0:00:03.495
0:d8????????0?days?0:00:00.000
看起來好像是ID為0x358的線程占用了大部分的CPU時(shí)間。但這個消息還不足以證明線程0x358就是罪魁禍?zhǔn)?#xff0c;因?yàn)檫@條命令顯示的CPU時(shí)間是線程在它整個生命期中所花的。我們還需要進(jìn)一步查看線程所用CPU時(shí)間的變化情況。讓我們再次運(yùn)行這條命令。這次，我們可以看到類似于下列的內(nèi)容：
0:000>?!runaway
User?Mode?Time
Thread???????Time
1:358???????0?days?0:00:47.408
2:150???????0?days?0:00:06.859
0:d8????????0?days?0:00:00.000
現(xiàn)在，我們可以把這個輸出內(nèi)容與上次的輸出內(nèi)容做個比較，找出CPU時(shí)間增長最快的線程。在這個例子里，很明顯就是線程0x150。現(xiàn)在，我們可以用Visual?Studio調(diào)試器附上這個應(yīng)用程序，切換到這個線程下，檢查它為什么轉(zhuǎn)個不停。
調(diào)試棧溢出
當(dāng)我們想找出棧溢出異常的原因時(shí)，CDB也非常有幫助。當(dāng)然，無控制的遞歸調(diào)用是棧溢出最典型的原因，通常來說，查看損壞了的線程的調(diào)用棧，找出它從哪里脫離控制就可以了。Visual?Studio在這方面可以做的很好，那為什么還要用CDB呢？讓我們設(shè)想一個更復(fù)雜的例子。例如，假設(shè)我們的應(yīng)用程序中包含一個依賴遞歸的算法？我們在設(shè)計(jì)算法時(shí)使用有符號數(shù)，在所有可能的情形下控制遞歸的運(yùn)行，但某個時(shí)候棧仍溢出了。為什么？或許是因?yàn)樵谀撤N情況下，算法使用的某些函數(shù)占用了太多的棧空間。我們怎么確定函數(shù)占用的總的棧空間呢？不幸地是，Visual?Studio調(diào)試器沒有簡便的方法可以做到。
即使調(diào)用棧沒有顯示任何遞歸的跡象時(shí)，應(yīng)用程序也可能會出現(xiàn)棧溢出異常。例如，查看StackOvfDemo.cpp例子。如果你編譯，并在調(diào)試器下運(yùn)行它，將立刻出現(xiàn)棧溢出。但此刻的調(diào)用棧看起來一切正常：
StackOvfDemo.exe!_woutput
StackOvfDemo.exe!wprintf
StackOvfDemo.exe!ProcessStringW
StackOvfDemo.exe!ProcessStrings
StackOvfDemo.exe!main
StackOvfDemo.exe!mainCRTStartup
KERNEL32.DLL!_BaseProcessStart@4
顯然，調(diào)用棧上的某個函數(shù)使用了太多的棧空間。但是我們怎么找出這個函數(shù)呢？不用擔(dān)心，有了CDB的'kf'命令的幫助，可以顯示每個函數(shù)在調(diào)用棧上占用的字節(jié)數(shù)。在應(yīng)用程序還停在Visual?Studio調(diào)試器里的時(shí)候，我們可以運(yùn)行下列命令：
cdb?-pv?-pn?stackovfdemo.exe?-logo?out.txt?-c?"~*kf;q"
('kf'默認(rèn)顯示調(diào)用棧上最后的20幀，像我們在“調(diào)試死鎖問題”部分討論的那樣。如果你想多顯示一些，可以增加前綴，例如，~*kf1000。另外要注意的是，~*kf將報(bào)告所有線程的調(diào)用棧。如果應(yīng)用包含大量的線程，它就不太適合了，這時(shí)，可以把它改成'~~[tid]kf',?'tid'是目標(biāo)線程的線程ID(例如，'~~[0x3a8]kf'))
這條命令顯示的內(nèi)容如下：
.??0??Id:?210.3a8?Suspend:?1?Teb:?7ffde000?Unfrozen
Memory??ChildEBP?RetAddr
00033440?0041aca5?StackOvfDemo!_woutput+0x22
44?00033484?00415eed?StackOvfDemo!wprintf+0x85
d8?0003355c?00415cc5?StackOvfDemo!ProcessStringW+0x2d
fc878?0012fdd4?00415a44?StackOvfDemo!ProcessStrings+0xe5
108?0012fedc?0041c043?StackOvfDemo!main+0x64
e4?0012ffc0?7c4e87f5?StackOvfDemo!mainCRTStartup+0x183
30?0012fff0?00000000?KERNEL32!BaseProcessStart+0x3d
注意第一列的內(nèi)容――它報(bào)告棧上函數(shù)所占用的字節(jié)數(shù)。很顯然，ProcessStrings函數(shù)用了可用棧空間的最大份額，因此，它可能要為棧溢出負(fù)責(zé)。
如果你想知道ProcessStrings函數(shù)為什么需要如此多的棧空間，這里有一些解釋。這個函數(shù)使用ATL的A2W宏把字符串從ANSI格式轉(zhuǎn)換成Unicode格式，這個宏在內(nèi)部用_alloca函數(shù)在棧上分配內(nèi)存。用_alloca分配的內(nèi)存只有當(dāng)它的調(diào)用者(在這個例子里是ProcessStrings)返回后才被釋放。直到ProcessStrings返回控制之前，A2W(因此，也就是_alloca)在棧上為每個后續(xù)的調(diào)用分配另外的空間，這將迅速耗盡棧空間。
底線：不要在循環(huán)里使用_alloca。
標(biāo) 題:翻譯：通往WinDbg的捷徑(二)
翻 譯:arhat
時(shí) 間:2006-04-14 22:54
鏈 接:詳細(xì)信息:
通往WinDbg的捷徑(二)
原文：http://www.debuginfo.com/articles/easywindbg2.html
譯者：arhat
時(shí)間：2006年4月14日
關(guān)鍵詞：CDB?WinDbg
保存?dumps
在我們調(diào)試不容易重現(xiàn)的問題時(shí)，可能想把應(yīng)用程序狀態(tài)的快照(內(nèi)存內(nèi)容，打開名柄的列表，等等)保存起來，以便日后分析。例如，當(dāng)我懷疑當(dāng)前的狀態(tài)可能包含我試圖解決的問題的關(guān)鍵點(diǎn)，而想繼續(xù)運(yùn)行應(yīng)用程序來查看情形怎樣發(fā)展時(shí)，它就很有用了。有時(shí)候，我會做一系列的快照，一個接一個，以便稍后我能比較它們，查看在應(yīng)用程序運(yùn)行時(shí)有些數(shù)據(jù)結(jié)構(gòu)怎樣變化。當(dāng)我最終能重現(xiàn)這個問題時(shí)，我總是創(chuàng)建一個快照來確保我沒有因?yàn)槟承╁e誤(錯誤關(guān)閉了調(diào)試會話)而丟失有價(jià)值的信息。或許，大家不難猜到當(dāng)我說“快照”時(shí)，我真正的意思是“minidump”，因?yàn)閙inidump為隨時(shí)保存應(yīng)用程序的狀態(tài)提供了便利。
下面是創(chuàng)建minidump的命令行示例：
cdb?-pv?-pn?myapp.exe?-c?".dump?/m?c:\myapp.dmp;q"
讓我們仔細(xì)看一下.dump命令。在上面的例子里，我們只用到這條命令的一個選項(xiàng)(/m)，后面跟著minidump的文件名。用/m來指定minidump里應(yīng)當(dāng)包括哪種信息。最重要的(依我之見)/m選項(xiàng)的變量列在下表中：
---------------------------------------------------------------------------------------------------------------------------
選項(xiàng)??????描述??????????????????????????????????????????????????????????????????????????????????????????????例子
---------------------------------------------------------------------------------------------------------------------------
/m????????默認(rèn)就是這個選項(xiàng)。它創(chuàng)建標(biāo)準(zhǔn)的minidump，等同于MiniDumpNormal?minidump類型。由此生成的minidump
一般很小，因此，如果你想通過慢速的網(wǎng)絡(luò)傳輸minidump，那么這個選項(xiàng)非常有用。但不幸地是，小體積的
minidump也意味著在大多數(shù)情況下，它包含的信息不足以進(jìn)行完整的分析(你可以在這篇文章里找到更多有
關(guān)minidump內(nèi)容的信息)。?????????????????????????????????????????????????????????????????????dump?/m?c:\myapp.dmp
---------------------------------------------------------------------------------------------------------------------------
/ma???????帶所有可選項(xiàng)的Minidump(完整的內(nèi)存內(nèi)容，名柄，已卸載的模塊，等等)，由此生成的minidump將非常
大。如果可以隨意使用磁盤空間，這個選項(xiàng)將非常適合本地調(diào)試。???????????????????????????????.dump?/ma?c:\myapp.dmp
---------------------------------------------------------------------------------------------------------------------------
/mFhutwd??這個選項(xiàng)將生成帶數(shù)據(jù)段，非共享讀/寫內(nèi)存頁和其它有用信息的minidump。如果你想盡可能的收集信息，
但仍想使minidump保持小體積(并壓縮)，就可以用這個選項(xiàng)。????????????????????????????????.dump?/mFhutwd?c:\myapp.dmp
---------------------------------------------------------------------------------------------------------------------------
下面的命令生成包含所有信息的minidump：
cdb?-pv?-pn?myapp.exe?-c?".dump?/ma?c:\myapp.dmp;q"
如果我們想生成一個新minidump，并覆蓋已有的，該怎么辦呢？在默認(rèn)情況下，.dump命令不允許這樣做――它會抱怨文件已經(jīng)存在。為了改變默認(rèn)行為，覆蓋已存在的.dump文件，我們可以用/o選項(xiàng)：
cdb?-pv?-pn?myapp.exe?-c?".dump?/ma?/o?c:\myapp.dmp;q"
如果我們想生成一系列的minidump，一個接一個，那么它能很方便的為minidump命名，并使文件名反映生成minidump時(shí)的時(shí)間嗎。嗯，如果我們指定了/u選項(xiàng)，.dump命令就可以自動為我們這樣做，這真是一個好消息，不是嗎？例如，下面的命令可以生成名為myapp_02CC_2006-01-28_04-11-18-171_0158.dmp的minidump(0158是進(jìn)程ID)：
cdb?-pv?-pn?myapp.exe?-c?".dump?/m?/u?c:\myapp.dmp;q"
.dump命令也支持其它有趣的選項(xiàng)(你可以在文檔里發(fā)現(xiàn)它們)。
如果你想生成運(yùn)行在Visual?Studio調(diào)試器下的進(jìn)程的minidump，我建議在生成dump前，先在Visual?Studio里臨時(shí)禁用所有的斷點(diǎn)。如果沒有禁用斷點(diǎn)，生成的minidump將包含Visual?Studio調(diào)試器插入目標(biāo)進(jìn)程代碼里的斷點(diǎn)指令(int?3)。
分析故障轉(zhuǎn)儲
CDB也可以用于自動分析故障轉(zhuǎn)儲。當(dāng)我們分析故障轉(zhuǎn)儲時(shí)，通常會執(zhí)行同樣的操作，所以可以把這些操作自動化。什么樣的操作呢？這要看故障轉(zhuǎn)儲的類型。我把所有的故障轉(zhuǎn)儲分成兩大類：
???帶異常信息的故障轉(zhuǎn)儲
???不帶異常信息的故障轉(zhuǎn)儲
當(dāng)應(yīng)用程序引發(fā)未經(jīng)處理的異常并調(diào)用just-in-time調(diào)試器(Dr.?Watson,NTSD??,?或其它的調(diào)試器)，或者用為未經(jīng)處理的異常定制的過濾器?生成minidump時(shí)，通常會生成帶異常信息的故障轉(zhuǎn)儲。通過寫入故障轉(zhuǎn)儲里的異常信息，我們可以確定異常的類型和發(fā)生時(shí)它在代碼里的位置。當(dāng)我們想為以后的分析生成進(jìn)程的快照時(shí)(例如，這方面的描述參見本文的前一部分“保存dumps”)，通常手動生成不帶異常信息的故障轉(zhuǎn)儲。
當(dāng)我們調(diào)試帶異常信息的故障轉(zhuǎn)儲時(shí)，通常想知道下面這些信息：
???異常在代碼中出現(xiàn)的位置(地址，源文件和行號)
???異常發(fā)生時(shí)的調(diào)用棧
???調(diào)用棧上一些或所有函數(shù)的參數(shù)值和局部變量
WinDbg和CDB為調(diào)試故障轉(zhuǎn)儲提供了非常有用的命令――!analyze。這條命令分析故障轉(zhuǎn)儲里的異常信息，確定異常發(fā)生的位置，調(diào)用棧，并顯示詳細(xì)的報(bào)告。下面是這條命令的示例：
cdb?-z?c:\myapp.dmp?-logo?out.txt?-lines?-c?"!analyze?-v;q"
(-v選項(xiàng)要求!analyze輸出詳細(xì)的內(nèi)容)
CrashDemo.cpp?例子演示了怎樣用定制的過濾器捕獲未經(jīng)處理的異常并生成minidumps。如果你編譯并運(yùn)行它，然后用上述的CDB命令分析生成的minidump，你將可以得到和下面類似的輸出內(nèi)容：
0:001>?!analyze?-v
*******************************************************************************
*?????????????????????????????????????????????????????????????????????????????*
*????????????????????????Exception?Analysis???????????????????????????????????*
*?????????????????????????????????????????????????????????????????????????????*
*******************************************************************************
FAULTING_IP:
CrashDemo!TestFunc+2e?[c:\tests\crashdemo\crashdemo.cpp?@?124]
004309de?c70000000000?????mov?????dword?ptr?[eax],0x0
EXCEPTION_RECORD:??ffffffff?--?(.exr?ffffffffffffffff)
.exr?ffffffffffffffff
ExceptionAddress:?004309de?(CrashDemo!TestFunc+0x0000002e)
ExceptionCode:?c0000005?(Access?violation)
ExceptionFlags:?00000000
NumberParameters:?2
Parameter[0]:?00000001
Parameter[1]:?00000000
Attempt?to?write?to?address?00000000
DEFAULT_BUCKET_ID:??APPLICATION_FAULT
PROCESS_NAME:??CrashDemo.exe
ERROR_CODE:?(NTSTATUS)?0xc0000005?-?The?instruction?at?"0x%08lx"?referenced?memory
at?"0x%08lx".?The?memory?could?not?be?"%s".
WRITE_ADDRESS:??00000000
BUGCHECK_STR:??ACCESS_VIOLATION
LAST_CONTROL_TRANSFER:??from?0043096e?to?004309de
STACK_TEXT:
006afe88?0043096e?00000000?00354130?00350001?CrashDemo!TestFunc+0x2e
[c:\tests\crashdemo\crashdemo.cpp?@?124]
006aff6c?00430f31?00000000?52319518?00354130?CrashDemo!WorkerThread+0x5e
[c:\tests\crashdemo\crashdemo.cpp?@?115]
006affa8?00430ea2?00000000?006affec?7c80b50b?CrashDemo!_callthreadstartex+0x51
[f:\rtm\vctools\crt_bld\self_x86\crt\src\threadex.c?@?348]
006affb4?7c80b50b?00355188?00354130?00350001?CrashDemo!_threadstartex+0xa2
[f:\rtm\vctools\crt_bld\self_x86\crt\src\threadex.c?@?331]
006affec?00000000?00430e00?00355188?00000000?kernel32!BaseThreadStart+0x37
FOLLOWUP_IP:
CrashDemo!TestFunc+2e?[c:\tests\crashdemo\crashdemo.cpp?@?124]
004309de?c70000000000?????mov?????dword?ptr?[eax],0x0
SYMBOL_STACK_INDEX:??0
FOLLOWUP_NAME:??MachineOwner
SYMBOL_NAME:??CrashDemo!TestFunc+2e
MODULE_NAME:??CrashDemo
IMAGE_NAME:??CrashDemo.exe
DEBUG_FLR_IMAGE_TIMESTAMP:??43dc6ee7
STACK_COMMAND:??.ecxr?;?kb
FAILURE_BUCKET_ID:??ACCESS_VIOLATION_CrashDemo!TestFunc+2e
BUCKET_ID:??ACCESS_VIOLATION_CrashDemo!TestFunc+2e
Followup:?MachineOwner
---------
注意用粗體表示的內(nèi)容。第一處報(bào)告了異常的地址和類型。第二外報(bào)告調(diào)用棧。第三處為我們提供了怎樣訪問保存在故障轉(zhuǎn)儲里的異常信息的額外信息。
現(xiàn)在，我們知道異常發(fā)生的位置，甚至可以查看調(diào)用棧。那么，是得到函數(shù)的參數(shù)值及局部變量的時(shí)候了。在開始之前，讓我們注意!analyze報(bào)告中的第三處信息。這里再重復(fù)一下第三處所包含的內(nèi)容：
STACK_COMMAND:??.ecxr?;?kb
對'kb'命令我們已經(jīng)不陌生了(它顯示調(diào)用棧)。但.ecxr是什么？這條命令要求調(diào)試器把當(dāng)前的內(nèi)容切換到保存在故障轉(zhuǎn)儲里的異常信息。我們執(zhí)行這條命令后，將能訪問異常拋出時(shí)調(diào)用棧和局部變量的值。
在我們要求調(diào)試使用異常的上下文后，我們可以用'dv'命令顯示函數(shù)的參數(shù)值以及局部變量。因?yàn)槲覀兺ǔＯ氩榭凑{(diào)用棧上每一個函數(shù)的信息，因此，我們可以用'!for_each_frame?dv?/t'命令(/t選項(xiàng)要求'dv'顯示有用的類型信息)。(當(dāng)然，我們必須記住，使用優(yōu)化編譯時(shí)，在函數(shù)的整個生存期中，局部變量有可能會被取消，重注冊或被重用來保存其它的數(shù)據(jù)，因此，可能會導(dǎo)致'dv'命令輸出錯誤的值)。
下面是分析帶異常信息的故障轉(zhuǎn)儲的命令行示例：
cdb?-z?c:\myapp.dmp?-logo?out.txt?-lines?-c?"!analyze?-v;.ecxr;!for_each_frame?dv?/t;q"
下面是'!for_each_frame?dv?/t'命令輸出的例子：
_?_?_?_?_?_?_?_?_?_?_?_?_?_?_?_
00?006afe88?0043096e?CrashDemo!TestFunc+0x2e?[c:\tests\crashdemo\crashdemo.cpp?@?124]
int?*?pParam?=?0x00000000
_?_?_?_?_?_?_?_?_?_?_?_?_?_?_?_
01?006aff6c?00430f31?CrashDemo!WorkerThread+0x5e?[c:\tests\crashdemo\crashdemo.cpp?@?115]
void?*?lpParam?=?0x00000000
int?*?TempPtr?=?0x00000000
_?_?_?_?_?_?_?_?_?_?_?_?_?_?_?_
02?006affa8?00430ea2?CrashDemo!_callthreadstartex+0x51
[f:\rtm\vctools\crt_bld\self_x86\crt\src\threadex.c?@?348]
struct?_tiddata?*?ptd?=?0x00355188
_?_?_?_?_?_?_?_?_?_?_?_?_?_?_?_
03?006affb4?7c80b50b?CrashDemo!_threadstartex+0xa2
[f:\rtm\vctools\crt_bld\self_x86\crt\src\threadex.c?@?331]
void?*?ptd?=?0x00355188
struct?_tiddata?*?_ptd?=?0x00000000
_?_?_?_?_?_?_?_?_?_?_?_?_?_?_?_
04?006affec?00000000?kernel32!BaseThreadStart+0x37
Unable?to?enumerate?locals,?HRESULT?0x80004005
Private?symbols?(symbols.pri)?are?required?for?locals.
Type?".hh?dbgerr005"?for?details.
_?_?_?_?_?_?_?_?_?_?_?_?_?_?_?_
00?006afe88?0043096e?CrashDemo!TestFunc+0x2e?[c:\tests\crashdemo\crashdemo.cpp?@?124]
如果minidump沒有包括目標(biāo)進(jìn)程內(nèi)存的完整內(nèi)容，那么只有當(dāng)調(diào)試器能正確發(fā)現(xiàn)被目標(biāo)進(jìn)程加載的、相同版本的可執(zhí)行模塊時(shí)，才能分析dump。在某些情形下，你必須幫助調(diào)試器定位這些模塊――通過指定模塊搜索路徑。關(guān)于模塊搜索路徑的詳細(xì)信息和相關(guān)內(nèi)容可以在這篇文章?中找到。
現(xiàn)在，我們來處理不帶異常信息的故障轉(zhuǎn)儲。當(dāng)我們分析這樣的dump時(shí)，通常想知道所有線程的調(diào)用棧。下面是怎樣得到這些信息：
cdb?-z?c:\myapp.dmp?-logo?out.txt?-lines?-c?"~*kb;q"
如果我們不知道故障轉(zhuǎn)儲是否包含異常信息，該怎么做呢？對于minidumps來說，我們可以用MiniDumpView?打印dump的內(nèi)容，查看它里面是否包含異常信息。對于過時(shí)的'full?user?dumps'，或許唯一的選擇是，照現(xiàn)在的樣子啟動包含異常信息的dump，并查看!analyze是否報(bào)告了有意義的內(nèi)容。
有一個有趣的特例――因?yàn)槲唇?jīng)處理的異常生成故障轉(zhuǎn)儲，但因?yàn)槟承┰驔]有包含異常信息是有可能的。在這種情形下，在下面過程的幫助下，仍可能找出異常發(fā)生的位置：
1.??打印所有線程的調(diào)用棧(用前面提過的CDB命令)。
2.??找出包含kernel32!UnhandledExceptionFilter函數(shù)調(diào)用棧的線程。
3.??使用UnhandledExceptionFilter?函數(shù)的第一個參數(shù)(包含一個指向EXCEPTION_POINTERS?結(jié)構(gòu)的指針)的實(shí)際值。
下面是EXCEPTION_POINTERS?結(jié)構(gòu)的聲明：
typedef?struct?_EXCEPTION_POINTERS
{
PEXCEPTION_RECORD?ExceptionRecord;
PCONTEXT?ContextRecord;
}?EXCEPTION_POINTERS,?*PEXCEPTION_POINTERS;
如果我們知道這個結(jié)構(gòu)的地址，就能得到指向異常上下文的指針(保存在ContextRecord字段里)，把它傳遞給.cxr命令，從而把調(diào)試器上下文切換到異常發(fā)生的位置。在.cxr命令執(zhí)行后，我們可以用'kb'命令得到異常發(fā)生時(shí)的調(diào)用棧。下面是一個例子：
1.??打印所有線程的調(diào)用棧。
cdb?-z?c:\myapp.dmp?-logo?out.txt?-c?"~*kb;q"
0:000>?~*kb
.??0??Id:?6c4.73c?Suspend:?1?Teb:?7ffdf000?Unfrozen
ChildEBP?RetAddr??Args?to?Child
0012fdf8?7c90d85c?7c8023ed?00000000?0012fe2c?ntdll!KiFastSystemCallRet
0012fdfc?7c8023ed?00000000?0012fe2c?0012ff54?ntdll!NtDelayExecution+0xc
0012fe54?7c802451?0036ee80?00000000?0012ff54?kernel32!SleepEx+0x61
0012fe64?00430856?0036ee80?00330033?00300037?kernel32!Sleep+0xf
0012ff54?00431702?00000001?00352ed0?00352fb0?CrashDemo!wmain+0x96
0012ffb8?004314bd?0012fff0?7c816d4f?00330033?CrashDemo!__tmainCRTStartup+0x232
0012ffc0?7c816d4f?00330033?00300037?7ffd9000?CrashDemo!wmainCRTStartup+0xd
0012fff0?00000000?0042e5a5?00000000?00000000?kernel32!BaseProcessStart+0x23
1??Id:?6c4.5cc?Suspend:?1?Teb:?7ffde000?Unfrozen
ChildEBP?RetAddr??Args?to?Child
006af6e4?7c90e273?7c863130?d0000144?00000004?ntdll!KiFastSystemCallRet
006af6e8?7c863130?d0000144?00000004?00000000?ntdll!NtRaiseHardError+0xc
006af96c?00438951?006af9e0?5d343834?00000000?kernel32!UnhandledExceptionFilter+0x59c
006af990?00430f2a?c0000005?006af9e0?0044ad30?CrashDemo!_XcptFilter+0x61
006af99c?0044ad30?00000000?00000000?00000000?CrashDemo!_callthreadstartex+0x7a
006af9b0?00438c67?00430f13?0049a230?00000000?CrashDemo!_EH4_CallFilterFunc+0x12
006af9e8?7c9037bf?006afad4?006aff98?006afaf0?CrashDemo!_except_handler4+0xb7
006afa0c?7c90378b?006afad4?006aff98?006afaf0?ntdll!ExecuteHandler2+0x26
006afabc?7c90eafa?00000000?006afaf0?006afad4?ntdll!ExecuteHandler+0x24
006afabc?004309be?00000000?006afaf0?006afad4?ntdll!KiUserExceptionDispatcher+0xe
006afe88?0043094e?00000000?00354130?00350001?CrashDemo!TestFunc+0x2e
006aff6c?00430f01?00000000?647bff58?00354130?CrashDemo!WorkerThread+0x5e
006affa8?00430e72?00000000?006affec?7c80b50b?CrashDemo!_callthreadstartex+0x51
006affb4?7c80b50b?00355188?00354130?00350001?CrashDemo!_threadstartex+0xa2
006affec?00000000?00430dd0?00355188?00000000?kernel32!BaseThreadStart+0x37
2.??改變調(diào)試器的上下文，得到異常的調(diào)用棧。
cdb?-z?c:\myapp.dmp?-logo?out.txt?-lines?-c?".cxr?dwo(0x006af9e0+4);kb;q"
('dwo'操作符返回保存在指定地址里的double?word，并把它傳遞給.cxr命令)
本篇文章后面提供的批處理文件(實(shí)際上是DumpStackCtx.bat)將簡化這個任務(wù)。
還有另外的方法可以解決這個問題――你可以在這里?找到更多的信息。
分析虛擬內(nèi)存
當(dāng)我們想審查被調(diào)試進(jìn)程的虛擬內(nèi)存布局時(shí)，CDB可以協(xié)助Visual?Studio調(diào)試器。下面的命令顯示進(jìn)程完整的虛擬內(nèi)存映射：
cdb?-pv?-pn?myapp.exe?-logo?out.txt?-c?"!vadump?-v;q"
(!vadump命令負(fù)責(zé)打印虛擬內(nèi)存映射，照常，用-v選項(xiàng)要求它顯示詳細(xì)的內(nèi)容)
下面是!vadump輸出的例子：
BaseAddress:???????00040000
AllocationBase:????00040000
AllocationProtect:?00000004??PAGE_READWRITE
RegionSize:????????0002e000
State:?????????????00002000??MEM_RESERVE
Type:??????????????00020000??MEM_PRIVATE
BaseAddress:???????0006e000
AllocationBase:????00040000
AllocationProtect:?00000004??PAGE_READWRITE
RegionSize:????????00001000
State:?????????????00001000??MEM_COMMIT
Protect:???????????00000104??PAGE_READWRITE?+?PAGE_GUARD
Type:??????????????00020000??MEM_PRIVATE
BaseAddress:???????0006f000
AllocationBase:????00040000
AllocationProtect:?00000004??PAGE_READWRITE
RegionSize:????????00011000
State:?????????????00001000??MEM_COMMIT
Protect:???????????00000004??PAGE_READWRITE
Type:??????????????00020000??MEM_PRIVATE
在Windows?XP和Windows?Server?2003上，CDB為審查虛擬內(nèi)存布局提供了一條更好的命令――!address。這條命令可以完成下面的任務(wù)：
???顯示進(jìn)程的虛擬內(nèi)存映射(依我之見，比!vadump的輸出內(nèi)容更易閱讀)
???顯示有用的、虛擬內(nèi)存使用的統(tǒng)計(jì)數(shù)據(jù)
???確定指定的地址屬于哪種虛擬內(nèi)存區(qū)域(例如，它是屬于棧，堆，還是可執(zhí)行映象？)
下面是怎樣用!address報(bào)告虛擬內(nèi)存映射的示例：
cdb?-pv?-pn?myapp.exe?-logo?out.txt?-c?"!address;q"
下面顯示被線程的棧占用的內(nèi)存區(qū)域：
00040000?:?00040000?-?0002e000
Type?????00020000?MEM_PRIVATE
Protect??00000000
State????00002000?MEM_RESERVE
Usage????RegionUsageStack
Pid.Tid??658.644
0006e000?-?00001000
Type?????00020000?MEM_PRIVATE
Protect??00000104?PAGE_READWRITE?|?PAGE_GUARD
State????00001000?MEM_COMMIT
Usage????RegionUsageStack
Pid.Tid??658.644
0006f000?-?00011000
Type?????00020000?MEM_PRIVATE
Protect??00000004?PAGE_READWRITE
State????00001000?MEM_COMMIT
Usage????RegionUsageStack
Pid.Tid??658.644
注意，!address非常智能，可以報(bào)告屬于棧的線程的線程ID。
在!address報(bào)告虛擬內(nèi)存區(qū)域之后，它也能報(bào)告有趣的、虛擬內(nèi)存使用的統(tǒng)計(jì)數(shù)據(jù)：
--------------------?Usage?SUMMARY?--------------------------
TotSize???Pct(Tots)?Pct(Busy)???Usage
00838000?:?0.40%???????27.96%??????:?RegionUsageIsVAD
7e28c000?:?98.56%??????0.00%???????:?RegionUsageFree
01348000?:?0.94%???????65.60%??????:?RegionUsageImage
00040000?:?0.01%???????0.85%???????:?RegionUsageStack
00001000?:?0.00%???????0.01%???????:?RegionUsageTeb
001a0000?:?0.08%???????5.53%???????:?RegionUsageHeap
00000000?:?0.00%???????0.00%???????:?RegionUsagePageHeap
00001000?:?0.00%???????0.01%???????:?RegionUsagePeb
00001000?:?0.00%???????0.01%???????:?RegionUsageProcessParametrs
00001000?:?0.00%???????0.01%???????:?RegionUsageEnvironmentBlock
Tot:?7fff0000?Busy:?01d64000
--------------------?Type?SUMMARY?--------------------------
TotSize???Pct(Tots)?Usage
7e28c000?:?98.56%?????:?01348000?:?0.94%??????:?MEM_IMAGE
007b6000?:?0.38%??????:?MEM_MAPPED
00266000?:?0.12%??????:?MEM_PRIVATE
--------------------?State?SUMMARY?--------------------------
TotSize???Pct(Tots)?Usage
01647000?:?1.09%??????:?MEM_COMMIT
7e28c000?:?98.56%?????:?MEM_FREE
0071d000?:?0.35%??????:?MEM_RESERVE
Largest?free?region:?Base?01014000?-?Size?59d5c000
當(dāng)我們正在調(diào)試內(nèi)存泄露，以及想確定內(nèi)存泄露的類型(堆，棧，原始的虛擬內(nèi)存，等等)時(shí)，這些統(tǒng)計(jì)數(shù)據(jù)非常有用。通過最后一行，我們可以確定虛擬內(nèi)存中最大的空閑區(qū)域的大小，這在我們必須設(shè)計(jì)請求大量內(nèi)存的應(yīng)用程序時(shí)非常有幫助。
如果你只想查看統(tǒng)計(jì)數(shù)據(jù)，而不想看虛擬內(nèi)存映射，可以用-summary參數(shù)：
cdb?-pv?-pn?myapp.exe?-logo?out.txt?-c?"!address?-summary;q"
如果我們想確定給定地址的虛擬內(nèi)存屬于哪種類型，可以把這個地址作為參數(shù)傳遞給!address命令。下面是一個例子：
0:000>?!address?0x000a2480;q
000a0000?:?000a0000?-?000d7000
Type?????00020000?MEM_PRIVATE
Protect??00000004?PAGE_READWRITE
State????00001000?MEM_COMMIT
Usage????RegionUsageHeap
Handle???000a0000
搜索符號
有時(shí)候，我們可能需要確定符號(函數(shù)或變量)的地址。如果我們知道準(zhǔn)確的符號名，可以把它輸入Visual?Studio調(diào)試器的反匯編窗口，從中找出它對應(yīng)的地址。但是，假設(shè)我們忘了準(zhǔn)確的符號名呢？或者想找出名字上有相同規(guī)律的、一組符號的地址(例如，類的所有成員函數(shù))？CDB很容易解決這個問題――它提供'x'命令，可以列出匹配指定掩碼的所有符號名：
x?Module!Symbol
下面的命令設(shè)法定位位于kernel32.dll?中的UnhandledExceptionFilter函數(shù)的地址：
cdb?-pv?-pn?notepad.exe?-logo?out.txt?-c?"x?kernel32!UnhandledExceptionFilter;q"
下面是輸出內(nèi)容：
0:000>?x?kernel32!UnhandledExceptionFilter;q
7c862b8a?kernel32!UnhandledExceptionFilter?=?'x'命令可以接受多個通配符，提供一些有用的選項(xiàng)，可用于排序輸出內(nèi)容以及輸出符號的額外信息――你可以在WinDbg文檔里找到更多的信息。例如，下面的命令可以把我們在應(yīng)用程序的主可執(zhí)行模塊中定義的CmainFrame類所有的成員函數(shù)和統(tǒng)計(jì)數(shù)據(jù)列出來：
0:000>?x?myapp!*CMainFrame*
004542f8?MyApp!CMainFrame::classCMainFrame?=?struct?CRuntimeClass
00401100?MyApp!CMainFrame::`scalar?deleting?destructor'?(void)
004011a0?MyApp!CMainFrame::OnCreate?(struct?tagCREATESTRUCTW?*)
00401000?MyApp!CMainFrame::CreateObject?(void)
00401280?MyApp!CMainFrame::PreCreateWindow?(struct?tagCREATESTRUCTW?*)
00401070?MyApp!CMainFrame::GetRuntimeClass?(void)
00401120?MyApp!CMainFrame::~CMainFrame?(void)
00401090?MyApp!CMainFrame::CMainFrame?(void)
00401080?MyApp!CMainFrame::GetMessageMap?(void)
004578ec?MyApp!CMainFrame::`RTTI?Base?Class?Array'?=?004578dc?MyApp!CMainFrame::`RTTI?Class?Hierarchy?Descriptor'?=?004578c8?MyApp!CMainFrame::`RTTI?Complete?Object?Locator'?=?004579ec?MyApp!CMainFrame::`RTTI?Base?Class?Descriptor?at?(0,-1,0,64)'?=?00461e94?MyApp!CMainFrame?`RTTI?Type?Descriptor'?=?00454354?MyApp!CMainFrame::`vftable'?=?CDB也可以反著做――通過地址找符號，使用'ln'命令：
ln?Address
下面是它的用法：
cdb?-pv?-pn?notepad.exe?-logo?out.txt?-c?"ln?0x77d491c8;q"
下面是它的輸出內(nèi)容：
0:000>?ln?0x77d491c8;q
(77d491c6)???USER32!GetMessageW+0x2???|??(77d49216)???USER32!CharUpperBuffW
注意，我們不必指定符號的起始地址(在這個例子里，是函數(shù))，而可以用符號占用的地址范圍內(nèi)的任何地址。'ln'將找出符號，報(bào)告它的地址，另外還報(bào)告跟在指定內(nèi)容后面的地址和符號名。
顯示數(shù)據(jù)結(jié)構(gòu)
如果我們想研究數(shù)據(jù)結(jié)構(gòu)的內(nèi)容，通常會用Visual?Studio的Watch，QuickWatch或其它類似的窗口。這些窗口允許我們查看結(jié)構(gòu)成員變量的類型和值。但是假設(shè)我們也需要知道結(jié)構(gòu)的精確布局，包括它的成員的偏移量？Visual?Studio不提供易用的解決方法，但幸運(yùn)的是，CDB可以。在'dt'命令的幫助下，我們可以顯示數(shù)據(jù)結(jié)構(gòu)或類的精確布局。
如果我們只想了解數(shù)據(jù)類型的布局，可以用下面這條命令：
dt?-b?TypeName
(-b選項(xiàng)啟用遞歸顯示，顯示結(jié)構(gòu)或類的成員類型的嵌入式數(shù)據(jù)結(jié)構(gòu))。
下面是命令的示例：
cdb?-pv?-pn?myapp.exe?-logo?out.txt?-c?"dt?-b?CSymbolInfoPackage;q"
下面是輸出內(nèi)容(在運(yùn)行SymFromAddr?應(yīng)用程序時(shí)得到的)：
0:000>?dt?/b?CSymbolInfoPackage;q
+0x000?si???????????????:?_SYMBOL_INFO
+0x000?SizeOfStruct?????:?Uint4B
+0x004?TypeIndex????????:?Uint4B
+0x008?Reserved?????????:?Uint8B
+0x018?Index????????????:?Uint4B
+0x01c?Size?????????????:?Uint4B
+0x020?ModBase??????????:?Uint8B
+0x028?Flags????????????:?Uint4B
+0x030?Value????????????:?Uint8B
+0x038?Address??????????:?Uint8B
+0x040?Register?????????:?Uint4B
+0x044?Scope????????????:?Uint4B
+0x048?Tag??????????????:?Uint4B
+0x04c?NameLen??????????:?Uint4B
+0x050?MaxNameLen???????:?Uint4B
+0x054?Name?????????????:?Char
+0x058?name?????????????:?Char
如果你想顯示特殊變量的布局，可以把它的地址傳遞給'dt'命令：
dt?-b?TypeName?Address
下面是例子：
cdb?-pv?-pn?myapp.exe?-logo?out.txt?-c?"dt?-b?CSymbolInfoPackage?0x0012f6d0;q"
0:000>?dt?/b?CSymbolInfoPackage?0x0012f6d0;q
+0x000?si???????????????:?_SYMBOL_INFO
+0x000?SizeOfStruct?????:?0x58
+0x004?TypeIndex????????:?2
+0x008?Reserved?????????:
[00]?0
[01]?0
+0x018?Index????????????:?1
+0x01c?Size?????????????:?0x428
+0x020?ModBase??????????:?0x400000
+0x028?Flags????????????:?0
+0x030?Value????????????:?0
+0x038?Address??????????:?0x411d30
+0x040?Register?????????:?0
+0x044?Scope????????????:?0
+0x048?Tag??????????????:?5
+0x04c?NameLen??????????:?0xe
+0x050?MaxNameLen???????:?0x7d1
+0x054?Name?????????????:??"S"
[00]?83?'S'
+0x058?name?????????????:??"SymbolInfo"
[00]?83?'S'
[01]?121?'y'
[02]?109?'m'
[03]?98?'b'
[04]?111?'o'
[05]?108?'l'
[06]?73?'I'
[07]?110?'n'
[08]?102?'f'
[09]?111?'o'
[10]?0?''
[11]?0?''
[12]?0?''
[13]?0?''
[14]?0?''
[15]?0?''
[16]?0?''
[17]?0?''
...?省略部分輸出內(nèi)容
[1990]?0?''
[1991]?0?''
[1992]?0?''
[1993]?0?''
[1994]?0?''
[1995]?0?''
[1996]?0?''
[1997]?-52?''
[1998]?-52?''
[1999]?-52?''
[2000]?-52?''
注意，'dt'也顯示結(jié)構(gòu)成員變量的值。
批處理文件
我們已經(jīng)知道怎樣用CDB解決一些有趣的調(diào)試問題了。現(xiàn)在可以用它解決更多的問題了――用易用的批處理文件代替難記的CDB命令行。考慮我們在本文開始部分使用的命令行示例：
cdb?-pv?-pn?myapp.exe?-logo?out.txt?-c?"lm;q"
這條命令中的大部分是固定的，用不著改變。唯一可變的部分是目標(biāo)信息(-pn?myapp.exe)，我們可能會用另外的可執(zhí)行文件名，或另外的附著方式(例如，通過進(jìn)程ID)替換它。
下面介紹了怎樣用批處理文件代替這條命令：
;?lm.bat
cdb?-pv?%1?%2?-logo?out.txt?-c?"lm;q"
如果我們運(yùn)行這個批處理文件，通過進(jìn)程來得到已加載模塊的列表，可以用下面的方法：
通過可執(zhí)行文件名附上進(jìn)程：
lm?-pn?myapp.exe
通過進(jìn)程ID附上進(jìn)程：
lm?-p?1234
通過服務(wù)名附上進(jìn)程：
lm?-psn?MyService
打開故障轉(zhuǎn)儲文件：
lm?-z?c:\myapp.dmp
這條命令與具體的目標(biāo)無關(guān)，只做同樣的事情――打印已加載模塊的列表。
如果我們想為CDB命令指定另外的參數(shù)，我們可以用同樣的方法。考慮下面用于顯示數(shù)據(jù)結(jié)構(gòu)布局的命令：
cdb?-pv?-pn?myapp.exe?-logo?out.txt?-c?"dt?/b?MyStruct;q"
當(dāng)然，我們可能想使用任何數(shù)據(jù)類型運(yùn)行這條命令，而不僅僅是MyStruct。下面是怎樣做的示例：
;?dt.bat
cdb?-pv?%1?%2?-logo?out.txt?-c?"dt?/b?%3;q"
現(xiàn)在，我們可以象下面這樣運(yùn)行這條命令：
dt?-pn?myapp.exe?CTestClass
或者象這樣：
dt?-p?1234?SYMBOL_INFO
或者，也可以象這樣：
dt?-z?c:\myapp.dmp?EXCEPTION_POINTERS
總結(jié)
以上是生活随笔為你收集整理的windbg 查看结构体_用WinDbg进行调试的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： wifi卡慢延迟高_健康生活好助手：华为
- 下一篇： nc65语义模型设计_NC6X报表数据加