32位C++异常处理机制反汇编：从SEH链表到throw/catch实现

让我从一次比较狼狈的调试说起。几年前我遇到一个上线后的崩溃 dump，调用栈看着干干净净，崩在一个析构函数里，完全找不到是谁在调它。后来一路追到汇编才明白，问题其实出在 32 位下异常处理的展开阶段：某个 handler 返回的状态值不对，导致整个 SEH 链被破坏，栈回溯直接乱了。那次之后我养成一个习惯——研究 C++ 异常处理的反汇编，永远从 32 位的异常结构开始，把 fs:[0] 那条链、函数帧里的处理记录、throw 编译出来后的形态全部搞清楚，再谈别的。

这篇文章就是那次经验汇总后的输出，也是系列的第一篇，目标是纯反汇编视角，把 32 位下 C++ 异常处理的核心结构彻底拆开。你不需要之前有太多逆向经验，但最好会读基本的 x86 汇编指令，知道 esp/ebp 是干嘛的。看完之后，你能独立在 IDA、WinDbg 或者 x64dbg 里定位一个函数的异常处理记录，看懂 throw 和 catch 在汇编层如何协作，也知道遇到异常展开崩溃时该从哪里下手。

1. 为什么要从32位切入C++异常处理机制

1.1 先说结论：C++异常在Windows上是建立在SEH之上的

很多初学者以为 C++ 的 throw 和 catch 是语言层面的东西，跟操作系统没什么关系。这在逻辑上没错，但具体到 Windows 32 位平台，编译器和系统之间必须有一个“翻译层”，把高级语言的异常语义转成操作系统能理解的事件。

这个翻译层就是 SEH（Structured Exception Handling，结构化异常处理）。Windows 内核在 32 位模式下提供了一个基于线程栈的异常分发机制：每个线程有一个异常处理链表，系统在异常发生时沿着链表逐个调用处理函数，直到有人表示“我接住了”。C++ 的 throw 最终会触发系统级异常，catch 最终也会编译成一个系统异常处理函数里的分支判断。所以反汇编 C++ 代码时，你看到的不仅是编译器生成的语言逻辑，还有它在 SEH 之上搭的整个架子。

理解这一点是入门的关键。如果你只盯着 catch 关键字对应的源码行，忽略背后那条 fs:[0] 链表，遇到复杂一点的异常路径就会彻底迷失。

1.2 32位是理解整个机制的“解剖窗口”

为什么非要强调 32 位？因为 32 位 Windows 的 SEH 是显式结构化的，它直接暴露在栈上。你随便找一个 32 位 MSVC 编译出来的函数，入口处几乎必定能看到下面这样的代码序列：

asm复制push    ebp
mov     ebp, esp
push    0FFFFFFFFh
push    offset __ehhandler$...
mov     eax, fs:[0]
push    eax
mov     dword ptr fs:[0], esp

这四五行汇编，就是函数在向系统登记自己的异常处理函数。你可以在调试器里直接看到链表节点的值，可以用 dd 命令把内存 dump 出来，可以沿着 fs:[0] 的 Next 指针一条一条走完整个链表。这种“看得见摸得着”的特性，对学习异常处理内部的帮助是巨大的。

反观 64 位，微软把原来的显式链表换成了表的方案，异常处理信息被压缩到 .pdata 和 .xdata 段里，靠 UnwindInfo + 指令偏移去驱动展开，栈上不再维护可随意遍历的链表。结构更安全了，但理解门槛也上去了。所以我强烈建议：先把 32 位这条线走通，再去啃 64 位，你会觉得很多东西其实是相通的。

1.3 这系列文章适合谁、需要什么基础

这篇文章适合三类人。第一类是在读 C++ 和逆向工程之间反复横跳、想搞懂 throw/catch 背后机关的学习者；第二类是正在排查线上崩溃 dump、发现纯源码层已经看不出问题，不得不下到汇编层找答案的开发；第三类是准备面试时被问到“C++ 异常在 Windows 下如何实现”的一线工程师。

需要的基础很简单：懂 x86 汇编的基本指令，比如 push、mov、call、lea，知道什么是栈帧、什么是函数调用约定。如果完全没有汇编基础，建议先补一下 ebp/esp 栈帧的概念再回来读。另外最好准备一个调试器，我用的是 IDA 和 WinDbg，但 x64dbg 也完全够用，跟着文章里的步骤自己拉一遍，比单纯看文字有效十倍。

2. 地基：FS:[0]指向的SEH链表究竟长什么样

2.1 _EXCEPTION_REGISTRATION_RECORD：链表的节点定义

32 位 Windows 的地基是 TEB（Thread Environment Block，线程环境块），它由 fs 段寄存器指向。TEB 的偏移 0 处存储了一个指针，这个指针指向 _NT_TIB 结构中的 ExceptionList，也就是当前线程异常处理链表的头节点。

链表节点本身是个非常简单的结构：

c复制typedef struct _EXCEPTION_REGISTRATION_RECORD {
    struct _EXCEPTION_REGISTRATION_RECORD *Next;
    PEXCEPTION_DISPOSITION Handler;
} EXCEPTION_REGISTRATION_RECORD;

就两个字段，一个指向下一个节点的指针（Next），一个处理函数指针（Handler）。没错，表面上就是这么朴素。但朴素不代表简单，每个进入异常路径的函数都会在这个链表头插入一个新节点，插入顺序是后进先出——也就是离当前执行点最近的函数，它的 handler 排在链的最前面。

用一句人话概括：fs:[0] 是链表的入口，链表的每个节点对应栈上某一个活动函数的异常处理记录，链表的顺序和函数调用的深度直接对应。

在汇编里你看到 mov eax, dword ptr fs:[0]，然后把 eax 压栈，再把新节点的地址写回 fs:[0]，本质就是在做“头插法”。这个操作在 32 位下的几乎每个带异常保护的函数入口都会重复一遍。

2.2 Handler返回给系统的状态值

系统在处理异常过程中，会调用链上每个节点的 Handler 函数，然后根据返回值决定下一步做什么。这个返回值定义在 EXCEPTION_DISPOSITION 枚举里，一共四个值：

其中前两个是最常见的。C++ 的 catch 块如果不能匹配，__CxxFrameHandler 最终就会返回 ExceptionContinueSearch，让系统继续往链表深处找。而一旦 catch 匹配成功，处理流程会先做栈展开（unwind），然后直接修改异常上下文中的 EIP，让程序跳到 catch 块的开头继续执行，并返回 ExceptionContinueExecution 之类的值告诉系统“你不用再找了”。

2.3 一个函数注册异常处理的汇编样板

一个标准 MSVC 32 位函数，开头通常这样：

asm复制push    ebp
mov     ebp, esp
push    0FFFFFFFFh              ; 初始 tryLevel = -1，表示不在任何 try 块中
push    offset __ehhandler$...   ; 编译器生成的异常处理函数
mov     eax, dword ptr fs:[0]
push    eax                      ; 保存旧链表头
mov     dword ptr fs:[0], esp   ; 将当前节点挂到链表头

C++ 异常处理和 SEH __try/__except 在 MSVC 下都经历过几个阶段：早期用 _except_handler3，后来加入安全 cookie 后用 _except_handler4，C++ 异常则通常走 __ehhandler$ 对应的包装函数，内部最终落到 __CxxFrameHandler 上。不同编译器版本，符号名会不一样，但动作是一样的：保存旧头，构造新节点，把新节点挂上去。

函数结尾会有对应的还原动作。无论函数正常返回还是异常展开，都要把 fs:[0] 恢复成保存的旧值，否则后续函数一旦出错，系统会沿着已经被破坏的链表瞎走，后果就是崩溃在奇怪的地方。

3. C++编译器如何把throw变成一个“系统级事件”

3.1 throw的完整汇编链路

现在我们把视角放到 throw 语句上。假设源码是：

cpp复制void f() {
    throw 42;
}

MSVC 编译出来的汇编形态，会让你看到两个非常明确的信息：临时对象的构造 + 对 __CxxThrowException 的调用。Release 优化后大概长这样：

asm复制mov     dword ptr [esp], 42      ; 在栈上构造临时对象
lea     eax, [esp]
push    offset _TI1?C@...        ; _ThrowInfo 描述符
push    eax                      ; 异常对象指针
call    __CxxThrowException

__CxxThrowException 是 CRT 提供的运行库函数，它对外的行为是：把两个参数（异常对象指针、ThrowInfo 指针）重新封装，然后调用操作系统的 RaiseException 接口。

这一步极其关键。RaiseException 接收一个异常代码参数，MSVC 的 C++ 异常固定使用 0xE06D7363。注意看这段十六进制，它的 ASCII 解码后是 "msc"，也就是 Microsoft C/C++ 的缩写。所以你在内存里搜这个特征码，就能定位 C++ 异常事件。我用 WinDbg 分析 dump 时经常这么干：先搜 DWORD 0xE06D7363，再顺着引用关系找异常对象和 ThrowInfo。

看到这里你应该明白了：C++ 的 throw 在 32 位 Windows 下，本质上就是一次经过包装的系统异常发送，异常参数里不是简单的一个 int，而是一个指向 _ThrowInfo 的描述符和一个指向异常对象的指针。

3.2 _ThrowInfo与RTTI类型描述符

_ThrowInfo 是理解 C++ 异常类型匹配的核心结构。它包含了当前异常的类型信息和可捕获类型列表，定义大致如下（不同版本 MSVC 略有差异，但核心思路一致）：

c复制struct _ThrowInfo {
    unsigned int attributes;
    void *pmd;                     // 指向偏移信息的指针
    void *pCatchableTypeArray;     // 可捕获类型数组
};

真正起作用的是 pCatchableTypeArray，它指向一个 _CatchableTypeArray，数组里每个 _CatchableType 描述一个“可以被这个异常捕获的类型”。每个 _CatchableType 内部又有一个成员指向 RTTI 的 type_info 描述符，以及从异常对象指针到该类型子对象的偏移等信息。

系统在匹配 catch 时，会拿到两个关键数据：一个是异常对象携带的可捕获类型列表，另一个是函数帧描述表中 catch 块的期望类型。两者做 RTTI 类型比较，匹配上了就走这个 catch，匹配不上就返回 ExceptionContinueSearch。

这也是为什么 catch(...) 能捕获一切 C++ 异常，因为它在类型比较阶段的规则是“无条件匹配”。但 catch(...) 不会捕获纯 SEH 异常（除非编译选项强制转换），因为非 C++ 异常根本不存在 _ThrowInfo，__CxxFrameHandler 看到异常代码不是 0xE06D7363 时，会直接决定不处理。

3.3 __$EHRec$与函数帧内的tryLevel

继续深入函数内部。异常处理记录在 MSVC 函数栈帧里有专门的布局，通常被称为 __$EHRec$，32 位下经常占用三个 DWORD（12 字节）：

• 偏移 0：之前的链表头（Prev）
• 偏移 4：语言相关处理函数地址（Handler）
• 偏移 8：作用域表状态（tryLevel 或 scopetable 指针）

其中的第三个字段最值得关注。早期 VC6 时代，它就是一个简单的整数，表示当前执行点处于第几层 try 块。函数刚进入时设为 -1，表示不在任何 try 块内；进入第一个 try 块后变为 0，进入嵌套的第二个 try 块变为 1，离开后相应回退。这个值在异常发生时，会被编译器生成的 handler 读取，用来定位应该匹配哪一段 catch 逻辑。

后来的版本引入了 scopetable 指针，配合 GS 安全 cookie 做校验，防止恶意代码伪造异常记录。但从反汇编角度看，你需要记住的核心始终是：函数帧里有一个跟异常状态相关的字段，handler 依赖这个字段知道“当前执行到哪了”。

3.4 catch块匹配：__CxxFrameHandler如何找到正确的catch

当一个 C++ 异常沿着链表被分发到某个函数时，真正干活的函数是 __CxxFrameHandler。它拿到异常代码，如果发现不是 C++ 异常，直接返回 ExceptionContinueSearch。如果是 C++ 异常，它会：

1. 从 RaiseException 的参数数组中取出 _ThrowInfo 和异常对象地址。
2. 读取当前函数帧的 tryLevel / scopetable 状态，明确当前处于哪个 try 区。
3. 从当前 try 区对应的 catch 描述表里，逐个取出 catch 块，用 RTTI 信息与异常对象携带的类型列表比对。
4. 类型匹配后，开始展开（unwind）当前函数中所有比该 try 区更深层的局部对象，调用它们的析构函数。
5. 最后修改异常上下文中的 EIP 和 ESP，把控制权直接交给 catch 块的代码。

这就是 catch 在汇编层的全貌。它的复杂之处在于第 4 步的展开过程：编译器为每个可能有析构对象的区域都生成了展开表，__CxxFrameHandler 根据当前栈指针和 tryLevel 计算哪些对象需要析构，按构造的逆序调用析构函数。一旦这一环节的数据表被损坏，就会出现我开头说的情况——析构函数在异常展开路径上崩溃。

4. 从反汇编样本看异常结构的实际形态

4.1 准备一个最小复现样本

理论讲再多，不如实际拉一段汇编看看。我准备了一个最简单的例子，源码如下：

cpp复制void g() {
    throw 1;
}

void f() {
    try {
        g();
    }
    catch (int e) {
        // ... 处理 int 异常
    }
}

用 32 位 MSVC 编译，Debug 模式默认选项，不做任何优化。这样能最大程度保留结构信息，便于观察。

编译后在 IDA 或 x64dbg 中打开，定位到 f 函数，你会看到一个清清楚楚的异常处理帧构建过程。Debug 构建因为包含完整栈帧，ebp 会被用作帧基址，__$EHRec$ 很容易定位。

4.2 逐条解析关键汇编

以下是一段典型的 32 位 Debug 反汇编（伪指令格式，跟具体编译器版本会略有差异）：

asm复制push        ebp
mov         ebp, esp
push        -1                     ; tryLevel = -1
push        offset __ehhandler$f   ; handler 地址
mov         eax, dword ptr fs:[0]
push        eax                    ; 保存旧 fs:[0]
mov         dword ptr fs:[0], esp  ; 挂入链表
sub         esp, 20h
mov         dword ptr [ebp-10h], esp ; 保存用于展开的 ESP
...
lea         ecx, [ebp-14h]         ; 一些局部变量初始化
mov         dword ptr [ebp-14h], 0
...
call        g                      ; 调用 g()，g 内部会 throw
...
mov         dword ptr [ebp-4], 0   ; 标记进入 try 块

注意这里 [ebp-4] 实际上就是第三字段的位置。它初始为 -1，进入 try 块前被改成 0。异常发生时，__ehhandler$f 会读取 [ebp-4] 的值，再通过这个索引去函数描述表里找对应的 catch 块。

g 内部 throw 的汇编前面已经说过，这里不再重复。关键是当 RaiseException 返回分发流程后，__ehhandler$f 会被系统调用。如果你在调试器里对 __ehhandler$f 下断点，能看到它的参数里有 EXCEPTION_RECORD，其中 ExceptionCode == 0xE06D7363，NumberParameters == 2，ExceptionInformation[0] 指向 _ThrowInfo，ExceptionInformation[1] 指向异常对象临时体。这组参数是 C++ 异常在 Windows 上最核心的握手信息。

接着 __CxxFrameHandler 用 _ThrowInfo 里的类型描述和 [ebp-4] 指向的 catch 表做比对，匹配上 int 后进入展开流程，然后修改上下文，跳转到 catch 块。catch 块内如果有局部对象，也会构造新的栈帧，但函数的异常保护记录仍然沿用外层函数的记录，因为 catch 块本质还是同一个函数体内的代码。

4.3 优化开关对异常结构的影响

如果你用 Release 构建，再打开 /O2，看到的形态会变很多。优化器会做几件事：

第一，如果 try 块很薄，或者 catch 只在特定路径可达，编译器可能把多个状态合并，减少 tryLevel 的赋值点。你不再看到清晰的 mov [ebp-4], 0，而是看到 tryLevel 的更新跟某个分支合并在一起。

第二，帧指针省略（/Oy）会导致没有 ebp 做基址，异常帧的定位变成相对 esp 的偏移。此时调试器如果符号信息不全，想找到 __$EHRec$ 会比较痛苦，要顺着函数入口的 mov dword ptr fs:[0], esp 指令，沿着 esp 的后续变化手动计算偏移。

第三，编译器可能会将整个异常路径从正常路径中剥离，放在函数末尾的 cold 区。这种优化在商业软件很常见，IDA 里经常能看到一个函数的末尾堆着一大段 catch 逻辑，而正常逻辑早就返回了。

理解优化后的结构，核心还是抓住两点：函数入口构建链条的动作在哪，tryLevel 或等价状态字段放在栈帧哪个偏移。抓稳这两个锚点，无论优化怎么变形，你都能把它还原出来。

5. 调试与排障：借助调试器榨干细节

5.1 WinDbg观察SEH链表的操作

理论说完了，分享点实际干活时的工具操作。我在 WinDbg 里看 32 位 dump 或活动进程时，第一条命令永远是：

text复制!exchain

这个扩展命令会从 fs:[0] 出发，把整个异常处理链打印出来。你会看到一长串地址，每一条都对应一个活动函数的异常处理记录，最后以 ntdll!... 之类的系统最后防线收尾。如果在链上看到你的模块符号（比如 MyApp!f+0x50），就说明这个函数还挂在栈上，异常有机会先经过它。

查看当前线程 TEB 和 TIB 可以用：

text复制!pcr

_NT_TIB 的 ExceptionList 字段就在 fs:[0] 处。直接读内存也行：

text复制dd fs:[0] L1

拿到链表头地址后，用 dd /c2 一列一列地往后拉，每一条记录的 Next 和 Handler 都清清楚楚，跟 !exchain 的输出能对应上。

5.2 断点与异常分发时间线

调试异常处理流程，最有效的断点是系统异常分发函数。在 x86 上通常是 ntdll!KiUserExceptionDispatcher 和 ntdll!RtlRaiseException。如果你想观察 throw 从哪里触发，直接对 _CxxThrowException 下断点即可。

如果你已经知道问题出在某个函数的 handler 上，可以对这个特定地址下断点。比如：

text复制bp MyApp!f+0x1A

当断点命中后，用 k 看调用栈，用 dt ntdll!_EXCEPTION_RECORD @ecx（不同调用约定参数位置不同，32 位默认 stdcall 会从栈上传参）查看异常代码和参数。实际上 32 位下 __ehhandler 调用时，第一个参数是 EXCEPTION_RECORD*，通常在栈顶，用 kp 或 dd esp 就能看到。

一个我常用的套路是搜内存里的 0xE06D7363。比如：

text复制s -d 0 L?4000000 0xE06D7363

这个指令在当前进程前 64MB 范围搜索 C++ 异常特征码。一旦搜到，周围往往就是 _ThrowInfo 或异常对象。这个技巧在分析函数栈已经被破坏的 dump 时极其好用——代码和数据不一定在栈上，但特征码往往还在内存中。配合 ln（列出最近符号）和 dps 能快速还原抛出点的上下文。

5.3 常见坑：ContinueSearch、类型不匹配、展开丢失

第一个常见坑是 ExceptionContinueSearch 的误判。在 32 位下，如果自己实现了 SEH handler，忘记在无法处理时返回 ExceptionContinueSearch，而是返回了 ExceptionContinueExecution，系统会认为异常已经解决，然后在抛出点重新执行，大概率再次触发异常，形成死循环。这种问题在混合使用 C++ 异常和 SEH 的代码里反复出现，只要把返回码弄错，你的程序就会卡在一个看起来不断触发异常的状态。

第二个坑是类型不匹配导致的“接不住异常”。源码里 catch 写的是 catch(const std::exception&)，但异常对象实际是从某个自定义基类继承来的，且虚析构不完整，RTTI 比较阶段就会出问题。反汇编时你会看到一个现象：__CxxFrameHandler 返回 ExceptionContinueSearch，异常继续往上走，最终到 UnhandledExceptionFilter。如果你在源码层面觉得“明明有 catch 但没接住”，可以顺着 _ThrowInfo 的类型描述和 catch 表做逐一比对，看是偏移算错还是类型描述符根本对不上。

第三个坑是展开路径上的析构函数崩溃。异常展开会按逆序调用局部对象的析构函数，一旦对象指针偏移算错，可能在析构里访问到非法地址。此时整个栈虽然是在 unwind，但崩出来的栈帧往往不是原始 throw 点，而是某个看似毫无关系的析构函数。遇到这种情况，不要只盯着新的崩溃栈，要回到 EXCEPTION_RECORD 参数里找原始的抛出地址和上下文。32 位下，展开过程的上下文可能保存在 DispatcherContext 参数里，顺着它就能还原异常发生时的 EIP 和 ESP。

6. 64位世界的变化与后续扩展

6.1 64位为什么不再维护栈上的SEH链表

聊完 32 位，必须提一嘴 64 位，否则你可能会在切换平台后产生巨大的困惑。64 位 Windows 的异常处理模型，不再是通用寄存器段 + 栈链表，而是彻底改成了“表驱动”的模型。这里有三个原因比较关键：

一是安全考虑。栈上的 SEH 链表在历史上是注入攻击的经典目标，攻击者伪造一个节点，把 Handler 指向 shellcode，等下一次异常就能触发。64 位改为表驱动后，异常处理数据不再放在可写栈上，而是放在只读数据段，想篡改的难度大大增加。

二是栈回溯的精确性需求。64 位系统的函数调用约定中，rsp 对齐要求和寄存器保存规则更严格，系统需要一个更确定的方式知道每个函数的栈帧大小和返回地址位置，单纯靠链表回溯容易出错。

三是性能。表驱动方案用地址区间查表即可找到对应展开信息，避免了异常发生前在函数入口处反复修改 fs:[0] 的开销。函数不进异常路径时，几乎没有额外成本。

6.2 .pdata/.xdata驱动的展开模型

64 位下，PE 文件里有一个 .pdata 节，存储 RUNTIME_FUNCTION 数组。每个条目包含三个字段：函数起始地址、函数结束地址、UnwindInfo 信息地址或偏移。

UnwindInfo 真正描述了函数怎么展开。它里面包含：函数使用的栈大小、非易失寄存器保存位置、是否需要调用异常处理函数、处理函数地址等。当异常发生时，系统用 RtlLookupFunctionEntry 根据当前 RIP 查 .pdata，得到一个 RUNTIME_FUNCTION，接着用 RtlVirtualUnwind 模拟执行“展开指令”，一步步恢复上一个函数的栈帧。

这也意味着，反汇编 64 位 C++ 异常时，你不再直接看栈上的异常链，而是要看 .pdata/.xdata 里的展开指令序列，以及由编译器生成、挂在 .xdata 里的语言处理器（比如 __CxxFrameHandler）和它需要的描述表。好消息是，前 32 位理解的那些概念——_ThrowInfo、catch 类型表、tryLevel 与作用域——在 64 位下依然适用，变的只是分发和展开的机制。把这些功课做扎实，切到 64 位后你会轻松一半。

6.3 下一篇预告与实际建议

这个系列是连续的，下一篇我准备把 64 位下的 UnwindInfo 和 .pdata/.xdata 的完整结构与反汇编过程写清楚，包括如何手动解析展开指令、如何从二进制里还原一个函数的异常处理表。那完全是另一个坑，涉及的细节比 32 位更多。

在进入下一篇之前，给你三条实际建议。第一，一定要亲手编一个带 try/catch 的 32 位程序，在 Release 和 Debug 下各编译一次，用调试器把 __$EHRec$ 构建、tryLevel 变化、handler 调用次数完整走一遍。第二，写个小工具或者用脚本解析你器里那些 __ehhandler$ 开头的符号对应的 .rdata 描述表，把每个函数的状态表拉出来看，你会对编译器生成的这些“隐形数据”有更直观的认识。第三，所有关于异常处理的研究，都建议在 fresh 进程里做，别在你正在跑业务的环境里折腾，因为栈上残留的旧 handler 信息会干扰你的判断。

就我个人经验而言，把 32 位异常结构吃透之后，再去排查线上崩溃 dump，整个思路会清晰很多。异常不再是一个“神秘机制”，而已是可以翻来覆去审查的内存布局和分发流程。希望这篇能给你同样打通任督二脉的感觉。