Win32结构化异常处理（SEH）探秘(上)

核心提示：在这段伪码中，注意对 lpfnEntryPoint 的调用被封装在一个__try 和 __except 块中，Win32结构化异常处理（SEH）探秘(上)(6)，正是此__try 块安装了默认的、异常处理程序链表上的最后一个异常处理程序，所有后来注册的异常处理程序都被安装在此链表中这个结点的前面，这个技巧是通过一个通常

在这段伪码中，注意对 lpfnEntryPoint 的调用被封装在一个__try 和 __except 块中。正是此__try 块安装了默认的、异常处理程序链表上的最后一个异常处理程序。所有后来注册的异常处理程序都被安装在此链表中这个结点的前面。如果 lpfnEntryPoint 函数返回，那么表明线程一直运行到完成并且没有引发异常。这时 BaseProcessStart 调用 ExitThread 使线程退出。

另一方面，如果线程引发了一个异常但是没有异常处理程序来处理它时，该怎么办呢？这时，执行流程转到 __except 关键字后面的括号中。在 BaseProcessStart 中，这段代码调用 UnhandledExceptionFilter 这个 API，稍后我会讲到它。现在对于我们来说，重要的是 UnhandledExceptionFilter 这个API包含了默认的异常处理程序。

如果 UnhandledExceptionFilter 返回 EXCEPTION_EXECUTE_HANDLER，这时 BaseProcessStart 中的__except 块开始执行。而__except块所做的只是调用 ExitProcess 函数去终止当前进程。稍微想一下你就会理解了。常识告诉我们，如果一个进程引发了一个错误而没有异常处理程序去处理它，这个进程就会被系统终止。你在伪代码中看到的正是这些。

对于上述内容我还有一点要补充。如果引发错误的线程是作为服务来运行的，并且是基于线程的服务，那么__except 块并不调用 ExitProcess，而是调用 ExitThread。不能仅仅因为一个服务出错就终止整个服务进程。

UnhandledExceptionFilter 中的默认异常处理程序都做了什么呢？当我在一个技术讲座上问起这个问题时，响应者寥寥无几。几乎没有人知道当未处理异常发生时，到底操作系统的默认行为是什么。简单地演示一下这个默认的行为也许会让很多人豁然开朗。我运行一个故意引发错误的程序，其结果如下（如图八）。

图八 未处理异常对话框

表面上看，UnhandledExceptionFilter 显示了一个对话框告诉你发生了一个错误。这时，你被给予了一个机会要么终止出错进程，要么调试它。但是幕后发生了许多事情，我会在文章最后详细讲述它。

正如我让你看到的那样，当异常发生时，用户写的代码可以（并且通常是这样）获得机会执行。同样，在操作过程中，用户写的代码可以执行。此用户编写的代码也可能有缺陷并可能引发另一个异常。由于这个原因，异常处理回调函数也可以返回另外两个值： ExceptionNestedException 和 ExceptionCollidedUnwind。很明显，它们很重要。但这是非常复杂的问题，我并不打算在这里详细讲述它们。要想理解其基本概念真的太困难了。

编译器级的SEH

虽然我在前面偶尔也使用了__try 和__except，但迄今为止几乎我写的所有内容都是关于操作系统方面对 SEH 的实现。然而看一下我那两个使用操作系统的原始 SEH 的小程序别扭的样子，编译器对这个功能进行封装实在是非常有必要的。现在让我们来看一下 Visual C++ 是如何在操作系统对 SEH 功能实现的基础上来创建它自己的结构化异常处理支持的。

在继续往下讨论之前，记住其它编译器可以使用原始的系统 SEH 来做一些完全不同的事情这一点是非常重要的。没有谁规定编译器必须实现 Win32 SDK 文档中描述的__try/__except 模型。例如 Visual Basic 5.0 在它的运行时代码中使用了结构化异常处理，但是那里的数据结构和算法与我这里要讲的完全不同。

如果你把 Win32 SDK 文档中关于结构化异常处理方面的内容从头到尾读一遍，一定会遇到下面所谓的“基于帧”的异常处理程序模型：

__try　{
//　这里是被保护的代码
}
__except　(过滤器表达式)　{
//　这里是异常处理程序代码
}

简单地说，某个函数__try 块中的所有代码是由 EXCEPTION_REGISTRATION 结构来保护的，该结构建立在此函数的堆栈帧上。在函数的入口处，这个新的 EXCEPTION_REGISTRATION 结构被放在异常处理程序链表的头部。在__try 块结束后，相应的 EXCEPTION_REGISTRATION 结构从这个链表的头部被移除。正如我前面所说，异常处理程序链表的头部被保存在 FS:[0] 处。因此，如果你在调试器中单步跟踪时能看到类似下面的指令

MOV　DWORD　PTR　FS:[00000000],ESp
或者
MOV　DWORD　PTR　FS:[00000000],ECX

就能非常确定这段代码正在进入或退出一个__try/__except块。

既然一个__try 块对应着堆栈上的一个 EXCEPTION_REGISTRATION 结构，那么 EXCEPTION_REGISTRATION 结构中的回调函数又如何呢？使用 Win32 的术语来说，异常处理回调函数对应的是过滤器表达式（filter-expression）代码。事实上，过滤器表达式就是__except 关键字后面的小括号中的代码。就是这个过滤器表达式代码决定了后面的大括号中的代码是否执行。

由于过滤器表达式代码是你自己写的，你当然可以决定在你的代码中的某个地方是否处理某个特定的异常。它可以简单的只是一句 “EXCEPTION_EXECUTE_HANDLER”，也可以先调用一个把p计算到20,000,000位的函数，然后再返回一个值来告诉操作系统下一步做什么。随你的便。关键是你的过滤器表达式代码必须是我前面讲的有效的异常处理回调函数。

我刚才讲的虽然相当简单，但那只不过是隔着有色玻璃看世界罢了。现实是非常复杂的。首先，你的过滤器表达式代码并不是被操作系统直接调用的。事实上，各个 EXCEPTION_REGISTRATION 结构的 handler 域都指向了同一个函数。这个函数在 Visual C++ 的运行时库中，它被称为__except_handler3。正是这个__except_handler3 调用了你的过滤器表达式代码，我一会儿再接着说它。

对我前面的简单描述需要修正的另一个地方是，并不是每次进入或退出一个__try 块时就创建或撤销一个 EXCEPTION_REGISTRATION 结构。相反，在使用 SEH 的任何函数中只创建一个 EXCEPTION_REGISTRATION 结构。换句话说，你可以在一个函数中使用多个 __try/__except 块，但是在堆栈上只创建一个 EXCEPTION_REGISTRATION 结构。同样，你可以在一个函数中嵌套使用 __try 块，但 Visual C++ 仍旧只是创建一个 EXCEPTION_REGISTRATION 结构。

如果整个 EXE 或 DLL 只需要单个的异常处理程序（__except_handler3），同时，如果单个的 EXCEPTION_REGISTRATION 结构就能处理多个__try 块的话，很明显，这里面还有很多东西我们不知道。这个技巧是通过一个通常情况下看不到的表中的数据来完成的。由于本文的目的就是要深入探索结构化异常处理，那就让我们来看一看这些数据结构吧。