PE异常表解析实战：深入RUNTIME_FUNCTION与UNWIND_INFO

我在分析一个64位C++程序崩溃转储的时候，遇到过这么一档子事：windbg里栈回溯明明能拿到调用栈，但用别的工具一跑，callstack却是空的，还带一句“unwind data not found”。当时第一反应是符号表坏了，折腾了半天才发现问题出在PE文件的**异常表（Exception Table）**上——不是每个函数都有对应的展开信息，或者说，展开信息本身被某个环节吃掉了。从那次之后，我对PE数据目录里这个常年被忽略的“第4号条目”就格外留神。

这里先说明一下，标题里的PE指的不是微PE、优启通那种装机维护用的预安装环境，而是Portable Executable，也就是Windows下EXE、DLL、SYS这些可执行文件的格式规范。异常表是PE可选头数据目录里的一个条目，在x64和ARM64系统里承担着异常分发、栈展开、崩溃回溯的核心职责。这篇文章打算把它从头到尾拆一遍，再把解析代码写出来，帮大家彻底搞懂“程序跑着跑着崩了，系统是怎么把调用栈翻出来的”。

如果你平时接触二进制分析、逆向调试、驱动开发，或者写编译器后端、做安全产品，又或者只是好奇PE文件内部结构，这篇文章都值得看完。我不光会讲结构和原理，还会给出一套可以直接编译运行的解析器实现，把常见坑也一并说清楚。

1. 异常表在PE文件中的定位

1.1 数据目录里的“第4号房客”

解析PE文件的人都知道一个固定套路：先找DOS头的e_lfanew字段，跳到NT头，看Signature是否为PE\0\0，然后从文件头进入可选头，那里有一张DataDirectory数组。这个数组一共有16个条目，从0到15，分别对应导出表、导入表、资源表、重定位表等。异常表排在第3位，宏定义是IMAGE_DIRECTORY_ENTRY_EXCEPTION，说它是“第4号房客”是因为数组下标从0算起。

每个数据目录条目只有两个DWORD：VirtualAddress（RVA）和Size。异常表的VirtualAddress指向的是一组RUNTIME_FUNCTION结构体数组，这个数组的每一项都记录了一个函数的起始地址、结束地址，以及该函数展开信息的位置。系统在异常分发时通过这个数组快速定位“当前指令属于哪个函数”，再顺着展开信息恢复函数调用前的寄存器状态，从而实现栈回溯。

有一个容易混淆的点：异常表在PE32和PE32+里的数据目录起始偏移不同。因为32位和64位可选头里ImageBase、SizeOfStackReserve这些字段的宽度不一样，导致数据目录数组在文件中的位置也不同。解析器必须分情况处理，不能拿一个固定的偏移量到处套。

1.2 为什么x64和ARM64平台离不开异常表

在x64平台上，微软采用的是基于表的异常处理（table-based exception handling）。这种设计最直接的原因是x64处理器几乎没有为异常处理提供专用的硬件栈帧机制，加上寄存器数量增加、调用约定改用rcx/rdx/r8/r9传参，函数序言（prolog）里有大量保存非易失寄存器的操作。一旦发生异常，系统想恢复到调用者的状态，必须知道“这个函数到底在栈上分配了多少空间、把哪些寄存器压到哪个位置了”。

这些信息从哪来？就来自异常表。当CPU触发异常后，内核将异常分发给用户态的ntdll，RtlDispatchException会调用RtlLookupFunctionEntry，用当前指令的地址在异常表里二分查找，找到对应的RUNTIME_FUNCTION；接着RtlVirtualUnwind按照UNWIND_INFO里的展开操作码，一条条逆推，还原出调用者的寄存器现场和返回地址；然后继续向上重复这个过程，直到最外层函数。这就是我们在调试器里看到的完整调用栈能够成立的根基。

ARM64平台采用了类似的机制，因为ARM64也使用固定寄存器集和基于表的展开，异常表在系统异常分发和回溯中的作用同样举足轻重。可以说，在x64和ARM64世界里，没有异常表的程序在异常来临时连“自救”的能力都没有。

1.3 32位程序的SEH是另一套玩法

写解析器时如果遇到32位PE没有异常表数据目录，千万不要以为文件损坏了。x86体系下的结构化异常处理（SEH）走的是另一条路：异常处理函数指针保存在线程栈上，通过fs:[0]指向的异常链表串起来，属于运行期动态结构。这也意味着x86的栈回溯经常非常痛苦——没有集中式的函数展开信息，调试器只能靠符号和启发式猜测。

当然x86也有SafeSEH机制，它在LOAD_CONFIG目录里保存了一份合法的异常处理器地址表，但这份表的作用是校验异常处理器是否合法，而不是描述函数如何展开栈，作用域和格式都跟x64异常表不一样。所以在解析的时候，看到Machine字段是0x14C（x86），异常表大小经常是0，那是正常的；只有当Machine是0x8664（x64）或者0xAA64（ARM64）时，异常表才是强制存在的。

2. 异常表的核心数据结构

2.1 RUNTIME_FUNCTION数组

x64平台下，每个RUNTIME_FUNCTION是12字节，三个DWORD：

整个异常表就是这样一个结构体数组，按BeginAddress升序排列。排列有序这一点很重要，因为系统要支持二分查找。如果你自己写解析器遍历一般不需要排序，但如果要做地址定位，就得利用这个有序性，或者自己实现一个二分查找，不然几万个函数挨个线性扫，效率会很尴尬。

UnwindData字段的含义有点绕：它的值是展开信息的RVA，但如果最低位是1，就表示当前函数使用的是“链式展开信息”（chained unwind info），此时高31位不再是UNWIND_INFO的RVA，而是一个相对于当前函数BeginAddress的偏移量。真正的展开信息要从这个偏移地址开始找。这条规则是解析时最容易翻车的地方，后面我还会专门讲。

2.2 UNWIND_INFO与UNWIND_CODE

UnwindData指向的UNWIND_INFO才是存放展开细节的地方。它是个长度可变的结构，开头固定4字节：

c复制typedef struct _UNWIND_INFO {
    UBYTE Version       : 3;   // 结构版本，通常为1
    UBYTE Flags         : 5;   // 展开标志
    UBYTE SizeOfProlog;        // 函数序言长度（字节数）
    UBYTE CountOfCodes;        // UNWIND_CODE条目数
    UBYTE FrameRegister : 4;   // 帧寄存器编号
    UBYTE FrameOffset   : 4;   // 帧寄存器偏移（以16字节为单位）
} UNWIND_INFO;

Flags有几个关键值：UNW_FLAG_EHANDLER（1）表示函数有C++异常处理器或语言特定处理逻辑；UNW_FLAG_UHANDLER（2）表示有展开处理器；UNW_FLAG_CHAININFO（4）表示当前展开信息是链式的，真正的内容在另一个RUNTIME_FUNCTION里。如果Flags包含1或2，在UNWIND_CODE数组结束并做4字节对齐之后，还会跟着一个DWORD，指向异常处理函数或展开处理函数的地址。

紧跟着UNWIND_INFO头4个字节的是UNWIND_CODE数组，每个条目也是2字节：

c复制typedef struct _UNWIND_CODE {
    UBYTE CodeOffset;   // 指令在函数序言中的偏移
    UBYTE UnwindOp : 4; // 展开操作码
    UBYTE OpInfo   : 4; // 操作辅助信息
} UNWIND_CODE;

展开操作码才是真正描述“怎么回滚”的指令。常见的有：

注意，某些操作码后面会跟着额外的操作数，这些操作数也占用UNWIND_CODE的槽位（每个槽2字节）。解析时必须根据操作码动态跳过，否则后面的条目全都会错位。这个坑我踩过不止一次，第5章会专门讲。

2.3 用现成工具验证理解：dumpbin与PE-bear

动手写解析器之前，我建议先拿现成工具核对一下自己的理解，免得对着错误模型写半天代码。dumpbin /unwindinfo是最直接的方式，它会列出模块里每个函数的展开信息，输出格式跟UNWIND_CODE几乎一一对应：

bash复制dumpbin /unwindinfo C:\Windows\System32\ntdll.dll

输出里能看到每个函数的RVA范围、UNWIND_INFO版本、序言长度、操作码序列。对照着看一天，基本就把格式长什么样印在脑子里了。

另一个很顺手的工具是PE-bear，它把数据目录可视化成表格，点开Exception Table就能挨个查看RUNTIME_FUNCTION条目，还会自动解析UNWIND_INFO并展示UNWIND_CODE，省去了在十六进制里数偏移的功夫。CFF Explorer也能看到异常表目录项，但细粒度解析不如PE-bear直观。建议先用这些工具“剧透”一下输出，再回来看自己的代码输出是否一致。

3. 手写解析器：从文件字节到UNWIND_CODE

3.1 读取文件与验证PE头

解析器第一步是把PE文件整个读进内存，然后定位NT头。整个过程我倾向于用“最小结构体 + 手动偏移”的方式来做，好处是不依赖Windows SDK，Linux、macOS上也能编译运行。

先从文件最开头验证DOS头，DOS头的e_magic必须是'M' 'Z'（0x5A4D），e_lfanew字段在文件偏移0x3C处，是一个32位整数，指向NT头。跳到NT头后校验Signature是否为0x00004550，也就是P E \0 \0。之后从文件头里取Machine、NumberOfSections、SizeOfOptionalHeader。

这一步很容易犯的错误是：直接从文件偏移0取DOS头，然后以为e_lfanew之后紧跟的就是NT头。实际上在某些壳或特殊构建里，e_lfanew可以指向任意位置，所以一定要严格按照偏移来，不要写死。

3.2 定位数据目录计算RVA转FOA

拿到NT头之后，可选头从e_lfanew + 24开始。需要判断可选头Magic是0x10B（PE32）还是0x20B（PE32+），因为数据目录数组的起始位置不同：

• PE32: 可选头偏移 + 96
• PE32+: 可选头偏移 + 112

数据目录数组每个条目8字节（VirtualAddress + Size），异常表的索引是3，所以从数据目录数组起始位置往下数第4个条目就是异常表。表达式可以写成：

c复制uint32_t exc_rva  = *(uint32_t *)(buf + data_dir_off + 3 * 8);
uint32_t exc_size = *(uint32_t *)(buf + data_dir_off + 3 * 8 + 4);

接下来最关键的一个转换是RVA转FOA。PE文件在磁盘上的布局和加载到内存后的布局并不一致，节的数据在内存中的起始地址（VirtualAddress）和文件中的偏移（PointerToRawData）是不同的。转换方法：遍历节表，找到目标RVA落在哪个节的虚拟地址范围内，然后做偏移换算：

c复制static uint32_t rva_to_foa(const uint8_t *buf, size_t file_size, uint32_t rva) {
    uint32_t e_lfanew = *(const uint32_t *)(buf + 0x3C);
    uint16_t num_sections = *(const uint16_t *)(buf + e_lfanew + 6);
    uint16_t size_opt = *(const uint16_t *)(buf + e_lfanew + 20);
    uint32_t opt_start = e_lfanew + 24;
    uint32_t sec_start = opt_start + size_opt;

    for (int i = 0; i < num_sections; i++) {
        uint32_t sec = sec_start + i * 40;
        uint32_t va = *(const uint32_t *)(buf + sec + 12);
        uint32_t vs = *(const uint32_t *)(buf + sec + 8);
        uint32_t raw_size = *(const uint32_t *)(buf + sec + 16);
        uint32_t raw_ptr = *(const uint32_t *)(buf + sec + 20);

        if (rva >= va && rva < va + vs) {
            uint32_t delta = rva - va;
            if (delta >= raw_size) return 0;
            uint32_t foa = raw_ptr + delta;
            if (foa >= file_size) return 0;
            return foa;
        }
    }
    return 0;
}

这个函数必须是解析器的地基。后面无论是定位异常表数组本身，还是定位每个UNWIND_INFO，都要调它。我的习惯是：凡是转换后检查foa >= file_size就直接返回0，宁可返回0让上层跳过，也不要返回一个越界地址。

3.3 遍历RUNTIME_FUNCTION

异常表数组的RVA和大小从数据目录拿到后，先用rva_to_foa转成文件偏移，然后按每个条目12字节（x64）除法算出条目数。注意大小不一定刚好是12的整数倍，向下取整即可，多出来的几个字节属于对齐填充或冗余数据，直接忽略。

遍历的逻辑其实很直接：对每个条目读出BeginAddress、EndAddress、UnwindData，然后打印出来。判断UnwindData最低位：

• 为0：UnwindData本身就是UNWIND_INFO的RVA，直接转换后解析。
• 为1：UnwindData高31位是相对BeginAddress的偏移，真正的UNWIND_INFO地址是 (UnwindData & 0x7FFFFFFF) + BeginAddress。

这种链式结构在设计上是为了让“叶子函数”或“跳到另一段代码”的函数不用重复保存展开信息，而是指向另一个函数的展开信息。但解析时需要递归或迭代跟随，并且要防止无限循环。我的做法是限制最大深度为8，超过就报错。

3.4 深入UNWIND_INFO内部

定位到UNWIND_INFO之后，先读头4字节，按位域拆出版本、标志、序言长度、代码条数、帧寄存器。然后从偏移4开始，逐个读UNWIND_CODE。每个条目2字节，CodeOffset在低字节，UnwindOp和第4位开始的OpInfo在高字节。

解析UNWIND_CODE时，必须处理带额外操作数的情况。我建议按操作码判断“本条到底占几个槽位”，核心逻辑如下：

c复制int get_slot_advance(uint8_t op, uint8_t info) {
    switch (op) {
        case 1:  // UWOP_ALLOC_LARGE
            return (info == 0) ? 1 : 2;
        case 4:  // UWOP_SAVE_NONVOL
        case 8:  // UWOP_SAVE_XMM128
            return 1;
        case 5:  // UWOP_SAVE_NONVOL_FAR
        case 9:  // UWOP_SAVE_XMM128_FAR
            return 2;
        default:
            return 0;
    }
}

循环时，每处理一个UNWIND_CODE，索引要额外加上get_slot_advance()返回的槽位数，因为这些槽位是给“操作数”用的，不是独立的UNWIND_CODE条目。

如果UNWIND_INFO的Flags包含UNW_FLAG_EHANDLER或UNW_FLAG_UHANDLER，那么在UNWIND_CODE数组结束之后，按4字节对齐的位置会有一个DWORD，是异常处理器或展开处理器的RVA。解析时这个也要读出来，有时候对判断“函数是否参与C++异常处理”很有用。

4. 解析器完整实现与实测

4.1 一个不依赖Windows SDK的C解析器

下面这段代码是我通常拿来应急的版本，完整可编译，不依赖任何平台SDK。它做的事情是：读入一个PE文件，打印异常表目录项，遍历每个RUNTIME_FUNCTION，并解析对应的UNWIND_INFO。

c复制#include <stdio.h>
#include <stdlib.h>
#include <stdint.h>
#include <string.h>

static uint32_t rva_to_foa(const uint8_t *buf, size_t file_size, uint32_t rva) {
    uint32_t e_lfanew = *(const uint32_t *)(buf + 0x3C);
    uint16_t num_sections = *(const uint16_t *)(buf + e_lfanew + 6);
    uint16_t size_opt = *(const uint16_t *)(buf + e_lfanew + 20);
    uint32_t opt_start = e_lfanew + 24;
    uint32_t sec_start = opt_start + size_opt;

    for (int i = 0; i < num_sections; i++) {
        uint32_t sec = sec_start + i * 40;
        uint32_t va = *(const uint32_t *)(buf + sec + 12);
        uint32_t vs = *(const uint32_t *)(buf + sec + 8);
        uint32_t raw_size = *(const uint32_t *)(buf + sec + 16);
        uint32_t raw_ptr = *(const uint32_t *)(buf + sec + 20);

        if (rva >= va && rva < va + vs) {
            uint32_t delta = rva - va;
            if (delta >= raw_size) return 0;
            uint32_t foa = raw_ptr + delta;
            if (foa >= file_size) return 0;
            return foa;
        }
    }
    return 0;
}

static int parse_unwind_info(const uint8_t *buf, size_t file_size, uint32_t unwind_rva, int depth) {
    if (depth > 8) return -1;
    uint32_t fo = rva_to_foa(buf, file_size, unwind_rva);
    if (fo == 0 || fo + 4 > file_size) return -1;

    const uint8_t *p = buf + fo;
    uint8_t version = p[0] & 0x07;
    uint8_t flags = (p[0] >> 3) & 0x1F;
    uint8_t prolog = p[1];
    uint8_t codes = p[2];
    uint8_t frame_reg = p[3] & 0x0F;
    uint8_t frame_off = (p[3] >> 4) & 0x0F;

    printf("      UNWIND_INFO RVA=0x%08X version=%u flags=0x%X prolog=%u codes=%u frame_reg=%u frame_off=%u\n",
           unwind_rva, version, flags, prolog, codes, frame_reg, frame_off);

    if (flags & 4) {
        printf("      -> CHAININFO, skip detailed codes\n");
        return 0;
    }

    uint32_t code_pos = fo + 4;
    int idx = 0;
    for (int i = 0; i < codes; i++) {
        if (code_pos + 2 > file_size) break;
        uint8_t off = buf[code_pos];
        uint8_t op = buf[code_pos + 1] & 0x0F;
        uint8_t info = (buf[code_pos + 1] >> 4) & 0x0F;
        const char *op_name = "?";
        switch (op) {
            case 0: op_name = "PUSH_NONVOL"; break;
            case 1: op_name = "ALLOC_LARGE"; break;
            case 2: op_name = "ALLOC_SMALL"; break;
            case 3: op_name = "SET_FPREG"; break;
            case 4: op_name = "SAVE_NONVOL"; break;
            case 5: op_name = "SAVE_NONVOL_FAR"; break;
            case 6: op_name = "EPILOG"; break;
            case 8: op_name = "SAVE_XMM128"; break;
            case 9: op_name = "SAVE_XMM128_FAR"; break;
            case 10: op_name = "PUSH_MACHFRAME"; break;
        }
        printf("      CODE[%02d] offset=0x%02X op=%s(%u) info=0x%X\n",
               idx, off, op_name, op, info);

        int advance = 0;
        if (op == 1) advance = (info == 0) ? 1 : 2;
        else if (op == 4 || op == 8) advance = 1;
        else if (op == 5 || op == 9) advance = 2;

        code_pos += 2 + advance * 2;
        idx += 1 + advance;
    }

    if (flags & 1) {
        uint32_t handler_off = (code_pos + 3) & ~3u;
        if (handler_off + 4 <= file_size) {
            uint32_t handler_rva = *(const uint32_t *)(buf + handler_off);
            printf("      EHANDLER RVA=0x%08X\n", handler_rva);
        }
    }
    return 0;
}

int main(int argc, char **argv) {
    if (argc < 2) {
        fprintf(stderr, "usage: %s <pe-file>\n", argv[0]);
        return 1;
    }

    FILE *fp = fopen(argv[1], "rb");
    if (!fp) { perror("open"); return 1; }
    fseek(fp, 0, SEEK_END);
    long sz = ftell(fp);
    fseek(fp, 0, SEEK_SET);
    uint8_t *buf = (uint8_t *)malloc(sz);
    if (!buf) { fclose(fp); return 1; }
    fread(buf, 1, sz, fp);
    fclose(fp);

    if (sz < 0x40 || *(const uint16_t *)buf != 0x5A4D) {
        fprintf(stderr, "invalid DOS header\n");
        free(buf);
        return 1;
    }
    uint32_t e_lfanew = *(const uint32_t *)(buf + 0x3C);
    if (e_lfanew + 24 + 4 > (uint32_t)sz) {
        fprintf(stderr, "invalid NT header offset\n");
        free(buf);
        return 1;
    }
    if (*(const uint32_t *)(buf + e_lfanew) != 0x00004550) {
        fprintf(stderr, "invalid PE signature\n");
        free(buf);
        return 1;
    }

    uint16_t machine = *(const uint16_t *)(buf + e_lfanew + 4);
    uint16_t num_sections = *(const uint16_t *)(buf + e_lfanew + 6);
    uint16_t size_opt = *(const uint16_t *)(buf + e_lfanew + 20);
    uint32_t opt_start = e_lfanew + 24;
    uint16_t magic = *(const uint16_t *)(buf + opt_start);

    printf("Machine=0x%04X NumberOfSections=%u OptionalHeaderMagic=0x%04X\n",
           machine, num_sections, magic);

    if (magic != 0x10B && magic != 0x20B) {
        fprintf(stderr, "unknown optional header magic\n");
        free(buf);
        return 1;
    }

    uint32_t data_dir_off = opt_start + (magic == 0x20B ? 112 : 96);
    uint32_t exc_rva = *(const uint32_t *)(buf + data_dir_off + 3 * 8);
    uint32_t exc_size = *(const uint32_t *)(buf + data_dir_off + 3 * 8 + 4);
    printf("Exception directory RVA=0x%08X Size=0x%X\n", exc_rva, exc_size);

    if (exc_rva == 0 || exc_size == 0) {
        printf("No exception table.\n");
        free(buf);
        return 0;
    }

    uint32_t exc_foa = rva_to_foa(buf, sz, exc_rva);
    if (exc_foa == 0) {
        fprintf(stderr, "failed to map exception RVA to FOA\n");
        free(buf);
        return 1;
    }

    int entry_size = 12; // x64/ARM64不同，先用x64
    if (machine == 0xAA64) entry_size = 8;

    uint32_t count = exc_size / entry_size;
    printf("Total RUNTIME_FUNCTION entries: %u\n", count);

    for (uint32_t i = 0; i < count; i++) {
        uint32_t pos = exc_foa + i * entry_size;
        if (pos + 4 > (uint32_t)sz) break;

        uint32_t begin = *(const uint32_t *)(buf + pos);
        uint32_t end = *(const uint32_t *)(buf + pos + 4);

        if (machine == 0x8664) {
            uint32_t unw = *(const uint32_t *)(buf + pos + 8);
            printf("RUNTIME_FUNCTION[%u] Begin=0x%08X End=0x%08X UnwindData=0x%08X\n",
                   i, begin, end, unw);
            if (unw & 1) {
                uint32_t real_unwind_rva = (unw & 0x7FFFFFFF) + begin;
                printf("  CHAIN to RVA=0x%08X\n", real_unwind_rva);
                parse_unwind_info(buf, sz, real_unwind_rva, 1);
            } else {
                if (unw != 0) parse_unwind_info(buf, sz, unw, 0);
            }
        } else {
            printf("RUNTIME_FUNCTION[%u] Begin=0x%08X UnwindData=0x%08X\n",
                   i, begin, end);
        }
    }

    free(buf);
    return 0;
}

这段代码没有做任何花哨处理，但足够把一个x64 PE文件的异常表完整摊开。你在Windows上可以用Visual Studio的cl编译，也可以直接装个gcc在任意平台编译，指令不需要额外参数，因为它没有依赖任何Windows头文件。

4.2 拿真实系统DLL实测

我拿C:\Windows\System32\ntdll.dll测了一下，输出大概是这种感觉：

text复制Machine=0x8664 NumberOfSections=8 OptionalHeaderMagic=0x20B
Exception directory RVA=0x000F21C0 Size=0x00006318
Total RUNTIME_FUNCTION entries: 2102
RUNTIME_FUNCTION[0] Begin=0x00001000 End=0x0000102F UnwindData=0x000F1690
  UNWIND_INFO RVA=0x000F1690 version=1 flags=0x0 prolog=0x0B codes=2 frame_reg=0 frame_off=0
  CODE[00] offset=0x0B op=ALLOC_SMALL(2) info=0x3
  CODE[01] offset=0x04 op=PUSH_NONVOL(0) info=0x3

看到没有，一个典型的函数序言先给栈分配了空间（UWOP_ALLOC_SMALL），然后压入非易失寄存器rbx（info=3）。这些输出跟dumpbin的结果可以对上。

如果拿一个32位DLL来跑，大概率会打印Exception directory RVA=0x00000000 Size=0x00000000，然后输出No exception table。这是完全正常的，不是解析器出了问题。

4.3 用Python快速验证

有时候只是临时想看一眼异常表，没必要编译C代码，Python脚本两三下就能搞定。我经常这样用：

python复制import struct
import sys

def rva_to_foa(data, rva):
    e_lfanew = struct.unpack_from('<I', data, 0x3C)[0]
    num_sections = struct.unpack_from('<H', data, e_lfanew + 6)[0]
    size_opt = struct.unpack_from('<H', data, e_lfanew + 20)[0]
    opt_start = e_lfanew + 24
    sec_start = opt_start + size_opt
    for i in range(num_sections):
        sec = sec_start + i * 40
        vs, va, raw