本人進2年來主要在做windbg調試相關的工作, 有一些心得和體會. 我會逐片寫在我blog中,希望對大家有用.
windbg調試最重要的是要對系統的方方面面有比較深入的了解. 只有了解了系統工作原理才能夠順藤摸瓜.
一步步展開線索.
windbg基礎篇 比較注重于原理方面的討論, 逐步展開調試方法. 此文當是基于我給公司同事做培訓時的ppt.
所以難免會寫的不是面面俱到.
如果您發現文章中有任何錯誤和意見,請給我留言. 謝謝.
寄存器上下文
“上下文”的常用含義是一組寄存器，表示處理器在某個特定時刻的狀態，因此也被稱之為寄存器上下文。
每條線程都有自己的上下文信息;
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
異常上下文
當發生中斷或者異常時, 系統會將當前寄存器的值保存到棧內存中（我們稱之為context record）,
這個記錄稱之為異常上下文. 分析轉儲dump時,可以使用.ecxr將dump中保存的異常上下文切換到寄存器上下文中
異常上下文結構體
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)
異常發生時，操作系統捕獲到CPU異常(內核中掛接了CPU異常處理函數),CPU去執行操作系統異常處理函數，操作系統再將此異常通知給用戶態進程的異常處理函數,讓用戶態進程有機會去處理異常.用戶態進程處理接收到異常將會進入catch block或者什么都不做。
如果用戶態進程什么都不做，此時操作系統默認的行為就是終止程序并顯示向Microsoft發送錯誤報告界面。 異常可以被手動觸發，如c#/c++中的throw關鍵字。異常是通過異常編碼來標示的，如比如訪問無效地址的號 碼是0xc0000005, WinDBG中的斷點和單步調試都是通過異常基礎來實現的。
弄清楚異常發生的時間、地址、導致異常的指令和異常導致的結果對排錯是至關重要的。
當一個異常發生時，操作系統要向引起異常的線程的棧里壓入三個結構，分別是：
E X C E P T I O N _ R E C O R D結構、C O N T E X T結構和E X C E P T I O N _ P O I N T E R S結構。
E X C E P T I O N _ R E C O R D結構包含有關已發生異常的獨立于C P U的信息，C O N T E X T結構包含已發生異 常的依賴于C P U的信息。E X C E P T I O N _ P O I N T E R S結構只有兩個數據成員，二者都是指針，分別指向被壓入棧的E X C E P T I O N _ R E C O R D和C O N T E X T結構：
0:000> dt EXCEPTION_POINTERS 0012fe6c
EXCEPTION_POINTERS
+0x000 ExceptionRecord : (null)
+0x004 ContextRecord : (null) == _CONTEXT
在Vista和Windows 2008中，系統改良了Error Reporting功能。程序崩潰后，系統會在Error Reporting的時候從內核直接掛起出錯的進程。這個時候如果用調試器檢查，會看到出錯進程就停在發生問題的指令上，
不再需要在調試器中手動恢復exception context。
程序崩潰調試
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
這時候往往需要進行手工分析和恢復異常上下文，以找回真正的問題所在/調用堆棧。
先切換到出錯線程。
> !teb 觀察線程環境塊
StackBase: 002a0000
StackLimit: 0029e000
>dds/dps/dqs [StackLimit] ~ [StackBase]
然后查找到RtlDispatchException, 具體函數參數請查詢此函數原型。
0029fbf8 0029fc78
0029fbfc 0029fc94 //第二個函數參數
cxr加上異常上下文地址來切換上下文：
>.cxr 0029fc94 ---> 此步執行之后,再使用
> kb 往往可以看出來真正的錯誤代碼調用
當然可以采用另外的方法來搜索異常上下文標志:
s -d StackLimit(察看上面的!teb結果) L1000 1003f
你可以可以搜索到異常上下文信息.
0029fc94 0001003f 00000000 00000000 00000000 00000000
為什么搜索 1003f 呢??
>dd 0029fc94 你會看到前四個字節存放的就是 1003f
至此, 使用此方法你可以恢復出任何異常上下文. 找出異常上下文,可以恢復出出錯時cpu寄存器的所有值.
posted on 2009-08-22 13:47
Only Soft 閱讀(5260)
評論(4) 編輯 收藏 引用 所屬分類:
Windbg