本人進2年來主要在做windbg調(diào)試相關的工作, 有一些心得和體會. 我會逐片寫在我blog中,希望對大家有用.
windbg調(diào)試最重要的是要對系統(tǒng)的方方面面有比較深入的了解. 只有了解了系統(tǒng)工作原理才能夠順藤摸瓜.
一步步展開線索.
windbg基礎篇 比較注重于原理方面的討論, 逐步展開調(diào)試方法. 此文當是基于我給公司同事做培訓時的ppt.
所以難免會寫的不是面面俱到.
如果您發(fā)現(xiàn)文章中有任何錯誤和意見,請給我留言. 謝謝.
寄存器上下文
“上下文”的常用含義是一組寄存器，表示處理器在某個特定時刻的狀態(tài)，因此也被稱之為寄存器上下文。
每條線程都有自己的上下文信息;
0:000> r 讀取第一條線程寄存器值
eax=00000002 ebx=7ffff000 ecx=00000001 edx=00000001 esi=0012fe6c edi=0012ff48
0:001> r 讀取第二條線程寄存器值
eax=003dfd24 ebx=77b451f4 ecx=00000000 edx=00000000 esi=00000000 edi=7fffd000
異常上下文
當發(fā)生中斷或者異常時, 系統(tǒng)會將當前寄存器的值保存到棧內(nèi)存中（我們稱之為context record）,
這個記錄稱之為異常上下文. 分析轉(zhuǎn)儲dump時,可以使用.ecxr將dump中保存的異常上下文切換到寄存器上下文中
異常上下文結(jié)構(gòu)體
0:001> dt ntdll!_CONTEXT
+0x000 ContextFlags : Uint4B
+0x01c FloatSave : _FLOATING_SAVE_AREA
+0x09c Edi : Uint4B
+0x0a0 Esi : Uint4B
+0x0a4 Ebx : Uint4B
+0x0a8 Edx : Uint4B
+0x0ac Ecx : Uint4B
+0x0b0 Eax : Uint4B
+0x0b4 Ebp : Uint4B
+0x0b8 Eip : Uint4B
+0x0c4 Esp : Uint4B
異常上下文 與 SEH (Window32 Structured Exception Handling)
異常發(fā)生時，操作系統(tǒng)捕獲到CPU異常(內(nèi)核中掛接了CPU異常處理函數(shù)),CPU去執(zhí)行操作系統(tǒng)異常處理函數(shù)，操作系統(tǒng)再將此異常通知給用戶態(tài)進程的異常處理函數(shù),讓用戶態(tài)進程有機會去處理異常.用戶態(tài)進程處理接收到異常將會進入catch block或者什么都不做。
如果用戶態(tài)進程什么都不做，此時操作系統(tǒng)默認的行為就是終止程序并顯示向Microsoft發(fā)送錯誤報告界面。 異常可以被手動觸發(fā)，如c#/c++中的throw關鍵字。異常是通過異常編碼來標示的，如比如訪問無效地址的號 碼是0xc0000005, WinDBG中的斷點和單步調(diào)試都是通過異常基礎來實現(xiàn)的。
弄清楚異常發(fā)生的時間、地址、導致異常的指令和異常導致的結(jié)果對排錯是至關重要的。
當一個異常發(fā)生時，操作系統(tǒng)要向引起異常的線程的棧里壓入三個結(jié)構(gòu)，分別是：
E X C E P T I O N _ R E C O R D結(jié)構(gòu)、C O N T E X T結(jié)構(gòu)和E X C E P T I O N _ P O I N T E R S結(jié)構(gòu)。
E X C E P T I O N _ R E C O R D結(jié)構(gòu)包含有關已發(fā)生異常的獨立于C P U的信息，C O N T E X T結(jié)構(gòu)包含已發(fā)生異 常的依賴于C P U的信息。E X C E P T I O N _ P O I N T E R S結(jié)構(gòu)只有兩個數(shù)據(jù)成員，二者都是指針，分別指向被壓入棧的E X C E P T I O N _ R E C O R D和C O N T E X T結(jié)構(gòu)：
0:000> dt EXCEPTION_POINTERS 0012fe6c
EXCEPTION_POINTERS
+0x000 ExceptionRecord : (null)
+0x004 ContextRecord : (null) == _CONTEXT
在Vista和Windows 2008中，系統(tǒng)改良了Error Reporting功能。程序崩潰后，系統(tǒng)會在Error Reporting的時候從內(nèi)核直接掛起出錯的進程。這個時候如果用調(diào)試器檢查，會看到出錯進程就停在發(fā)生問題的指令上，
不再需要在調(diào)試器中手動恢復exception context。
程序崩潰調(diào)試
Stack 沒有指出任何有用的信息:
0:000> kb
ChildEBP RetAddr Args to Child
0012f74c 7c821b74 77e999ea d0000144 00000004 ntdll!KiFastSystemCallRet
0012f750 77e999ea d0000144 00000004 00000000 ntdll!ZwRaiseHardError+0xc
0012f9bc 004339be 0012fa08 7ffdd000 0044c4d8 kernel32!UnhandledExceptionFilter+0x4b4
這時候往往需要進行手工分析和恢復異常上下文，以找回真正的問題所在/調(diào)用堆棧。
先切換到出錯線程。
> !teb 觀察線程環(huán)境塊
StackBase: 002a0000
StackLimit: 0029e000
>dds/dps/dqs [StackLimit] ~ [StackBase]
然后查找到RtlDispatchException, 具體函數(shù)參數(shù)請查詢此函數(shù)原型。
0029fbf8 0029fc78
0029fbfc 0029fc94 //第二個函數(shù)參數(shù)
cxr加上異常上下文地址來切換上下文：
>.cxr 0029fc94 ---> 此步執(zhí)行之后,再使用
> kb 往往可以看出來真正的錯誤代碼調(diào)用
當然可以采用另外的方法來搜索異常上下文標志:
s -d StackLimit(察看上面的!teb結(jié)果) L1000 1003f
你可以可以搜索到異常上下文信息.
0029fc94 0001003f 00000000 00000000 00000000 00000000
為什么搜索 1003f 呢??
>dd 0029fc94 你會看到前四個字節(jié)存放的就是 1003f
至此, 使用此方法你可以恢復出任何異常上下文. 找出異常上下文,可以恢復出出錯時cpu寄存器的所有值.
posted on 2009-08-22 13:47
Only Soft 閱讀(5273)
評論(4) 編輯 收藏 引用 所屬分類:
Windbg