CSDN博客

img flier_lu

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

发表于2004/4/5 22:53:00  975人阅读

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

0 0

相关博文

我的热门文章

img
取 消
img