http://202.102.53.35/user8/flier_lu/main.asp?id=1324316
Win32 调试接口设计与实现浅析 [2] 调试事件
Flier Lu @ http://flier_lu.blogone.net/
[2] 调试事件
前面说到 Win32 下的用户态调试器实际上就是一个while循环，循环体内先等待一个调
试事件，然后处理之，最后将控制权交还给调试服务器，就好像一个窗口消息循环一样。调
试事件的核心实际上就是一个DEBUG_EVENT结构，在WinBase.h文件中定义如下：
以下为引用：
typedef struct _DEBUG_EVENT {
DWORD dwDebugEventCode;
DWORD dwProcessId;
DWORD dwThreadId;
union {
EXCEPTION_DEBUG_INFO Exception;
CREATE_THREAD_DEBUG_INFO CreateThread;
CREATE_PROCESS_DEBUG_INFO CreateProcessInfo;
EXIT_THREAD_DEBUG_INFO ExitThread;
EXIT_PROCESS_DEBUG_INFO ExitProcess;
LOAD_DLL_DEBUG_INFO LoadDll;
UNLOAD_DLL_DEBUG_INFO UnloadDll;
OUTPUT_DEBUG_STRING_INFO DebugString;
RIP_INFO RipInfo;
} u;
} DEBUG_EVENT, *LPDEBUG_EVENT;
dwDebugEventCode字段给出此调试事件的类型，dwProcessId和dwThreadId字段分别给
出调试事件发生的进程和线程ID号。调试事件一般有以下几类：
以下为引用：
#define EXCEPTION_DEBUG_EVENT 1
#define CREATE_THREAD_DEBUG_EVENT 2
#define CREATE_PROCESS_DEBUG_EVENT 3
#define EXIT_THREAD_DEBUG_EVENT 4
#define EXIT_PROCESS_DEBUG_EVENT 5
#define LOAD_DLL_DEBUG_EVENT 6
#define UNLOAD_DLL_DEBUG_EVENT 7
#define OUTPUT_DEBUG_STRING_EVENT 8
#define RIP_EVENT 9
CREATE_PROCESS_DEBUG_EVENT事件在调试的进程中创建一个新的进程或调试器开始调试
一个附加到的进程时被引发；相对的EXIT_PROCESS_DEBUG_EVENT事件在调试的进程结束最后
一个线程时被引发；每次新建/推出一个线程时会有CREATE_THREAD_DEBUG_EVENT/EXIT_THRE
AD_DEBUG_EVENT事件被引发；每次载入/卸载一个DLL时会有LOAD_DLL_DEBUG_EVENT/UNLOAD_
DLL_DEBUG_EVENT事件被引发；使用OutputDebugString函数输出一个字符串时调试器会接受
到一个OUTPUT_DEBUG_STRING_EVENT事件；异常被引发时调试器会接受到一个第一时间的EXC
EPTION_DEBUG_EVENT事件，如果调试器不处理此异常，则进入被调试进程的正常SEH调用链
，如果被调试进程也不处理，则会再次引发此事件；RIP_EVENT则一般用于报告错误事件。
一般来说程序的调试事件按照如下顺序被引发：
以下为引用：
CREATE_PROCESS_DEBUG_EVENT
LOAD_DLL_DEBUG_EVENT x n // 静态载入的DLL
CREATE_THREAD_DEBUG_EVENT & EXIT_THREAD_DEBUG_EVENT // 多线程程序中成对出现
LOAD_DLL_DEBUG_EVENT & UNLOAD_DLL_DEBUG_EVENT // 动态载入 DLL 时成对出现
EXCEPTION_DEBUG_EVENT x n // 随机出现
OUTPUT_DEBUG_STRING_EVENT x n // 程序写调试信息时出现
EXIT_PROCESS_DEBUG_EVENT
接下来我们详细分析每种调试事件的内容及其被引发的时机。
首先是建立进程的CREATE_PROCESS_DEBUG_EVENT事件和建立线程的CREATE_THREAD_DEBU
G_EVENT事件。这两个事件都是由DbgkCreateThread函数(ntos\dbgk\dbgkproc.h:211)引发
的。此函数首先检查当前线程是否具有调试端口的活动线程；然后检查当前线程是否是进程
的创建的第一个线程；如果不是第一个线程，或者调试器是挂接(attach)到一个活动进程上
（判断依据是此进程是否占用过用户态的CPU时间），则向调试子系统的调试服务器引发CRE
ATE_THREAD_DEBUG_EVENT事件；否则转而报告CREATE_PROCESS_DEBUG_EVENT事件。具体的调
试事件信息这里就不罗嗦了，有兴趣写调试器的朋友可以参考MSDN和<Debugging Applicati
ons>中相关内容。
DbgkCreateThread函数伪代码如下：
以下为引用：
VOID DbgkCreateThread(PVOID StartAddress)
{
if(!PsGetCurrentProcess()->DebugPort || PsGetCurrentThread()->DeadThread)
{
return;
}
PsLockProcess(Process,KernelMode,PsLockWaitForever); // 锁定进程中所有线程
if(PsGetCurrentProcess()->Pcb.UserTime &&
PsGetCurrentProcess()->CreateProcessReported == FALSE)
{
// 引发 CREATE_PROCESS_DEBUG_EVENT 事件
}
else
{
// 引发 CREATE_THREAD_DEBUG_EVENT 事件
}
PsUnlockProcess(PsGetCurrentProcess());
}
Win32在创建用户态线程的时候，大致流程如下：
以下为引用：
CreateThread (kernel32.dll)
CreateRemoteThread (kernel32.dll)
NtCreateThread (ntoskrnl.exe)
PspCreateThread (ntos\ps\create.c:237)
PspCreateThread函数在创建用户态线程时，使用PspUserThreadStartup函数(ntos\ps\
create.c:1639)作为入口函数参数，线程被创建后直接进入此函数。PspUserThreadStartu
p函数对非僵死线程和没有结束的线程初始化其APC；然后调用DbgkCreateThread函数通知调
试器采取相应动作；最后将进程的用户态CPU事件设置为1，以标示此进程已启动。对一种特
殊线程，非僵死线程但线程启动时已经停止，则直接DbgkCreateThread后立刻PspExitThrea
d，以通知调试器采取相应动作。PspUserThreadStartup函数伪代码如下：
以下为引用：
VOID PspUserThreadStartup(IN PKSTART_ROUTINE StartRoutine, IN PVOID StartContext
)
{
if(!PsGetCurrentThread()->DeadThread && !PsGetCurrentThread()->HasTerminated)
{
// 初始化 APC
}
else
{
if(!PsGetCurrentThread()->DeadThread)
{
DbgkCreateThread(StartContext);
}
PspExitThread(STATUS_THREAD_IS_TERMINATING);
}
DbgkCreateThread(StartContext);
if(PsGetCurrentProcess()->Pcb.UserTime == 0)
{
PsGetCurrentProcess()->Pcb.UserTime = 1;
}
}
与DbgkCreateThread函数对应的是DbgkExitThread函数(ntos\dbgk\dbgkproc.c:384)和
DbgkExitProcess函数(ntos\dbgk\dbgkproc.c:439)，分别向调试服务器引发EXIT_THREAD_D
EBUG_EVENT和EXIT_PROCESS_DEBUG_EVENT事件。
这两个函数被系统内核推出线程的PspExitThread函数(ntos\ps\psdelete.c:622)在合
适的时候调用。PspExitThread函数检测当前进程PCB的线程列表是否只有当前线程一个线程
，如果是则调用DbgkExitProcess函数，否则调用DbgkExitThread函数。
对于载入和卸载DLL，实际的调用流程如下：
以下为引用：
LoadLibrary (kernel32.dll)
LoadLibraryEx (kernel32.dll)
BasepLoadLibraryAsDataFile (kernel32.dll)
NtMapViewOfSection (ntos\mm\mapview.c:204)
NtMapViewOfSection函数在调用MmMapViewOfSection函数(ntos\mm\mapview.c:699)完
成实际的内存文件映射之后，会根据映射节的标记和目标进程是否是当前进程，判断是否要
调用DbgkMapViewOfSection函数(ntos\dbgk\dbgkproc.c:495)通知调试服务器有新的映象文
件被加载。与之对于MmUnmapViewOfSection函数(ntos\mm\umapview.c:88)也在判断标志和
目标进程是否是当前进程后在函数末尾调用DbgkUnMapViewOfSection函数(ntos\dbgk\dbgkp
roc.c:567)通知调试服务器有映象文件被卸载。
与前面的几种事件不同，OutputDebugString函数(kernel32.dll)实际上是通过异常实
现的。而且有趣的是，这个函数是为数不多的W后缀Unicode转而调用A后缀Ansi版本完成实
际功能的例子。OutputDebugStringA函数(kernel32.dll)实际上使用RaiseException函数引
发了一个异常号为0x40010006的软异常，并将字符串的指针和长度作为异常参数传递。
DbgkForwardException函数(ntos\dbgk\dbgkport.c:96)作为实际引发EXCEPTION_DEBUG
_EVENT调试事件的函数，在系统的异常分发KiDispatchException函数(ntos\ke\i386\excep
tn.c:797)中被调用。KiDispatchException函数根据异常被引发时的状态，分别完成核心和
用户态的异常处理。
对核心态异常，首先给核心调试程序一个处理机会，然后试图分发到基于帧的SEH异常
去，没有被处理的话则再给核心调试程序一个机会，如果还是没被处理，就只能调用KeBugC
heckEx函数(ntos\ke\bugcheck.c:157)蓝屏了，呵呵。
对用户态异常，还是首先试图让核心调试器处理，如果不行才调用DbgkForwardExcepti
on函数试图分发，没有被处理的话则多次尝试，如果还是没被处理，就停止线程并报告异常
给用户。
伪代码如下：
以下为引用：
VOID KiDispatchException (IN PEXCEPTION_RECORD ExceptionRecord, IN PKEXCEPTION_F
RAME ExceptionFrame,
IN PKTRAP_FRAME TrapFrame, IN KPROCESSOR_MODE Previous
Mode, IN BOOLEAN FirstChance)
{
CONTEXT ContextFrame;
KeContextFromKframes(TrapFrame, ExceptionFrame, &ContextFrame); // 从核心异常
帧(Frame)构造异常上下文(Context)
if (ExceptionRecord->ExceptionCode == STATUS_BREAKPOINT)
{
ContextFrame.Eip--;
}
if (PreviousMode == KernelMode)
{
if (FirstChance == TRUE)
{
if (KiDebugRoutine && KiDebugRoutine(..., FALSE) != FALSE) goto Handle1
if(RtlDispatchException(ExceptionRecord, &ContextFrame) == TRUE) goto Hand
led1;
}
if (KiDebugRoutine && KiDebugRoutine(..., TRUE) != FALSE) goto Handle1
KeBugCheckEx(...); // 核心错误，以可控方式崩溃 -_-b 说白了就是Dead Blue Scre
en，呵呵
}
else // PreviousMode = UserMode
{
if (FirstChance == TRUE)
{
if (KiDebugRoutine && KiDebugRoutine(..., FALSE) != FALSE) goto Handle1
if (DbgkForwardException(ExceptionRecord, TRUE, FALSE)) goto Handled2;
// 将异常信息转换到用户模式，并尝试分发
}
if (DbgkForwardException(ExceptionRecord, TRUE, TRUE))
{
goto Handled2;
}
else if (DbgkForwardException(ExceptionRecord, FALSE, TRUE))
{
goto Handled2;
}
else
{
ZwTerminateThread(NtCurrentThread(), ExceptionRecord->ExceptionCode);
KeBugCheckEx(...);
}
}
Handled1:
KeContextToKframes(TrapFrame, ExceptionFrame, &ContextFrame,
ContextFrame.ContextFlags, PreviousMode);
Handled2:
}
DbgkForwardException函数分别针对DebugException和SecondChance参数的三种组合被
调用。DebugException为True时向调试端口发送信息，否则向异常端口发送
至此，几种常见的调试事件的引发机制就大概有了一个了解，下一节将介绍将这些调试
事件和最终用户态调试器关联起来的Win32中调试子系统的实现思路。
to be continue...
