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

核心提示：扩展的异常处理帧Visual C++ 的 SEH 实现并没有使用原始的 EXCEPTION_REGISTRATION 结构，它在这个结构的末尾添加了一些附加数据，Win32结构化异常处理（SEH）探秘(上)(7)，这些附加数据正是允许单个函数（__except_handler3）处理所有异常并将执行流程传递到相应的过滤

扩展的异常处理帧

Visual C++ 的 SEH 实现并没有使用原始的 EXCEPTION_REGISTRATION 结构。它在这个结构的末尾添加了一些附加数据。这些附加数据正是允许单个函数（__except_handler3）处理所有异常并将执行流程传递到相应的过滤器表达式和__except 块的关键。我在 Visual C++ 运行时库源代码中的 EXSUP.INC 文件中找到了有关 Visual C++ 扩展的 EXCEPTION_REGISTRATION 结构格式的线索。在这个文件中，你会看到以下定义（已经被注释掉了）：

;struct　_EXCEPTION_REGISTRATION{
;　struct　_EXCEPTION_REGISTRATION　*prev;
;　void　(*handler)(　PEXCEPTION_RECORD,
;　PEXCEPTION_REGISTRATION,
;　PCONTEXT,
;　PEXCEPTION_RECORD);
;　struct　scopetable_entry　*scopetable;
;　int　trylevel;
;　int　_ebp;
;　PEXCEPTION_POINTERS　xpointers;
;};

在前面你已经见过前两个域：prev 和 handler。它们组成了基本的 EXCEPTION_REGISTRATION 结构。后面三个域：scopetable（作用域表）、trylevel 和_ebp 是新增加的。scopetable 域指向一个 scopetable_entry 结构数组，而 trylevel 域实际上是这个数组的索引。最后一个域_ebp，是 EXCEPTION_REGISTRATION 结构创建之前栈帧指针（EBP）的值。

_ebp 域成为扩展的 EXCEPTION_REGISTRATION 结构的一部分并非偶然。它是通过 PUSH EBP 这条指令被包含进这个结构中的，而大多数函数开头都是这条指令（通常编译器并不为使用FPO优化的函数生成标准的堆栈帧，这样其第一条指令可能不是 PUSH EBP。但是如果使用了SEH的话，那么无论你是否使用了FPO优化，编译器一定生成标准的堆栈帧）。这条指令可以使 EXCEPTION_REGISTRATION 结构中所有其它的域都可以用一个相对于栈帧指针（EBP）的负偏移来访问。例如 trylevel 域在 [EBP-04]处，scopetable 指针在[EBP-08]处，等等。（也就是说，这个结构是从[EBP-10H]处开始的。）

紧跟着扩展的 EXCEPTION_REGISTRATION 结构下面，Visual C++ 压入了另外两个值。紧跟着（即[EBP-14H]处）的一个DWORD，是为一个指向 EXCEPTION_POINTERS 结构（一个标准的Win32 结构）的指针所保留的空间。这个指针就是你调用 GetExceptionInformation 这个API时返回的指针。尽管SDK文档暗示 GetExceptionInformation 是一个标准的 Win32 API，但事实上它是一个编译器内联函数。当你调用这个函数时，Visual C++ 生成以下代码：

MOV　EAX,DWORD　PTR　[EBP-14]

GetExceptionInformation 是一个编译器内联函数，与它相关的 GetExceptionCode 函数也是如此。此函数实际上只是返回 GetExceptionInformation 返回的数据结构（EXCEPTION_POINTERS）中的一个结构（EXCEPTION_RECORD）中的一个域（ExceptionCode）的值。当 Visual C++ 为 GetExceptionCode 函数生成下面的指令时，它到底是想干什么？我把这个问题留给读者。（现在就能理解为什么SDK文档提醒我们要注意这两个函数的使用范围了。）

MOV　EAX,DWORD　PTR　[EBP-14]　;　执行完毕，EAX指向EXCEPTION_POINTERS结构
MOV　EAX,DWORD　PTR　[EAX]　;　执行完毕，EAX指向EXCEPTION_RECORD结构
MOV　EAX,DWORD　PTR　[EAX]　;　执行完毕，EAX中是ExceptionCode的值

现在回到扩展的 EXCEPTION_REGISTRATION 结构上来。在这个结构开始前的8个字节处（即[EBP-18H]处），Visual C++ 保留了一个DWORD来保存所有prolog代码执行完毕之后的堆栈指针（ESP）的值（实际生成的指令为MOV DWORD PTR [EBP-18H],ESP）。这个DWORD中保存的值是函数执行时ESP寄存器的正常值（除了在准备调用其它函数时把参数压入堆栈这个过程会改变 ESP寄存器的值并在函数返回时恢复它的值外，函数在执行过程中一般不改变ESP寄存器的值）。

看起来好像我一下子给你灌输了太多的信息，我承认。在继续下去之前，让我们先暂停，来回顾一下 Visual C++ 为使用结构化异常处理的函数生成的标准异常堆栈帧，它看起来像下面这个样子：

EBP-00　_ebp
EBP-04　trylevel
EBP-08　scopetable数组指针
EBP-0C　handler函数地址
EBP-10指向前一个EXCEPTION_REGISTRATION结构
EBP-14　GetExceptionInformation
EBP-18　栈帧中的标准ESP

在操作系统看来，只存在组成原始 EXCEPTION_REGISTRATION 结构的两个域：即[EBP-10h]处的prev指针和[EBP-0Ch]处的handler函数指针。栈帧中的其它所有内容是针对于Visual C++的。把这个Visual C++生成的标准异常堆栈帧记到脑子里之后，让我们来看一下真正实现编译器层面SEH的这个Visual C++运行时库例程——__except_handler3。

__except_handler3 和 scopetable

我真的很希望让你看一看Visual C++运行时库源代码，让你自己好好研究一下__except_handler3函数，但是我办不到。因为 Microsoft并没有提供。在这里你就将就着看一下我为__except_handler3函数写的伪代码吧：。

图九 __except_handler3函数的伪代码：

int　__except_handler3(
struct　_EXCEPTION_RECORD　*　pExceptionRecord,
struct　EXCEPTION_REGISTRATION　*　pRegistrationFrame,
struct　_CONTEXT　*pContextRecord,
void　*　pDispatcherContext　)
{
LONG　filterFuncRet;
LONG　trylevel;
EXCEPTION_POINTERS　exceptPtrs;
PSCOPETABLE　pScopeTable;
CLD　//　将方向标志复位（不测试任何条件！）
//　如果没有设置EXCEPTION_UNWINDING标志或EXCEPTION_EXIT_UNWIND标志
//　表明这是第一次调用这个处理程序（也就是说，并非处于异常展开阶段）
if　(　!　(pExceptionRecord->ExceptionFlags
&　(EXCEPTION_UNWINDING　|　EXCEPTION_EXIT_UNWIND))　)
{
//　在堆栈上创建一个EXCEPTION_POINTERS结构
exceptPtrs.ExceptionRecord　=　pExceptionRecord;
exceptPtrs.ContextRecord　=　pContextRecord;
//　把前面定义的EXCEPTION_POINTERS结构的地址放在比
//　establisher栈帧低4个字节的位置上。参考前面我讲
//　的编译器为GetExceptionInformation生成的汇编代
//　码*(PDWORD)((PBYTE)pRegistrationFrame　-　4)　=　&exceptPtrs;
//　获取初始的“trylevel”值
trylevel　=　pRegistrationFrame->trylevel;
//　获取指向scopetable数组的指针
scopeTable　=　pRegistrationFrame->scopetable;
search_for_handler:
if　(　pRegistrationFrame->trylevel　!=　TRYLEVEL_NONE　)
{
if　(　pRegistrationFrame->scopetable[trylevel].lpfnFilter　)
{
PUSH　EBP　//　保存这个栈帧指针
//　！！！非常重要！！！切换回原来的EBP。正是这个操作才使得
//　栈帧上的所有局部变量能够在异常发生后仍然保持它的值不变。
EBP　=　&pRegistrationFrame->_ebp;
//　调用过滤器函数
filterFuncRet　=　scopetable[trylevel].lpfnFilter();
POP　EBP　//　恢复异常处理程序的栈帧指针
if　(　filterFuncRet　!=　EXCEPTION_CONTINUE_SEARCH　)
{
if　(　filterFuncRet　<　0　)　//　EXCEPTION_CONTINUE_EXECUTION
return　ExceptionContinueExecution;
//　如果能够执行到这里，说明返回值为EXCEPTION_EXECUTE_HANDLEr
scopetable　=　pRegistrationFrame->scopetable;
//　让操作系统清理已经注册的栈帧，这会使本函数被递归调用
__global_unwind2(　pRegistrationFrame　);
//　一旦执行到这里，除最后一个栈帧外，所有的栈帧已经
//　被清理完毕，流程要从最后一个栈帧继续执行
EBP　=　&pRegistrationFrame->_ebp;
__local_unwind2(　pRegistrationFrame,　trylevel　);
//　NLG　=　"non-local-goto"　(setjmp/longjmp　stuff)
__NLG_Notify(　1　);　//　EAX　=　scopetable->lpfnHandler
//　把当前的trylevel设置成当找到一个异常处理程序时
//　SCOPETABLE中当前正在被使用的那一个元素的内容
pRegistrationFrame->trylevel　=　scopetable->previousTryLevel;
//　调用__except　{}块，这个调用并不会返回
pRegistrationFrame->scopetable[trylevel].lpfnHandler();
}
}
scopeTable　=　pRegistrationFrame->scopetable;
trylevel　=　scopeTable->previousTryLevel;
goto　search_for_handler;
}
else　//　trylevel　==　TRYLEVEL_NONE
{
return　ExceptionContinueSearch;
}
}
else　//　设置了EXCEPTION_UNWINDING标志或EXCEPTION_EXIT_UNWIND标志
{
PUSH　EBP　//　保存EBp
EBP　=　&pRegistrationFrame->_ebp;　//　为调用__local_unwind2设置EBp
__local_unwind2(　pRegistrationFrame,　TRYLEVEL_NONE　)
POP　EBP　//　恢复EBp
return　ExceptionContinueSearch;
}
}