深入研究win32结构化异常处理(SEH总结篇)

最新推荐文章于 2021-02-18 00:01:06 发布
最新推荐文章于 2021-02-18 00:01:06 发布
阅读量1k 收藏 3
点赞数 1
分类专栏： windows编程

深入研究Win32结构化异常处理(SEH总结篇)

 

本文假设你熟悉WIN32，C/C++。

引言：

 

本文是在《Win32 结构化异常处理（SEH）探秘》基础上做的更新总结。探索MS C/C++编译器和MS核心DLL在操作系统SEH上的不同扩展，逐个分析其内部采用的数据结构及处理流程。

 

摘要：

 

    Win32 结构化异常处理其核心是操作系统提供的服务，特定的编译器运行库包装操作系统SEH的实现，这其中就包括MS C/C++编译器定义的__try，__finally，__except关键字，这些关键字包装操作系统SEH的实现，方便我们编写异常处理语句。在本文中，我将一层层对SEH进行解剖，以便展示其最基本的概念。

 

SEH 浅析

 

    当某个线程出错了，操作系统会给我们一个机会通知这个情况。具体点说，操作系统会调用某个用户定义的回调函数，这个回调函数可以做任何它想做的事情，不管回调函数做什么，其最后总是返回一个值，这个值告诉系统下一步做什么。我们来看看这个异常回调函数的原型（该原型在VC/include/excpt.h中有声明）：

[cpp]  view plain copy
  1. EXCEPTION_DISPOSITION __cdecl _except_handler (  
  2.     _In_ struct _EXCEPTION_RECORD *_ExceptionRecord,  
  3.     _In_ void * _EstablisherFrame,  
  4.     _Inout_ struct _CONTEXT *_ContextRecord,  
  5.     _Inout_ void * _DispatcherContext  
  6. );  

 

第一个参数是指向EXCEPTION_RECORD结构指针，该结构在WINNT.H中定义(成员含义查阅MSDN)：

[cpp]  view plain copy
  1. typedef struct _EXCEPTION_RECORD {  
  2.     DWORD ExceptionCode;  
  3.     DWORD ExceptionFlags;  
  4.     struct _EXCEPTION_RECORD *ExceptionRecord;  
  5.     PVOID ExceptionAddress;  
  6.     DWORD NumberParameters;  
  7.     ULONG_PTR ExceptionInformation[EXCEPTION_MAXIMUM_PARAMETERS];  
  8. } EXCEPTION_RECORD;  

ExceptionCode是有操作系统提供给异常的一个数，代表异常发生的原因。ExceptionAddress表示异常发生的地址。

 

第二个参数是指向异常帧结构的指针，是一个很重要的参数。操作系统的异常帧结构类型如下：

[cpp]  view plain copy
  1. 0:000> dt _EXCEPTION_REGISTRATION_RECORD  
  2. ntdll!_EXCEPTION_REGISTRATION_RECORD  
  3.    +0x000 Next             : Ptr32 _EXCEPTION_REGISTRATION_RECORD  
  4.    +0x004 Handler          : Ptr32 _EXCEPTION_DISPOSITION   

 

第三个参数是CONTEXT结构的指针，CONTEXT结构在WINNT.H中定义，它表示特定线程异常发生时寄存器的值：

[cpp]  view plain copy
  1. typedef struct _CONTEXT {  
  2.   
  3.     //  
  4.     // The flags values within this flag control the contents of  
  5.     // a CONTEXT record.  
  6.     //  
  7.     // If the context record is used as an input parameter, then  
  8.     // for each portion of the context record controlled by a flag  
  9.     // whose value is set, it is assumed that that portion of the  
  10.     // context record contains valid context. If the context record  
  11.     // is being used to modify a threads context, then only that  
  12.     // portion of the threads context will be modified.  
  13.     //  
  14.     // If the context record is used as an IN OUT parameter to capture  
  15.     // the context of a thread, then only those portions of the thread's  
  16.     // context corresponding to set flags will be returned.  
  17.     //  
  18.     // The context record is never used as an OUT only parameter.  
  19.     //  
  20.   
  21.     DWORD ContextFlags;  
  22.   
  23.     //  
  24.     // This section is specified/returned if CONTEXT_DEBUG_REGISTERS is  
  25.     // set in ContextFlags.  Note that CONTEXT_DEBUG_REGISTERS is NOT  
  26.     // included in CONTEXT_FULL.  
  27.     //  
  28.   
  29.     DWORD   Dr0;  
  30.     DWORD   Dr1;  
  31.     DWORD   Dr2;  
  32.     DWORD   Dr3;  
  33.     DWORD   Dr6;  
  34.     DWORD   Dr7;  
  35.   
  36.     //  
  37.     // This section is specified/returned if the  
  38.     // ContextFlags word contians the flag CONTEXT_FLOATING_POINT.  
  39.     //  
  40.   
  41.     FLOATING_SAVE_AREA FloatSave;  
  42.   
  43.     //  
  44.     // This section is specified/returned if the  
  45.     // ContextFlags word contians the flag CONTEXT_SEGMENTS.  
  46.     //  
  47.   
  48.     DWORD   SegGs;  
  49.     DWORD   SegFs;  
  50.     DWORD   SegEs;  
  51.     DWORD   SegDs;  
  52.   
  53.     //  
  54.     // This section is specified/returned if the  
  55.     // ContextFlags word contians the flag CONTEXT_INTEGER.  
  56.     //  
  57.   
  58.     DWORD   Edi;  
  59.     DWORD   Esi;  
  60.     DWORD   Ebx;  
  61.     DWORD   Edx;  
  62.     DWORD   Ecx;  
  63.     DWORD   Eax;  
  64.   
  65.     //  
  66.     // This section is specified/returned if the  
  67.     // ContextFlags word contians the flag CONTEXT_CONTROL.  
  68.     //  
  69.   
  70.     DWORD   Ebp;  
  71.     DWORD   Eip;  
  72.     DWORD   SegCs;              // MUST BE SANITIZED  
  73.     DWORD   EFlags;             // MUST BE SANITIZED  
  74.     DWORD   Esp;  
  75.     DWORD   SegSs;  
  76.   
  77.     //  
  78.     // This section is specified/returned if the ContextFlags word  
  79.     // contains the flag CONTEXT_EXTENDED_REGISTERS.  
  80.     // The format and contexts are processor specific  
  81.     //  
  82.   
  83.     BYTE    ExtendedRegisters[MAXIMUM_SUPPORTED_EXTENSION];  
  84.   
  85. } CONTEXT;  
  86.   
  87.   
  88.   
  89. typedef CONTEXT *PCONTEXT;  

 

第四个参数是_DispatcherContext，用于存放下一个异常帧，全局展开在执行当前异常帧局部展开中发生嵌套展开时使用。

 

    为了简化起见，我们可以这样理解：当异常发生时，有一个回调函数被调用，此回调函数带有四个参数。那么，当错误发生时候，操作系统如何知道去哪里调用这个回调函数呢？答案涉及另一个结构_EXCEPTION_REGISTRATION，它在vc/crt/src/exsup.inc中定义：

[cpp]  view plain copy
  1. _EXCEPTION_REGISTRATION struc  
  2.     prev                dd      ?  
  3.     handler             dd      ?  
  4. _EXCEPTION_REGISTRATION ends  

大家会发现这个结构和回调函数第二个参数的类型很相似，是的，它其实就是操作系统的异常帧结构类型！当错误发生时，操作系统将调用这个结构中的hanlder所指向的回调函数。好了，新的问题又来了，OS在哪里查找并发现_EXCEPTION_REGISTRATION结构？

    为了回答这个问题，回想一下结构化异常处理是以线程为基础的、并作用在每个线程上，明白这一点是有助于理解的。也就是说，每个线程具备其自己的异常处理回调函数。在Intel Win32 平台上，FS寄存器总是指向当前的_TEB（线程环境块），而_TEB的第一项又指向_NT_TIB，接着_NT_TIB的第一项又指向_EXCEPTION_REGISTRATION_RECORD。因此，我们可以通过FS:[0]获取_EXCEPTION_REGISTRATION_RECORD结构的信息。使用WinDbg我们可以很好地理解以上之间的关系：

[cpp]  view plain copy
  1. 0:000> dt _TEB  
  2. ntdll!_TEB  
  3.    +0x000 NtTib            : _NT_TIB  
  4.    +0x01c EnvironmentPointer : Ptr32 Void  
  5.    +0x020 ClientId         : _CLIENT_ID  
  6.    +0x028 ActiveRpcHandle  : Ptr32 Void  
  7.    +0x02c ThreadLocalStoragePointer : Ptr32 Void  
  8.    +0x030 ProcessEnvironmentBlock : Ptr32 _PEB  
  9.    ... ...  
  10.    ... ...  
  11. 0:000> dt _NT_TIB  
  12. ntdll!_NT_TIB  
  13.    +0x000 ExceptionList    : Ptr32 _EXCEPTION_REGISTRATION_RECORD  
  14.    +0x004 StackBase        : Ptr32 Void  
  15.    +0x008 StackLimit       : Ptr32 Void  
  16.    +0x00c SubSystemTib     : Ptr32 Void  
  17.    ... ...  
  18.    ... ...  
  19. 0:000> dt _EXCEPTION_REGISTRATION_RECORD  
  20. ntdll!_EXCEPTION_REGISTRATION_RECORD  
  21.    +0x000 Next             : Ptr32 _EXCEPTION_REGISTRATION_RECORD  
  22.    +0x004 Handler          : Ptr32 _EXCEPTION_DISPOSITION   

 

    现在我们知道了，当异常发生时，系统检查出错线程的_TEB并获取_EXCEPTION_REGISTRATION_RECORD结构指针。这个结构中就有一个类型为_except_handler的异常回调函数指针Handler。这些信息足以让操作系统知道在哪里以及如何调用_except_handler异常回调函数。

    通过前面的描述，下面编写一个小程序来对操作系统层的结构化异常进行示范。代码如下：

[cpp]  view plain copy
  1. /** 
  2.  * 文件:MySeh.cpp 
  3.  * 编译:cl.exe myseh.cpp /link -SAFESEH:NO 
  4.  * 
  5. **/  
  6. #include <windows.h>  
  7. #include <stdio.h>  
  8.   
  9. DWORD scratch;  
  10.   
  11. //自定义异常回调函数  
  12. EXCEPTION_DISPOSITION __cdecl my_except_handler (  
  13.      struct _EXCEPTION_RECORD *_ExceptionRecord,  
  14.      void * _EstablisherFrame,  
  15.      struct _CONTEXT *_ContextRecord,  
  16.      void * _DispatcherContext  
  17.     )  
  18. {  
  19.     printf( "Hello from my exception handler/n" );   
  20.       
  21.     //修复异常,使EAX寄存器指向一个有效的地址  
  22.     _ContextRecord->Eax = (DWORD)&scratch;  
  23.       
  24.     //异常已修复,重新执行引发异常的指令  
  25.     return ExceptionContinueExecution;  
  26. }  
  27.   
  28. int main()  
  29. {  
  30.     DWORD handler = (DWORD)my_except_handler;  
  31.     __asm  
  32.     {  
  33.         //创建_EXCEPTION_REGISTRATION_RECORD结构  
  34.         push handler            //Handler成员  
  35.         push fs:[0]             //Next成员,指向下一个异常帧  
  36.         mov fs:[0],esp          //安装SEH  
  37.     }  
  38.       
  39.     __asm  
  40.     {  
  41.         xor eax,eax                 //EAX = 0  
  42.         mov dword ptr [eax],1234h   //写EAX指向的内存从而故意引发一个异常!  
  43.     }  
  44.       
  45.     //异常已修复,此时scratch的值为0x1234  
  46.     printf( "After writing! scratch=0x%08x/n",scratch);  
  47.       
  48.     __asm  
  49.     {  
  50.         //移除_EXCEPTION_REGISTRATION_RECORD结构  
  51.         pop dword ptr fs:[0]  
  52.         add esp,4  
  53.     }  
  54.       
  55.     return 0;  
  56. }  

 

    代码只有两个函数，main函数使用了三部分内联汇编块__asm。第一个__asm块通过两个PUSH指令在堆栈上建立一个_EXCEPTION_REGISTRATION_RECORD结构，紧接着的指令（mov fs:[0],esp）将FS:[0]指向这个新的_EXCEPTION_REGISTRATION_RECORD结构。值得注意的是，当我们使用MS C/C++编译器的__try/__except时，MS C/C++编译器也是这么在堆栈上建立起_EXCEPTION_REGISTRATION_RECORD结构的。第二个__asm块先把EAX寄存器清零（mov eax,0），然后把此寄存器的值作为内存地址向其写入数据，从而故意引发一个错误。最后一个__asm块清除我们安装的异常处理例程：首先它恢复以前的FS:[0]内容，然后再恢复栈指针到安装前的值。

    现在，我们运行MySeh.exe并观察所发生的事情：当mov dowrd ptr [eax],1234h指令执行时，它导致一个数据访问违例。系统查看FS:[0]并找到线程环境块（_TEB）中的_EXCEPTION_REGISTRATION_RECORD结构指针。此结构中则有一个指向MySeh.cpp中定义的my_except_handler函数指针。系统将四个必要的参数压入堆栈并调用my_except_handler函数。

    一旦进入my_except_handler函数，代码首先打印"Hello from my exception handler"，接着，通过改变CONTEXT结构中的Eax成员，让EAX寄存器指向某个允许进行写入操作的位置，修复此前导致出错的问题。最后，my_except_handler函数返回ExceptionContinueExecution值（ExceptionContinueExecution在EXCPT.H文件中定义）。

    当操作系统看到返回值为ExceptionContinueExecution，就会认为我们已经修复了问题并让引起错误的指令重新执行。因此main中的mov dword ptr [eax],1234h指令被再次执行，函数main一切正常!

 

进一步深入

 

    有了前面的最简单的例子，让我们再回过头去填补一些空白。前面讲过_EXCEPTION_REGISTRATION_RECORD结构，它的第一个成员Next实际上是一个指向另一个_EXCEPTION_REGISTRATION_RECORD结构的指针，第二个_EXCEPTION_REGISTRATION_RECORD结构的Next又可以指向下一个_EXCEPTION_REGISTRATION_RECORD结构，以此类推（其中每一个_EXCEPTION_REGISTRATION_RECORD结构都可以拥有完全不同的异常处理函数）。而线程环境块（_TEB）的第一个成员(在基于Intel CPU 的机器上是 FS:[0])总是指向这个链表的头部。

    操作系统要这个_EXCEPTION_REGISTRATION_RECORD结构链表做什么呢？原来，当异常发生时，系统遍历这个链表以便查找一个其异常处理函数Handler同意处理该异常的_EXCEPTION_REGISTRATION_RECORD结构。当然，异常处理函数也可以拒绝处理这个异常。在这种情况下，系统移向链表的下一个_EXCEPTION_REGISTRATION_RECORD结构并询问它的异常处理函数，看它是否愿意处理这个异常。一旦系统找到一个同意处理该异常的某个异常处理函数，它就停止遍历结构链表。在MySeh.cpp的例子中，异常处理程序my_except_handler通过返回ExceptionContinueExecution表示它同意处理这个异常。

    下面的代码MySeh2.cpp就是一个异常处理函数不处理某个异常的例子。为了使代码尽量简单，这里使用了编译器层面的异常处理。main函数只设置了一个__try/__except块。在__try块内部调用了HomeGrownFrame函数。

[cpp]  view plain copy
  1. /**    
  2.  * 文件: MySeh2.cpp    
  3.  * 编译: CL MYSEH2.CPP /link -SAFESEH:NO    
  4. **/         
  5. #include <windows.h>     
  6. #include <stdio.h>    
  7.    
  8. EXCEPTION_DISPOSITION  __cdecl _except_handler (     
  9.             struct _EXCEPTION_RECORD *ExceptionRecord,     
  10.             void * EstablisherFrame,     
  11.             struct _CONTEXT *ContextRecord,     
  12.             void * DispatcherContext   
  13.         )     
  14. {      
  15.     printf( "Home Grown handler: Exception Code: %08X Exception Flags %X",     
  16.         ExceptionRecord->ExceptionCode, ExceptionRecord->ExceptionFlags );      
  17.     if ( ExceptionRecord->ExceptionFlags & 1 )     
  18.         printf( " EH_NONCONTINUABLE" );      
  19.     if ( ExceptionRecord->ExceptionFlags & 2 )  //注意这里的标识  
  20.         printf( " EH_UNWINDING" );      
  21.     if ( ExceptionRecord->ExceptionFlags & 4 )     
  22.         printf( " EH_EXIT_UNWIND" );      
  23.     if ( ExceptionRecord->ExceptionFlags & 8 )        
  24.         printf( " EH_STACK_INVALID" );      
  25.     if ( ExceptionRecord->ExceptionFlags & 0x10 )      
  26.         printf( " EH_NESTED_CALL" );      
  27.     printf( "/n" );      
  28.       
  29.     // 我们不想处理这个异常，让其它函数处理吧     
  30.     return ExceptionContinueSearch;      
  31. }  
  32. void HomeGrownFrame( void )     
  33. {      
  34.     DWORD handler = (DWORD)_except_handler;      
  35.       
  36.     __asm     
  37.     {     
  38.         // 创建EXCEPTION_REGISTRATION结构  
  39.         push handler        // Handler成员     
  40.         push FS:[0]         // Next成员,指向下一个异常帧     
  41.         mov  FS:[0],ESP     // 安装新的EXECEPTION_REGISTRATION结构     
  42.     }      
  43.       
  44.     // 写入地址0，从而引发一个错误  
  45.     *(PDWORD)0 = 0;                   
  46.       
  47.     printf( "I should never get here!/n" );      
  48.      
  49.     __asm     
  50.     {     
  51.         // 移去EXECEPTION_REGISTRATION结构     
  52.         pop dword ptr fs:[0]    
  53.         add esp, 4     
  54.     }  
  55. }      
  56.   
  57. int main()     
  58. {  
  59.     __try    
  60.     {     
  61.         HomeGrownFrame();     
  62.     }      
  63.     __except( EXCEPTION_EXECUTE_HANDLER )     
  64.     {     
  65.         printf( "Caught the exception in main()/n" );     
  66.     }      
  67.     return 0;  
  68. }  

 

MySeh2.cpp中，函数通过向一个 NULL 指针所指向的内存处写入数据而故意引发一个异常：

[cpp]  view plain copy
  1. *(PDWORD)0 = 0;  

异常处理函数_except_handler捕获该异常，简单的输出异常标识并返回ExceptionContinueSearch来表明自己不适合处理这个异常，让系统继续在_EXCEPTION_REGISTRATION_RECORD结构链表中寻找下一个异常帧结构(_EXCEPTION_REGISTRATION_RECORD)。下一个异常帧结构安装的异常回调函数是针对 main 函数中的__try/__except块的。__except 块简单地打印出“Caught the exception in main()”。

 

我们运行MySeh2.exe，观察输出结果：

第一行输出结果大家都可以理解，那么第二行的输出是怎么回事呢？异常处理函数_except_handler为什么被调用了两次？通过仔细观察我们很容易看出这两行的区别，第一行的异常码是0xC0000005（EXCEPTION_ACCESS_VIOLATION，WinNT.h中定义），异常标识是0；而第二行的异常码是0xC0000027（STATUS_UNWIND，ntstatus.h中定义），异常标识是2（EXCEPTION_UNWINDING，exsup.inc中定义）。原来，当异常发生时，操作系统遍历EXCEPTION_REGISTRATION 结构链表，直到找到一个同意处理该异常的_EXCEPTION_REGISTRATION_RECORD结构节点。一旦操作系统找到该结节点，它就再次遍历这个结构链表，重新调用之前遍历过的、未处理该异常的_EXCEPTION_REGISTRATION_RECORD结构节点的异常处理函数，并传入异常标识为2（EXCEPTION_UNWINDING）的异常记录作为其第一个参数。

    当一个异常处理函数被第二次调用时（带 EXCEPTION_UNWINDING 标志），操作系统给这个函数一个最后清理的机会，它会调用诸如局部对象的析构函数以及__finally块代码对发生异常的代码及其上下文执行最后的清理工作。（若要深入理解这句话，请参考《逆向分析kernel32.dll!_except_handler3函数》、全局展开函数《逆向分析NtDLL.dll!RtlUnwind函数》、局部展开函数《逆向分析kernel32.dll!__local_unwind2函数》）。

    在异常已经被处理完毕，并且所有前面的异常帧都已经被展开之后，流程由处理异常的那个回调函数来决定从什么地方开始继续执行。一定要记住，仅仅把指令指针设置到所需的代码处就开始执行是不行的。流程恢复执行处的代码的堆栈指针和栈帧指针（在Intel CPU上是 ESP 和EBP）也必须被恢复成它们在处理这个异常的函数的栈帧上的值。因此，这个处理异常的回调函数必须负责把堆栈指针和栈帧指针恢复成它们在包含处理这个异常的 SEH 代码的函数的堆栈上的值。

    通常，展开操作导致堆栈上处理异常的帧以下的堆栈区域上的所有内容都被移除了，就好像我们从来没有调用过这些函数一样。展开的另外一个效果就是_EXCEPTION_REGISTRATION_RECORD结构链表上处理异常的那个结构之前的所有_EXCEPTION_REGISTRATION_RECORD 结构都被移除了。也就是说，FS:[0]被指向这个能够处理当前异常的_EXCEPTION_REGISTRATION_RECORD结构节点。

 

顶级异常处理函数

 

    为了避免引发的异常影响到操作系统，操作系统在任何用户代码开始之前、线程执行的早期，就暗中为每个线程都提供了一个默认的异常处理程序。这个默认的异常处理程序总是链表的最后一个节点，并且它总是选择处理异常。

    下面我们随意编写一个程序，准备找出这个默认的异常处理程序。

1、打开Visual Studio 2005/2008，新建[Visual C++] -> [Win32] -> [Win32 控制台应用程序]，在应用程序设置的附加选项中勾上[空项目]，点击[完成]按钮。

2、右击解决方案下的[源文件]->[添加]->[新建项]，添加一个名为DefaultExHandler.cpp的文件

3、编写一个简单的控制台代码，并设断点，如下图所示：

4、调试运行，观察调用堆栈，如下图：

5、由于调试符号未加载，我们程序的第一个执行函数并没有显示出它的名字来，只是用kernel32.dll!7c816fe7表示。右击调用堆栈中的[kernel32.dll!7c816fe7]，选择[符号设置]，弹跳出下面的对话框，按图设置：

6、点击[确定]后，我们回到调用堆栈，这时就可以看到我们运行的应用程序其最先调用的函数。

7、右击Kerne32.dll!_BaseProcessStart@4()，选择[转到反汇编]，来到这里：

8、通过对7C816FCB  call   __SEH_prolog (7C8024C6h)处的分析，我们得知_BaseProcessStart的异常处理函数是__except_handler3。也就是说，操作系统会为任何应用程序暗中安装一个名为__except_handler3的顶级异常处理函数，当一个进程引发了一个错误而没有异常处理程序去处理它，这个进程就会被系统终止。

下面是_BaseProcessStart的伪代码，具体分析过程请参考《逆向分析Kernel32.dll!BaseProcessStart函数》。

[cpp]  view plain copy
  1. #define SET_THREAD_ENTRY_ROUTINE    9        
  2.     
  3. typedef struct CPPEH_RECORD      
  4. {      
  5.     DWORD old_esp;  //ESP     
  6.     DWORD exc_ptr;  //GetExceptionInformation返回值     
  7.     DWORD prev_er;  //prev _EXCEPTION_REGISTRATION_RECORD     
  8.     DWORD handler;  //handler     
  9.     DWORD msEH_ptr; //scopetable     
  10.     DWORD disabled; //trylevel     
  11. }CPPEH_RECORD,*PCPPEH_RECORD;     
  12.     
  13. __stdcall BaseProcessStart(LPVOID lpfnStartRoutine)        
  14. {        
  15.     DWORD retValue = 0;        
  16.     __try       
  17.     {        
  18.         //将主线程的入口函数设置为mainCRTStartup        
  19.         NtSetInformationThread(GetCurrentThread(),SET_THREAD_ENTRY_ROUTINE,        
  20.             &lpfnStartRoutine,sizeof(lpfnStartRoutine));        
  21.                 
  22.         retValue = lpfnStartRoutine();        
  23.     }        
  24.     __except(retValue=GetExceptionCode(),     
  25.         UnhandledExceptionFilter(GetExceptionInformation()))        
  26.     {        
  27.         if(BaseRunningInServerProcess)     
  28.             ExitThread(retValue);     
  29.         else    
  30.             ExitProcess(retValue);     
  31.     }     
  32. }  

    在这段伪码中，注意对lpfnStartRoutine的调用被封装在一个__try 和 __except 块中。正是此__try 块安装了默认的、异常处理程序链表上的最后一个异常处理程序。所有后来注册的异常处理程序都被安装在此链表中这个结点的前面。如果lpfnStartRoutine函数返回，那么表明线程一直运行到完成并且没有引发异常。这时 BaseProcessStart 调用 ExitThread 使线程退出。 
    另一方面，如果线程引发了一个异常但是没有异常处理程序来处理它时，该怎么办呢？这时，执行流程转到 __except 关键字后面的括号中。在 BaseProcessStart 中，这段代码调用UnhandledExceptionFilter，显示了一个对话框告诉我们发生了一个错误，要么终止出错进程，要么调试它（详细情况可以反汇编Kernel32.dll!UnhandledExceptionFilter函数进行分析）。

 

编译器级的SEH

 

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

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

[cpp]  view plain copy
  1. __try       
  2. {        
  3.     // 受保护的代码  
  4. }        
  5. __except(/*过滤表达式*/)        
  6. {        
  7.     // 异常处理代码  
  8. }  

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

[cpp]  view plain copy
  1. MOV DWORD PTR FS:[00000000],ESP     
  2. 或者     
  3. MOV DWORD PTR FS:[00000000],ECX   

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

    事实上，上面讲述的并不完全正确。首先，使用SEH的函数无论拥有多少个__try/__except结构，它只创建一个_EXCEPTION_REGISTRATION_RECORD结构来保护。其次，并非在__try块结束后，相应的_EXCEPTION_REGISTRATION_RECORD结构从这个链表的头部被移除，而是当函数退出前的那一刻_EXCEPTION_REGISTRATION_RECORD结构从这个链表的头部被移除。最后，所有使用SEH的函数，经MS C/C++编译器(Visual Studio 2005/2008版本)编译后、它们的_EXCEPTION_REGISTRATION_RECORD结构所指向的异常处理程序Handler均是_except_handler4！_except_handler4在MS C/C++编译器的运行时库（msvcr80.dll或msvcr90.dll）中。正是这个函数调用过滤表达式来决定后面的大括号中的代码是否执行。 

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

 

MS C/C++编译器扩展的异常帧

 

    MS C/C++编译器的 SEH 实现并没有使用原始的_EXCEPTION_REGISTRATION_RECORD结构。它在这个结构的前后添加了一些附加数据。这些附加数据正是允许单个函数（__except_handler4）处理所有异常并将执行流程传递到相应的过滤器表达式和__except 块的关键。我们来看一下这个结构的定义(修正vc/crt/src/exsup.inc中的定义)：

[cpp]  view plain copy
  1. //C/C++扩展SEH的异常帧结构:        
  2. [ebp-18] _Esp        
  3. [ebp-14] PEXCEPTION_POINTERS xpointers;           
  4.          struct _EXCEPTION_REGISTRATION{           
  5. [ebp-10]      struct _EXCEPTION_REGISTRATION *Next;           
  6. [ebp-0C]      _except_handler Handler;           
  7. [ebp-08]      struct _EH4_SCOPETABLE *ScopeTable;           
  8. [ebp-04]      int TryLevel;           
  9. [ebp-00]      int _Ebp;           
  10.          };  
  11.   
  12. //C/C++运行库使用的SCOPE TABLE结构    
  13. struct _EH4_SCOPETABLE {    
  14.      DWORD GSCookieOffset;    
  15.      DWORD GSCookieXOROffset;    
  16.      DWORD EHCookieOffset;    
  17.      DWORD EHCookieXOROffset;    
  18.      struct _EH4_SCOPETABLE_RECORD ScopeRecord;    
  19. };  
  20.   
  21. //C/C++运行库使用的SCOPE TABLE RECORD结构    
  22. struct _EH4_SCOPETABLE_RECORD {    
  23.      DWORD EnclosingLevel;       //上一层__try块    
  24.      PVOID FilterFunc;           //过滤表达式    
  25.      union    
  26.      {    
  27.          PVOID HandlerAddress;   //__except块代码    
  28.          PVOID FinallyFunc;      //__finally块代码    
  29.      };    
  30. };  

    前面两个成员Next和Handler我们都很熟悉，它们组成基本的_EXCEPTION_REGISTRATION_RECORD结构。后面的三个成员ScopeTable、TryLevel和_Ebp是新增的。ScopeTable指向_EH4_SCOPETABLE结构，&ScopeTable->ScopeRecord的位置又指向一个ScopeRecord数组。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 结构下面，MS C/C++编译器压入了另外两个值。紧跟着（即[EBP-14H]处）的一个DWORD，是为一个指向 EXCEPTION_POINTERS 结构（一个标准的Win32 结构）的指针所保留的空间。这个指针就是你调用 GetExceptionInformation 这个API时返回的指针。当我们调用GetExceptionInformation时，MS C/C++编译器生成以下代码：

[cpp]  view plain copy
  1. MOV EAX,DWORD PTR [EBP-14]  

    GetExceptionInformation 是一个编译器内联函数，与它相关的 GetExceptionCode 函数也是如此。此函数实际上只是返回 GetExceptionInformation 返回的数据结构（EXCEPTION_POINTERS）中的一个结构（EXCEPTION_RECORD）中的一个域（ExceptionCode）的值。下面是MS C/C++编译器为GetExceptionCode生成的代码：

[cpp]  view plain copy
  1. MOV EAX,DWORD PTR [EBP-14]  ; 执行完毕，EAX指向EXCEPTION_POINTERS结构     
  2. MOV EAX,DWORD PTR [EAX]     ; 执行完毕，EAX指向EXCEPTION_RECORD结构     
  3. MOV EAX,DWORD PTR [EAX]     ; 执行完毕，EAX中是ExceptionCode的值  

看完GetExceptionInformation和GetExceptionCode的内部指令，现在就能理解为什么SDK文档提醒我们要注意这两个函数的使用范围了。

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

[cpp]  view plain copy
  1. EBP-00  _Ebp     
  2. EBP-04  TryLevel     
  3. EBP-08  ScopeTable数组指针     
  4. EBP-0C  Handler函数地址     
  5. EBP-10  Next,指向前一个_EXCEPTION_REGISTRATION结构     
  6. EBP-14  xpointers,即GetExceptionInformation的返回值    
  7. EBP-18  栈帧中的标准_Esp  

 

_except_handler4 和 ScopeTable

 

    前面讲过，使用SEH的函数无论拥有多少个__try/__except结构，MS C/C++ 编译器只创建一个_EXCEPTION_REGISTRATION_RECORD结构来保护。那么，编译器是如何做到的呢？这里我们要讲到扩展的 _EXCEPTION_REGISTRATION 结构中的ScopeTable指针。ScopeTable指针指向的是一个_EH4_SCOPETABLE结构，_EH4_SCOPETABLE结构中又有一个_EH4_SCOPETABLE_RECORD结构。事实上，&ScopeTable->ScopeRecord指向的是一个_EH4_SCOPETABLE_RECORD数组，这个数组的项数和使用SEH函数的__try/__except结构的个数一致。从_EH4_SCOPETABLE_RECORD结构中，我们很容易看出它是一个包含过滤表达式，__except块代码，__finally块代码的完整SEH处理结构。如果一个__try/__except(__finally)是一个完整SEH处理结构的话，那么我们怎么知道当前发生异常的是由_EH4_SCOPETABLE_RECORD数组上的哪个处理呢？这时，我们又引出了扩展的_EXCEPTION_REGISTRATION 结构中的TryLevel成员，TryLevel成员用于记载当前异常发生时_EH4_SCOPETABLE_RECORD所处的位置。当线程出现异常时，编译器会自动调用_EH4_SCOPETABLE_RECORD中的FilterFunc执行当前__try/__except的过滤表达式。下面代码演示了编译器在每次进入一个__try/__except(__finally)结构时对TryLevel所做的更新：

[cpp]  view plain copy
  1. /** 
  2.  *文件:TryLevel.cpp 
  3.  *编译:cl.exe TryLevel.cpp 
  4.  * 
  5. **/  
  6. #include <windows.h>  
  7.   
  8. int main()  
  9. {  
  10.     __try  
  11.     {  
  12.         __try  
  13.         {  
  14.             __try  
  15.             {  
  16.                 *((int *)0) = 0x1234;  
  17.             }  
  18.             __except(EXCEPTION_CONTINUE_SEARCH){}  
  19.         }  
  20.         __except(EXCEPTION_CONTINUE_SEARCH){}  
  21.     }  
  22.     __except(EXCEPTION_EXECUTE_HANDLER){}  
  23. }  

    现在我们知道了TryLevel指向的是当前运行线程所在的__try块。一旦线程发生错误，操作系统通过TryLevel找到ScopeTable中的_EH4_SCOPETABLE_RECORD结构执行异常处理。再进一步，如果当前__try块处理不了这个异常，那么操作系统如何将控制转到其上一个__try块(如果存在的话)进行处理呢？我们回顾一下_EH4_SCOPETABLE_RECORD结构，这个结构中有一个EnclosingLevel成员，EnclosingLevel成员用于指定当前__try块的上一个__try块，也就是嵌套的情况。

    前面还说过，所有使用SEH的函数，经MS C/C++编译器(Visual Studio 2005/2008版本)编译后、它们的_EXCEPTION_REGISTRATION_RECORD结构所指向的异常处理程序Handler均是_except_handler4！接下来我们来看一下_except_handler4是如何对异常进行处理的，请查阅：逆向分析MSVCR90D.dll!_except_handler4函数。

待续...

laogaoAV
关注
专栏目录
深入研究Win32结构化异常处理(SEH总结篇)
04-07 8185
深入研究Win32结构化异常处理(SEH总结篇) 本文假设你熟悉WIN32，C/C++。引言： 本文是在《Win32 结构化异常处理（SEH）探秘》基础上做的更新总结。探索MS C/C++编译器和MS核心DLL在操作系统SEH上的不同扩展，逐个分析其内部采用的数据结构及处理流程。 摘要：     Win32 结构化异常处理其核心是操作系统提供的服务，特定的编
SEH——Structured Exception Handling（结构化异常处理）
dayenglish的专栏
03-01 1716
SEH是windows操作系统处理程序错误或异常的技术。SEH是一种系统体制，与具体的程序设计语言无关，但是windows下的编译器多使用SEH实现异常处理。     系统级别的SEH比较好理解，利用fs:[0]处保存的异常处理回到函数链表对异常进行处理。从这里也可以看出异常是和线程相关的。因为fs:[0]指向的位置是TEB而TEB所包含的的TIB的第一个成员是EXCEPTION_REGISTR
(SEH)结构化异常处理ABC
anikan_yu的专栏
06-04 1257
千言万语从何说起呢?嗯,还是先说说SEH的特点吧:SEH的优点在于当你编写代码的时候,可以集中注意力完成任务,如果在运行的时候出现了问题,系统会捕获到错误并且通知你出了问题.使得SEH工作的任务主要落在编译器而不是操作系统上.当进入,退出异常块时候,你的编译器必须产生特殊的代码.编译器必须产生处理SEH的数据结构,还必须提供操作系统能调用的回调函数来使得异常块能被遍历.编译器还负责准备栈框
SEH（结构化异常处理）
寻梦&之璐
02-18 5484
内容回顾： 当用户异常产生后，内核函数KiDispatchException并不是像处理内核异常那样在0环直接处理，而是修正3环EIP为KiUSerExceptionDispatcher函数后就结束了。 这样，当线程再次回到3环时，将会从KiUserExceptionDispatcher函数开始执行。 KiUserExceptionDispatcher会调用RtlDispatchException函数来查找并调用异常处理函数，查找的顺序： 先查全局链表：VEH 再查句柄链表：SEH 它是与线程有关的，
Win32 结构化异常处理（SEH）探秘
乱码涅磐的专栏
01-26 876
Win32 结构化异常处理其核心是操作系统提供的服务，你能找到的关于 SEH 的所有文档都是描述一个特定的编译器运行时库，这个运行库包装着操作系统实现。在本文中，我将一层一层对 SEH 进行剥离，以便展现其最基本的概念。 在 Win32 操作系统提供的所有功能中，使用最广泛但最缺乏文档描述的也许就是结构化异常处理了（SEH），当你考虑 Win32 结构化异常处理时，你也许会想到诸如 _try，_
深入研究win32结构化异常处理.doc
10-17
总结一下，Win32结构化异常处理是一个强大的错误处理机制，它由操作系统提供服务，但通过编译器的扩展关键字进行封装。理解SEH的基本概念和工作原理对于编写健壮的Windows应用程序至关重要。尽管C++的异常处理和SEH...
Win32结构化异常处理(SEH)深度解析
"本文深入探讨了Win32操作系统的结构化异常处理（SEH），即Structured Exception Handling，是一种用于处理程序运行时异常的机制。尽管有针对编译器层面的SEH实现的文档，但操作系统级别的SEH实现细节却鲜有公开。...
深入解析结构化异常处理(SEH)
CherishPrecious的博客
08-16 484
尽管以前写过一篇SEH相关的文章《关于SEH的简单总结》， 但那真的只是皮毛，一直对Windows异常处理的原理似懂非懂， 看了下面的文章 ，一切都豁然开朗.  1997年文章，Windows技术的根一直没变： http://www.microsoft.com/msj/0197/exception/exception.aspx Matt Pietrek 著   董岩 译   在Win32操作系统...
SEH结构体异常处理
qq_35426012的博客
10-24 785
SEH结构化异常 1FS段存有线程信息结构体TIB 2储异常信息的链表指针为TIB结构体的第一个成员 3通过dt _EXCEPTION_REGISTRATION_RECORD发现链表指针的结构 前4个字节：指向下一个异常处理结构体指针的位置，形成链表 后4个字节：指向一个异常回调函数 4异常回调函数 //异常回调函数声明 int _except_handler3( PEXCEPTION...
Win32 结构化异常处理（SEH）探秘--网页截图
03-09
Win32 结构化异常处理（SEH）探秘的网页截图
关于C++异常处理和win32结构化异常处理
01-15
关于C++异常处理和win32结构化异常处理
[翻译]深入理解Win32结构化异常处理（三）
weixin_30737433的博客
06-20 192
__except_handler3 and the scopetable 我真的很希望让你看一看Visual C++运行时库源代码，让你自己好好研究一下__except_handler3函数，但是我办不到。因为 Microsoft并没有提供。在这里你就将就着看一下我为__except_handler3函数写的伪代码吧 View Code int __except_handler3( ...
Win32结构化异常处理
流彩飞霞的专栏
04-11 388
SEH(Structured Exception Handling)是windows系统提供的异常处理机制。这种机制独立于编程语言。通常情况下，开发人员不需要直接调用Win32中原始的与SEH相关的API函数，而是通过特定语言的类库（比如MFC）间接地使用SEH，特定语言的编译器会把他们转换为windows操作系统中相关API函数的调用。 SEH的思想：当某个线程在执行过程中出现异常时，它回调一...
Win32结构化异常处理(SEH)——异常处理程序(__try/__except)
我的编程之旅
03-07 2878
<br /><br />环境：VC++6.0, Windows XP SP3<br />        上一篇中，我们看到了如何实现一个终止处理程序，和系统级的异常处理程序，在这一篇中，我们要着重看一下VC++6.0的异常处理程序是如何实现的。<br />        这里要用的结构体有：<br /> <br /> typedef struct _SCOPETABLE<br />　　{<br />　　　　DWORD       previousTryLevel;<br />　　　　DWORD      
win32创建异常捕获处理
贺生技术专栏
05-24 975
SetUnhandledExceptionFilter(CustomFilter); LONG __stdcall CustomFilter(EXCEPTION_POINTERS* pep) {     // 生成dump文件名     CString strDumpFile;     CTime tCur = CTime::GetCurrentTime();     strDum
深入理解Win32结构化异常处理（一）
多媒体编程、网络编程、系统编程、网络安全编程、驱动编程
09-30 1371
[翻译]深入理解Win32结构化异常处理（一）      在所有的Win32操作系统提供的功能里，最常用但是描述最不全的（underdocument）恐怕就是结构化异常处理了（structured exception handling (SEH)）。当你想到Win32的结构化异常处理，你会想到 _try, _finally, 和 _except这些东西，你可以从任何一本Win32的书中找
【WIN32之旅】WINDOWS错误处理与参考(二)
Jeffrey Tse 的专栏
03-21 6916
讲述WINDOWS错误处理与参考的系列文章（二）
Windows异常世界历险记（一）——Windows系统用户级结构化异常处理机制（SEH）的基础知识和Unwind展开操作
LPWSTR的博客
12-04 1459
Windows系统的用户级结构化异常处理机制（SEH）是基于线程的，因此可为不同的线程指派不同的异常处理函数。且由于其形成了链结构，还可据此为一个线程指定多个异常处理函数，异常发生后，操作系统会沿此链表调用各异常处理函数，直到某个异常处理函数修复了该异常或已达末尾。通常处理完异常后，需要执行展开（Unwind）操作，该操作先通知目标结点前的各异常处理函数释放资源，然后将之前的SEH链全部删除。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值