Win32 调试接口设计与实现浅析 [2] 调试事件

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中调试子系统的实现思路。

本文地址：http://com.8s8s.com/it/it1069.htm