Win32结构化异常处理(SEH)——异常处理程序(__try/__except)

环境：VC++6.0, Windows XP SP3

        上一篇中，我们看到了如何实现一个终止处理程序，和系统级的异常处理程序，在这一篇中，我们要着重看一下VC++6.0的异常处理程序是如何实现的。

        这里要用的结构体有：

 

　　 typedef struct _SCOPETABLE
　　{
　　　　DWORD       previousTryLevel;
　　　　DWORD       lpfnFilter
　　　　DWORD       lpfnHandler
　　} SCOPETABLE, *PSCOPETABLE;

　　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;
　　};

 

        如果你不知道这两个结构体是干嘛的，建议你先看一下前一篇文章，再来看这里。

        我们知道在系统级的异常处理程序中，那个SEH链上串的EXCEPTION_REGISTRATION结构体只有两项，就是上面的结构体的前两项，而且系 统级的异常处理中没有我们现在所用的过滤函数和处理函数之分，只有一个handler，而现在我们在用C语言或都C++写程序时，用到的SEH时，都有过 滤函数(就是except后面的小括号里的内容)和处理函数(就是except后面的大括号里的内容)，其实系统SEH并没有给我们提供这样的服务，我们 之所以可以这样用，是因为编译器的原因。至于系统是如何做SEH的，在上一篇文章我已经说了。现在我们来看一下，VC++6.0是怎样做的。

        在VC++6.0中，基本上说只有一个异常处理函数(为什么说是基本上，后面我会说的)——__except_handler3，这个函数的指针会在产生 一个EXCEPTION_REGISTRATION结构时，赋给其成员handler，以后如果产生异常，系统就会调用这个函数，再由这个函数调用用户写 的异常处理函数，也就是说，用户写的异常处理函数(就是你自己写的except后面大括号里的内容)是没有注册到 EXCEPTION_REGISTRATION中的。那么，用户自己的异常处理函数在哪里呢？其实，编译器把用户的异常处理函数放到了一个结构体数组中， 这个结构体类型就是SCOPETABLE，每个try块会对应这么一个结构体，结构体中保存了它到底是哪一个try块(previousTryLevel 表示它的上一层try块的编号，最外层的try块的trylevel为0，所以，可以想像最外层的try块的previousTryLevel为-1)， 它的过滤函数以及异常处理函数。在一个函数中出现的try块，编译器会把这些try块对应的SCOPETABLE结构体放到一个数组里，并把这个数组的首 地址给这个函数的EXCEPTION_REGISTRATION结构的成员scopetable。这样，我想大家应该就可以基本上理解系统产生一个异常 时，编译器是如何处理的了。

        在上面一话段中，你可能会发现一个函数拥有一个EXCEPTION_REGISTRATION结构，通过这个结构中可以访问这个函数中所在的try块，其 实就是这样的，这就是VC++6.0对SEH所做的一些修改，如果你有多个函数中使用了SEH，那么你会发现fs:[0]上有多个 EXCEPTION_REGISTRATION结构。虽然这和我们看到的系统级SEH不太一样，但这里的SEH与系统的SEH是兼容的，你仔细看这里的 EXCEPTION_REGISTRATION结构，你会发现前两项与系统的一样，不一样的内容只是在后面，所以系统看到编译器产生的SEH结构以后，也 是可以认得的。

        加一句，后面我会为了方便把EXCEPTION_REGISTRATION结构称为frame，声明一下。

        到这里，我相信大家可以大致想像一下VC++6.0处理后的SEH是怎么运行的了吧。下面，我会仔细说一下这个过程的。

        我们先看一下结构体EXCEPTION_REGISTRATION，这个结构体和系统的不一样，但是，为什么要这样设计呢？前四项我就不说了，大家都能看懂，现在就剩下两个了，_ebp，xpointers。

        先看_ebp，这个成员保存的值是产生这个frame的函数的栈帧指针，为的是得到这个frame后，可以轻松访问其栈帧，还有一个作用就是在当前函数 里，你可以通过对ebp的负偏移来访问这个frame中的成员，比如trylevel是[ebp - 04h]，scopetable是[ebp - 08h]等等。

        再来看看xpointers。我们知道，在异常处理时，有一个API叫LPEXCEPTION_POINTERS GetExceptionInformation(void)，这个函数的做用是返回异常信息，下面是EXCEPTION_POINTERS的定义，看一 下就行了，目前对我们没什么用：

 

　　 typedef struct _EXCEPTION_POINTERS {
　　　　PEXCEPTION_RECORD ExceptionRecord;
　　　　PCONTEXT ContextRecord;
　　} EXCEPTION_POINTERS;

 

MSDN中对这个函数有一句话： The filter expression can invoke a filter function. The filter function cannot call GetExceptionInformation . However, the return value of GetExceptionInformation can be passed as a parameter to a filter function. 是什么意思呢，就是说GetExceptionInformation这个函数只能在except后面的那个小括号里被调用，为什么有这么奇怪的一条规定呢，我们来看一下这个函数的实现，就一句：

 

mov eax, dword ptr [ebp - 14h]

 

这是什么意 思呢，我们再看看EXCEPTION_REGISTRATION的定义，会发现ebp - 14h就是成员xpointers，这时你可能会想，只要在产生EXCEPTION_REGISTRATION的函数里调用 GetExceptionInformation应该也可以啊，为什么只能在except后面的小括号里调用啊？你可以把一个用SEH的程序用 VC++6.0反汇编后看看，你会发现，在程序开始设置frame的值的时候，并没有设置xpointers的值，而这个值是在 __except_handler3里被设定的，所以 如果你在除了except后面的小括号里调用GetExceptionInformation的时候得到的值是无效的！！

        看到这儿，过程已经慢慢清楚了，但是还不是很清楚，因为整个过程的实现是通过函数__except_handler3来做的，下面让我们看看这个函数是什 么内容，因为找到一组伪代码，所以用伪代码来分析(有点儿长，大家忍着点儿，不过看汇编的更长，呵呵)：

 

int __except_handler3(        //从参数来看，就是我们上一篇文章中提到的那个回调函数，这儿不多说了
     struct _EXCEPTION_RECORD * pExceptionRecord,
     struct EXCEPTION_REGISTRATION * pRegistrationFrame,
     struct _CONTEXT *pContextRecord,
     void * pDispatcherContext )
{
     LONG filterFuncRet                   //没什么意思，往后看就知道这个变量是干什么的了
     LONG trylevel                             //搞一个局部变量来存pRegistrationFrame->trylevel
     EXCEPTION_POINTERS exceptPtrs                         //这个就是GetExceptionInformation的返回值
     PSCOPETABLE pScopeTable                          //搞一个局部变量来存pRegistrationFrame->scopetable
 
     CLD     // Clear the direction flag (make no assumptions!)
 
      // if neither the EXCEPTION_UNWINDING nor EXCEPTION_EXIT_UNWIND bit
     // is set...  This is true the first time through the handler (the
     // non-unwinding case)

     if ( ! (pExceptionRecord->ExceptionFlags
             & (EXCEPTION_UNWINDING | EXCEPTION_EXIT_UNWIND)) )
     {
         // Build the EXCEPTION_POINTERS structure on the stack
         exceptPtrs.ExceptionRecord = pExceptionRecord;
         exceptPtrs.ContextRecord = pContextRecord;

         // Put the pointer to the EXCEPTION_POINTERS 4 bytes below the
         // establisher frame.  See ASM code for GetExceptionInformation
         *(PDWORD)((PBYTE)pRegistrationFrame - 4) = &exceptPtrs;    //看到了吧，这三句就是设定pRegistration->xpointers，现在明白为什么只能在except的小括号里调用GetExceptionInformation了吧
 
         // Get initial "trylevel" value
         trylevel = pRegistrationFrame->trylevel

         // Get a pointer to the scopetable array
         scopeTable = pRegistrationFrame->scopetable;

search_for_handler:

         if ( pRegistrationFrame->trylevel != TRYLEVEL_NONE )
         {
             if ( pRegistrationFrame->scopetable[trylevel].lpfnFilter )
             {
                 PUSH EBP                        // Save this frame EBP

                 // !!!Very Important!!!  Switch to original EBP.  This is
                 // what allows all locals in the frame to have the same
                 // value as before the exception occurred.
                 EBP = &pRegistrationFrame->_ebp

                 // Call the filter function
                 filterFuncRet = scopetable[trylevel].lpfnFilter();     //原来我们自己写的过滤函数是在这儿被调用的啊
 
                 POP EBP                          // Restore handler frame EBP

                 if ( filterFuncRet != EXCEPTION_CONTINUE_SEARCH )
                 {
                     if ( filterFuncRet < 0 ) // EXCEPTION_CONTINUE_EXECUTION
                         return ExceptionContinueExecution;

                     // If we get here, EXCEPTION_EXECUTE_HANDLER was specified
                     scopetable == pRegistrationFrame->scopetable

                     // Does the actual OS cleanup of registration frames
                     // Causes this function to recurse
                     __global_unwind2( pRegistrationFrame );

                     // Once we get here, everything is all cleaned up, except
                     // for the last frame, where we'll continue execution
                     EBP = &pRegistrationFrame->_ebp
                    
                     __local_unwind2( pRegistrationFrame, trylevel );

                     // NLG == "non-local-goto" (setjmp/longjmp stuff)
                     __NLG_Notify( 1 );  // EAX == scopetable->lpfnHandler

                     // Set the current trylevel to whatever SCOPETABLE entry
                     // was being used when a handler was found
                     pRegistrationFrame->trylevel = scopetable->previousTryLevel;

                     // Call the _except {} block.  Never returns.
                     pRegistrationFrame->scopetable[trylevel].lpfnHandler();
                 }
             }

             scopeTable = pRegistrationFrame->scopetable;
             trylevel = scopeTable->previousTryLevel

             goto search_for_handler;
         }
         else    // trylevel == TRYLEVEL_NONE
         {
             retvalue == DISPOSITION_CONTINUE_SEARCH;
         }
     }
     else     // EXCEPTION_UNWINDING or EXCEPTION_EXIT_UNWIND flags are set
     {
         PUSH EBP    // Save EBP
         EBP = pRegistrationFrame->_ebp  // Set EBP for __local_unwind2

         __local_unwind2( pRegistrationFrame, TRYLEVEL_NONE )

         POP EBP     // Restore EBP

         retvalue == DISPOSITION_CONTINUE_SEARCH;
     }
}

注： 这个函数的伪代码来自于Matt Pietrek 1997年的论文"A Crash Course on the Depths of Win32 Structured Exception Handling"，英语的注释就是作者自己写的，如果大家觉得我说得不清楚的话，建议看下这篇文章。

 

看到了吧， 如果我们的过滤函数返回的是EXCEPTION_CONTINUE_SEARCH，__except_handler3会看这个frame中的下一个过滤 函数，依次类推。还有一点要注意的是，如果我们的过滤函数返回值为EXCEPTION_EXECUTE_HANDLER的话，我们的异常处理会被 __except_handler3调用，但是， __except_handler3把控制权交给我们的程序后，我们的程序不会再返回到__except_handler3，而是顺序执行下去 ，这时也许你会想，就这样执行下去，栈的结构不是被破坏了吗，其实是破坏了，但是，破坏了我们还可以修复嘛，我们来看一段代码：

int main()
{
　　int a = 0;
　　__try
　　{
　　　　a = 1;
　　}
　　__except(filter(GetExceptionInformation()))  //看到了吧，GetExceptionInformation只能在这儿调用
　　{
　　　　a = 2;
　　}
　　a = 3;
　　return 0;
}

变成汇编我们再看看：

12:   int main()
13:   {
0040D860   push        ebp
0040D861   mov         ebp,esp
0040D863   push        0FFh
0040D865   push        offset string "stream != NULL"+14h (00422f80)
0040D86A   push        offset __except_handler3 (004011f0)
0040D86F   mov         eax,fs:[00000000]
0040D875   push        eax
0040D876   mov         dword ptr fs:[0],esp
0040D87D   add         esp,0B4h
0040D880   push        ebx
0040D881   push        esi
0040D882   push        edi
0040D883   mov         dword ptr [ebp-18h],esp    ;保存当前的ESP，待会儿用于恢复栈
0040D886   lea         edi,[ebp-5Ch]
0040D889   mov         ecx,11h
0040D88E   mov         eax,0CCCCCCCCh
0040D893   rep stos    dword ptr [edi]
14:       int a = 0;
0040D895   mov         dword ptr [ebp-1Ch],0
15:       __try
0040D89C   mov         dword ptr [ebp-4],0
16:       {
17:           a = 1;
0040D8A3   mov         dword ptr [ebp-1Ch],1
18:       }
0040D8AA   mov         dword ptr [ebp-4],0FFFFFFFFh
0040D8B1   jmp         $L564+11h (0040d8d1)
19:       __except(filter(GetExceptionInformation()))
0040D8B3   mov         eax,dword ptr [ebp-14h]    ;看到了吧，GetExceptionInformation就这么一句
0040D8B6   push        eax
0040D8B7   call        @ILT+10(filter) (0040100f)
0040D8BC   add         esp,4
$L565:
0040D8BF   ret
$L564:
0040D8C0   mov         esp,dword ptr [ebp-18h]      ;当我们的filter返回EXCEPTION_EXECUTE_HANDLER时，__except_handler3会把控制权交到这一句上，这句就是恢复栈的，所以，即使不用回到__except_handler3，程序也可以正常运行
20:       {
21:           a = 2;
0040D8C3   mov         dword ptr [ebp-1Ch],2
22:       }
0040D8CA   mov         dword ptr [ebp-4],0FFFFFFFFh
23:       a = 3;
0040D8D1   mov         dword ptr [ebp-1Ch],3
24:       return 0;
0040D8D8   xor         eax,eax
25:   }
0040D8DA   mov         ecx,dword ptr [ebp-10h]
0040D8DD   mov         dword ptr fs:[0],ecx
0040D8E4   pop         edi
0040D8E5   pop         esi
0040D8E6   pop         ebx
0040D8E7   add         esp,5Ch
0040D8EA   cmp         ebp,esp
0040D8EC   call        __chkesp (004010c0)
0040D8F1   mov         esp,ebp
0040D8F3   pop         ebp
0040D8F4   ret
        现在，我们来总结一下，在VC++6.0中，如果我们在一个函数中使用了SEH，编译器会为我们产生一个EXCEPTION_REGISTRATION结 构，设置相应的值，并把这个结构串在fs:[0]指向的SEH链上，如果这个函数中有多个try块，不管是嵌套的还是平行的，编译器都会分别把这些块的信 息放在一个叫SCOPETABLE的结构中，并形成一个数组，并把这个数组的首地址赋给EXCEPTION_REGISTRATION结构的成员 scopetable，如果有多个函数，那么编译器会为我们产生多个EXCEPTION_REGISTRATION结构，并且都串在SEH链上。当一个用 到SEH链的函数产生异常时，系统会调用编译器设定在EXCEPTION_REGISTRATION里的异常处理函数 __except_handler3，再由这个函数在产生异常的那个函数对应的EXCEPTION_REGISTRATION结构中搜索，看哪个 except块可以解决这个异常(如果过滤函数返回不是EXCEPTION_CONTINUE_SEARCH，就表示可以解决)，如果没有可以解决的，则 会转到一个叫UnhandledExceptionFilter函数那里，在这里，一般会结束掉产生异常的线程或进程，如果可以解决的话，而且过滤函数的 返回值又是EXCEPTION_EXECUTE_HANDLERR的话，__except_handler3会把控制权交给我们的except块的代码并 恢复栈指针ESP，程序继续向下执行。