本人进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 阅读(5204)
评论(4) 编辑 收藏 引用 所属分类:
Windbg