http://flier_lu.blogone.net/?id=1324316
[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_THREAD_DEBUG_EVENT事件被引发；每次载入/卸载一个DLL时会有LOAD_DLL_DEBUG_EVENT/UNLOAD_DLL_DEBUG_EVENT事件被引发；被调试程序使用OutputDebugString函数输出一个调试字符串时调试器会接受到一个OUTPUT_DEBUG_STRING_EVENT事件；异常被引发时调试器会接受到一个第一时间的EXCEPTION_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
接下来我们详细分析每种调试事件被引发的原因和时机。具体的调试事件内容这里就不罗嗦了，有兴趣写调试器的朋友可以参考MSDN和<Debugging Applications>中相关内容。
首先是建立进程的CREATE_PROCESS_DEBUG_EVENT事件和建立线程的CREATE_THREAD_DEBUG_EVENT事件。这两个事件都是由DbgkCreateThread函数(ntos\dbgk\dbgkproc.h:211)引发的。此函数首先检查当前线程是否是具有调试端口的活动线程；然后检查当前线程是否是进程的创建的第一个线程；如果不是第一个线程，或者调试器是挂接(attach)到一个活动进程上（判断依据是此进程是否占用过用户态的CPU时间），则向调试子系统的调试服务器引发CREATE_THREAD_DEBUG_EVENT事件；否则转而报告CREATE_PROCESS_DEBUG_EVENT事件。
DbgkCreateThread函数伪代码如下：
以下为引用：
VOID DbgkCreateThread(PVOID StartAddress)
{
if(!PsGetCurrentProcess()->DebugPort || PsGetCurrentThread()->DeadThread)
{
return;
}
PsLockProcess(Process,KernelMode,PsLockWaitForever); // 锁定进程中所有线程
if(PsGetCurrentProcess()->Pcb.UserTime &&
PsGetCurrentProcess()->CreateProcessReported == FALSE)
{
PsGetCurrentProcess()->CreateProcessReported = TRUE;
// 引发 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)作为线程入口函数，因此线程被创建后直接进入此函数。PspUserThreadStartup函数对非僵死线程和没有结束的线程初始化其APC；然后调用DbgkCreateThread函数通知调试器采取相应动作；最后将进程的用户态CPU时间设置为1，以标示此进程已启动。对一种特殊线程，非僵死线程但线程启动时已经停止，则直接调用DbgkCreateThread然后立刻调用PspExitThread，以通知调试器采取相应动作。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_DEBUG_EVENT和EXIT_PROCESS_DEBUG_EVENT事件。
这两个函数由系统内核退出线程的PspExitThread函数(ntos\ps\psdelete.c:622)在合适的时候调用。PspExitThread函数检测当前进程PCB的线程列表是否只有当前线程一个线程，如果没有其他线程则调用DbgkExitProcess函数，否则调用DbgkExitThread函数。
Win32 系统中载入和卸载DLL，实际的函数调用流程如下：
以下为引用：
LoadLibrary (kernel32.dll)
LoadLibraryEx (kernel32.dll)
BasepLoadLibraryAsDataFile (kernel32.dll)
NtMapViewOfSection (ntos\mm\mapview.c:204)
MmMapViewOfSection (ntos\mm\mapview.c:699)
NtMapViewOfSection函数在调用MmMapViewOfSection函数(ntos\mm\mapview.c:699)完成实际的内存文件映射之后，会根据映射节的标记位以及目标进程是否是当前进程，判断是否要调用DbgkMapViewOfSection函数(ntos\dbgk\dbgkproc.c:495)，通知调试服务器有新的映象文件被加载。与之对应MmUnmapViewOfSection函数(ntos\mm\umapview.c:88)也在判断标志位和目标进程是否是当前进程后，在函数末尾调用DbgkUnMapViewOfSection函数(ntos\dbgk\dbgkproc.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\exceptn.c:797)中被调用。KiDispatchException函数根据异常被引发时的状态，分别完成核心和用户态的异常处理工作。
对核心态异常，首先给核心调试程序一个处理机会，然后试图分发到基于帧的SEH异常链去，没有被处理的话则再给核心调试程序一个机会，如果还是没被处理，就只能调用KeBugCheckEx函数(ntos\ke\bugcheck.c:157)蓝屏了，呵呵。
对用户态异常，还是首先试图让核心调试器处理，如果不行才调用DbgkForwardException函数分发，没有被处理的话则多次尝试，如果还是没被处理，就停止线程并报告异常给用户。KiDispatchException函数伪代码如下：
以下为引用：
VOID KiDispatchException (IN PEXCEPTION_RECORD ExceptionRecord, IN PKEXCEPTION_FRAME ExceptionFrame,
IN PKTRAP_FRAME TrapFrame, IN KPROCESSOR_MODE PreviousMode, IN BOOLEAN FirstChance)
{
CONTEXT ContextFrame;
KeContextFromKframes(TrapFrame, ExceptionFrame, &ContextFrame); // 从核心异常帧(Frame)构造异常上下文(Context)
if (ExceptionRecord->ExceptionCode == STATUS_BREAKPOINT) // 处理调试断点 int 3
{
ContextFrame.Eip--;
}
if (PreviousMode == KernelMode)
{
if (FirstChance == TRUE)
{
if (KiDebugRoutine && KiDebugRoutine(..., FALSE) != FALSE) goto Handle1
if(RtlDispatchException(ExceptionRecord, &ContextFrame) == TRUE) goto Handled1;
}
if (KiDebugRoutine && KiDebugRoutine(..., TRUE) != FALSE) goto Handle1
KeBugCheckEx(...); // 核心错误，以可控方式崩溃 -_-b 说白了就是Deadth Blue Screen，呵呵
}
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中调试子系统的实现思路。
