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

图八 未处理异常对话框

表面上看，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 调用了你的过滤器表达式代码，我一会儿再接着说它。

对我前面的简单描述需要修正的另一个地方是，并不是每次进入或退

凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!