调试器揭密

hzbooks

于 2009-06-09 09:20:00 发布

阅读量6.1k

点赞数

分类专栏：（1-4）佳文推荐文章标签： exception windows 编译器 microsoft c thread

本文链接：https://blog.csdn.net/hzbooks/article/details/4253591

版权

（1-4）佳文推荐专栏收录该内容

68 篇文章 1 订阅

订阅专栏

调试器揭密

Microsoft 的Windows 调试工具集包含了许多功能强大的工具，这些工具在提供对调试目标总体控制的同时，还能够将调试工作的开销保持在最低的水平。在命令窗口中执行每个命令时不需要进行确认，这就要求用户自己必须对所键入的命令负责。与任何其他的工具一样，如果对这个工具了解得越透彻，那么就越能深入地知道命令的一些副作用，并且也能越准确地预测命令的执行结果。我们曾经遇到过多次这样的情况：调试器中的应用程序停止在某个关键的位置，并且之后程序的任何执行都将不可逆转地改变调试目标的状态。我们不希望在这些情况中丢失调试会话，尤其当程序的故障非常难以重现时。在其他的一些情况中，被调试进程属于某个运行中的系统，此时你必须了解调试器对这个进程将产生怎样的影响；否则，你很可能需要重新启动系统，或者最糟糕的情况是，程序由于一些内部结构被破坏而导致了不可预测的行为。

本章将介绍调试器的一些特殊功能，并且阐述支持这些特殊功能的底层机制。本章将详细介绍调试器与操作系统之间的交互，以及调试器与调试目标之间的交互。在本章中，我们将分析：

? 调试器的工作原理及其与代码执行的关系。

? 操作系统和调试目标如何产生调试事件，尤其在发生软件异常的情况下。

? 操作系统如何与应用程序中的异常处理代码交互。

? 调试器如何控制调试目标，以及用户的调试行为将产生怎样的结果。这些内容使你能够根据调试任务的具体情况来优化调试技术。

本章将使用03sample.exe 程序，调试器将以全自动模式对这个程序执行一些基本的操作。调试器将不会要求用户输入命令以进入到下一个步骤，这个伪调试器（Pseudo Debugger ）将显示关于当前状态的一些信息，并且按照预先配置的模式执行。调试目标将作为命令参数传递给调试器。03sample.exe 的源代码文件和二进制文件分别位于以下文件夹中：

源代码文件：C:/AWD/Chapter3

二进制文件：C:/AWDBIN/WinXP.x86.chk/03sample.exe

这个示例程序将使用第2 章中的02sample.exe 作为调试目标。

3.1 用户态调试器的内幕

第2 章已经指出，Windows 调试工具集包含了用户态调试器和内核态调试器，这两种调试器都需要使用操作系统中的一些功能。用户态调试器是软件工程师们使用的主要工具，通常用来验证他们对代码的假设、算法的正确性，以及对程序中一些未预期的故障进行分析，本章将重点揭示用户态调试器的内幕。

在本节以及本章的大部分内容中，我们将介绍用户态调试器的工作原理，并且重点指出如何以最有效的方式来使用调试器的每个功能。

3.1.1 操作系统对用户态调试器的支持

Windows 操作系统通过一小组Win32 API 来提供对调试器的支持。用户态调试器将这些API 与其他普通的Win32 API 结合起来，从而提供强大的功能。

根据功能的不同，这些Win32API 可以被分为若干组，如下所示：

? 创建调试目标的API 。

? 在调试循环（Debugger Loop ）中处理调试事件的API 。

? 查看和修改调试目标的API ，这些API 将用于调试事件的处理过程中。

本节将讨论每一组API 的用法。

创建调试目标

在启动调试会话时，首先要创建调试目标。用户态调试器可以启动一个新进程，或者被附加到一个运行中的进程。之后，这个进程就成为新的调试目标，而调试器的所有行为都将作用于这个进程。操作系统将调试目标与当前的调试器关联起来，直到调试目标停止运行并退出，或者调试器主动中断与进程的关联。

调试器是通过CreateProcess 和DEBUG_PROCESS 标志来启动一个新进程以作为调试目标。03sample.exe 示例使用了清单3-1 中的代码来创建调试目标。进程的名字被作为CreateProcess API 的第2 个参数，同时也是03sample.exe 的第一个命令行参数argv[1] 。

清单3-1 在用户态调试器下启动一个进程

STARTUPINFOA startupInfo={0};

startupInfo.cb = sizeof(startupInfo);

PROCESS_INFORMATION processInfo = {0};

BOOL res = CreateProcess(NULL, argv[1], NULL, NULL, FALSE,

DEBUG_PROCESS , NULL, NULL, &startupInfo, &processInfo);

如果调试器向操作系统请求调试某个运行中的进程，并且通过DebugActiveProcess 附加到进程时，那么这个进程也将进入到调试状态。无论是通过附加到运行中的进程来创建调试目标，还是通过启动新的进程来创建调试目标，在调试器与操作系统之间的交互方式都是相同的。按照这种方式连接到调试目标的调试器称为活动调试器（Active Debugger ）。每个调试目标只能有一个活动调试器。

调试循环

当调试进程时，在这个进程执行的一些操作将会被通知给调试器。例如动态库的加载与卸载、新线程的创建、线程退出，以及在代码或处理器中抛出的异常等，这些都被认为是调试器需要知道的特殊事件。当这些事件需要被发送到调试器时，Windows 内核将首先挂起进程中的所有线程，然后把发生的事件通知给活动调试器，并且等待来自调试器的“恢复执行”命令。

在大多数时候，调试器会等待内核在执行WaitForDebugEvent 函数时返回的数据，只有当调试目标遇到了在前面介绍的特殊事件时才会生成这些数据。WaitForDebugEvent 将返回的事件信息封装在DEBUG_EVENT 结构，这个结构包含了所有可能的事件类型，调试器将通过这些类型来解析事件信息。当调试器分析DEBUG_EVENT 结构时，进程的状态不会发生改变，因为此时每个线程都被挂起了。

在解析和处理完事件后，调试器将调用ContinueDebugEvent 来继续调试目标的执行。然后，Windows 内核将根据在ContinueDebugEvent 中指定的参数来恢复调试目标的执行。根据事件类型的不同，内核可能会立即放弃事件并且取消对当前事件的处理。当产生的事件不是一个异常时，将从产生事件的位置开始恢复所有线程的执行。

这一系列的操作称为调试循环，调试循环将不断重复直到调试会话结束，例如由于调试目标不再存在或者调试器脱离（Detach ）调试目标而使得调试会话结束。清单3-2 给出了一个调试循环。

清单3-2 标准的用户态调试循环

for(DWORD endDisposition = DBG_CONTINUE;endDisposition != 0;)

{

DEBUG_EVENT debugEvent = { 0 } ;

WaitForDebugEvent(&debugEvent, INFINITE);

endDisposition = ProcessEvent(debugEvent);

ContinueDebugEvent(debugEvent.dwProcessId, debugEvent.dwThreadId, endDisposi-tion);

}

调试事件的处理

如果在调试循环中获得一个新的事件，那么调试器将对DEBUG_EVENT 结构中的信息进行解析，并且可能在返回调试循环之前将调试目标的控制权转交给调试器的使用者。清单3-3 给出了一个简单的事件处理函数，这个示例忽略了DEBUG_EVENT 结构中的任何信息，对于除EXIT_PROCESS_DEBUG_EVENT 之外的每种类型事件都将返回DBG_CONTINUE ，当事件为EXIT_PROCESS_DEBUG_EVENT 时函数将返回零。为了简单起见，函数的返回值不仅被用于结束循环，而且还被用作为ContinueDebugEvent 的参数。

清单3-3 简单的调试事件处理函数

DWORD ProcessEvent(DEBUG_EVENT& dbgEvent)

{

switch (dbgEvent.dwDebugEventCode)

{

case EXCEPTION_DEBUG_EVENT:

break;

case CREATE_THREAD_DEBUG_EVENT:

break;

case CREATE_PROCESS_DEBUG_EVENT:

break;

case EXIT_THREAD_DEBUG_EVENT:

break;

case EXIT_PROCESS_DEBUG_EVENT:

break;

case LOAD_DLL_DEBUG_EVENT:

break;

case UNLOAD_DLL_DEBUG_EVENT:

break;

case OUTPUT_DEBUG_STRING_EVENT:

break;

case RIP_EVENT:

break;

}

return DBG_CONTINUE ;

}

在接下来的内容中，我们将进一步讨论清单3-3 中的一些调试事件，并且为它们提供合理的默认行为。03sample.exe 没有包含其他调试事件，读者可以作为一个练习来理解和掌握这些调试事件。请注意，功能完备的调试器通常可以使用户在调用ContinueDebugEvent 之前首先查看和修改调试目标的状态。

处理OUTPUT_DEBUG_STRING_EVENT

软件工程师们经常会在代码中使用调试输出命令，这是为了通过调试输出命令这种较为简单的手段来找出代码中的问题。在不同语言中，调试输出命令的语法是不同的，但大多数语法最终都会调用Windows 提供的某个调试系统函数，例如OutputDebugStringA 或者OutputDebugStringW 。调试器将把调试目标输出的字符串通过事件处理代码显示出来，如清单3-4 所示。DEBUG_EVENT 结构包含了一个OUTPUT_DEBUG_STRING_INFO 结构，这个结构又包含了特定事件的信息。成员lpDebugStringData 包含了将要被显示的字符串的地址，这个地址位于调试目标的地址空间中， nDebugStringLength 包含的是字符串的长度，fUnicode 则表示字符是Unicode 还是ANSI 。代码通过产生事件的进程的句柄来从调试目标的地址空间中读取信息。

清单3-4 处理输出调试字符串的事件

case OUTPUT_DEBUG_STRING_EVENT:

//typedef struct _OUTPUT_DEBUG_STRING_INFO {

// LPSTR lpDebugStringData;

// WORD fUnicode;

// WORD nDebugStringLength;

//} OUTPUT_DEBUG_STRING_INFO, *LPOUTPUT_DEBUG_STRING_INFO;

{

OUTPUT_DEBUG_STRING_INFO& OutputDebug = dbgEvent.u.DebugString;

WCHAR * msg = ReadRemoteString(hTargetProcessHandle, OutputDebug.lpDebugString-Data,

OutputDebug.nDebugStringLength, OutputDebug.fUnicode);

std::wcout << L"OutputDebugStringEvent/nMessage:/t";

std::wcout <<<< msg << std::endl;

delete[] msg;

break;

}

清单3-4 使用的ReadRemoteString 函数是一个辅助函数，它抽象了OUTPUT_ DEBUG_ STRING_INFO 结构中的字符大小以及字符串的长度。函数调用了kernel32!ReadProcessMemory 。ReadRemoteString 将从调试目标的地址空间中读取字符串，并将其转换为03sample.exe 所需的空字符结尾字符串。清单3-5 给出了ReadRemoteString 的实现。

清单3-5 从调试目标的地址空间中读取指定长度的字符串

WCHAR *

ReadRemoteString(HANDLE process,LPVOID address,WORD length,BOOL unicode)

{

WCHAR * msg = new WCHAR[length];

if (!msg) return NULL;

memset(msg, 0, sizeof(WCHAR)*(length));

if ( unicode )

{

ReadProcessMemory(process, address ,msg, length*sizeof(WCHAR),NULL);

return msg;

}

else

{

CHAR * originalMsg = new CHAR[length];

if (!originalMsg)

{

delete[] msg;

return NULL;

}

memset(originalMsg, 0, sizeof(BYTE)*(length));

ReadProcessMemory(process, address ,originalMsg, length,NULL);

for (WORD i = 0; i < length; i++)

{

msg[i] = originalMsg[i];

}

delete[] originalMsg;

return msg;

}

当在调试器控制台中输出字符串后，调试循环将继续执行。当调试器重新进入循环后，调试目标将继续执行。调试目标执行的这种行为将改变程序的执行时间，因此可能隐藏或者暴露出程序中的竞态条件问题。

处理EXCEPTION_DEBUG_EVENT

调试目标在其生命周期中可以产生多种类型的异常—对于每种不同的异常类型，调试器将采取不同的处理方式。有些异常对调试器本身有着特殊的含义，而其他异常则是对调试目标有着运行时的含义。调试器的异常处理器可能是非常复杂的。本节将只介绍一些有助于理解调试器异常处理过程的基本知识。

对于EXCEPTION_DEBUG_EVENT 调试事件来说， DEBUG_EVENT 结构包含的是一个EXCEPTION_ DEBUG_INFO 结构，在这个结构中又包含了一个成员ExceptionRecord ，类型为EXCEPTION_RECORD ，这个成员包含了异常信息的一个副本，如清单3-6 所示。调试器将从EXCEPTION_RECORD 结构中获得异常码、引发异常的地址以及异常参数等。EXCEPTION_DEBUG_EVENT 中的第2 个成员dwFirstChance 将告诉调试器是否是第一轮通知这个异常。本章在后面将对第一轮（First Chance ）异常通知与第二轮（Second Chance ）异常通知进行详细讨论。

从Windows 操作系统的角度来看，调试器必须对异常进行解析，并且将DBG_CONTINUE 或者DBG_EXCEPTION_NOT_HANDLED 作为CotinueDebugEvent 函数的参数。如果指定的是DBG_CONTINUE 参数，那么Windows 假设异常已经被正确地处理了，导致异常发生的条件也已经不复存在了，因此将从产生异常的地址开始恢复程序的执行。如果指定的是DBG_ EXCEPTION_ NOT_HANDLED 参数，那么Windows 表现出来的行为就好像是调试器并不存在，并且将继续它的异常分发流程。

清单3-6 给出了在03sample.exe 中的异常处理器，对于大多数异常来说，这个函数并不会影响Windows 的异常机制。由于Windows 操作系统通过STATUS_BREAKPOINT 异常将其他一些特殊的操作通知给调试器，因此对于这种异常，我们的异常处理器将返回DBG_CONTINUE 。

清单3-6 处理异常调试事件

case EXCEPTION_DEBUG_EVENT:

//typedef struct _EXCEPTION_DEBUG_INFO {

// EXCEPTION_RECORD ExceptionRecord;

// DWORD dwFirstChance;

//} EXCEPTION_DEBUG_INFO;

std::cout << "ExceptiondebugEvent/nException Code:/t " << std::hex <<

dbgEvent.u.Exception.ExceptionRecord.ExceptionCode;

std::cout << "/tFirstChance:/t" << dbgEvent.u.Exception.dwFirstChance

<<std::endl;

switch (dbgEvent.u.Exception.ExceptionRecord.ExceptionCode)

{

case EXCEPTION_BREAKPOINT:

case EXCEPTION_SINGLE_STEP:

return DBG_CONTINUE;

}

return DBG_EXCEPTION_NOT_HANDLED;

处理函数的返回值将被返回到Windows 中，并被作为ContinueDebugEvent 的最后一个参数，参数的名字为dwContinueStatus 。

3.1.2 调试事件的顺序

在调试循环从WaitForDebugEvent 中返回以及调用ContinueDebugEvent 之间的这段时间里，调试目标不会运行，并且它的状态也将保持不变。当挂起调试目标时，调试器将进入交互模式，接受并且执行用户键入的命令。在程序执行中，调试器可以通过API 来找出更多关于调试目标以及调试事件的信息，此外调试器还可以调用其他的Win32 API 来满足用户的需求。如果在调试器中键入一个执行命令，那么调试器将调用ContinueDebugEvent 并且等待下一个事件。

在有了所有这些信息和代码之后，就可以通过03sample.exe 来获得调试目标产生的所有事件。清单3-7 包含了在运行示例程序时产生的控制台输出，其中xcopy.exe 用作参数和调试目标。

清单3-7 在简单的进程执行（xcopy.exe ）中产生的调试事件

C:/>C:/AWDBIN /WinXP.x86.chk /03sample.exe xcopy.exe