Windows C++ Crash 治理全景：异常机制、崩溃类型与工具链实践

为什么写这个系列

Windows C++ 程序的崩溃治理，是客户端开发和系统编程里绕不开的话题。一个线上 crash 通常不会乖乖在开发环境复现，它更常见的形态是：用户机器上偶发、dump 文件发回来、调用栈看起来 unrelated、本地怎么跑都没事。

这个系列源于我对 Windows C++ 崩溃治理的系统性梳理。核心目标是把零散的知识点串成一条可执行的链路：

1	异常如何被捕获 → 崩溃如何分类 → 如何预防 → 如何用工具定位 → 如何工程化上报

文中出现的代码都是可独立编译运行的小例子，关键结论会配合运行现象说明，方便读者复现和理解。

知识地图

Windows C++ Crash 治理可以分成四条主线：

Windows C++ Crash 治理
├── 一、异常处理机制
│   ├── VEH：向量异常处理
│   ├── SEH：结构化异常处理
│   └── UEF + MiniDump：全局崩溃捕获与 dump 生成
├── 二、常见崩溃类型
│   ├── 空指针 / 野指针
│   ├── 堆破坏（越界、double free、use-after-free）
│   ├── 栈溢出
│   ├── 未初始化变量
│   ├── 内存耗尽
│   └── 纯虚函数调用
├── 三、并发问题
│   └── 多线程竞争
└── 四、大型工程问题
    ├── DLL 加载失败
    ├── 断言
    ├── 静态初始化顺序（SIOF）
    └── 跨模块内存分配

异常处理机制：一条有优先级的链条

Windows 的异常处理不是单一机制，而是多层链条：

异常发生
  → VEH（向量异常处理，最先，可注册多个）
  → SEH（结构化异常处理，__try/__except，栈帧级）
  → C++ EH（try/catch，仅处理 C++ throw 的异常）
  → UEF（未处理异常过滤器，最后兜底，用于生成 dump）
  → WER（Windows 错误报告，系统级）

关键理解：

VEH 优先级最高，可用于 hook 和抢先处理，但每次异常都会被调用，包括已被捕获的异常。
SEH 能捕获系统级硬件异常（如访问违例 0xC0000005），C++ 的 catch(...) 默认不能。
UEF 是崩溃兜底的最后一道防线，生产环境生成 MiniDump 通常在这里做。

一个容易踩坑的细节：调试器会抢在 VEH 之前拦截异常。在 Visual Studio 里按 F5 运行时，自己注册的 VEH 回调可能根本不会被调用；必须按 Ctrl + F5 不调试运行，或者关闭调试器对 Win32 异常的中断，才能验证 VEH 逻辑。这个细节直接影响到你如何在线下正确测试崩溃捕获代码。

常见崩溃类型：不是只会空指针

崩溃类型	根因	治理方向
空指针 / 野指针	解引用无效地址	使用前判空、智能指针
堆破坏	越界写、重复释放、释放后使用	ASan、page heap、RAII
栈溢出	无限递归、大局部数组	递归深度限制、堆分配大对象
未初始化	变量 / 成员未赋初值	声明即初始化、`{}` 初始化
内存耗尽	分配失败未处理	检查返回值、优雅降级
纯虚调用	构造 / 析构期调用虚函数	避免在构造析构中调虚函数

堆破坏是最隐蔽的一类。 越界写入后，Release 模式的 CRT 堆检查宽松，程序可能”正常”跑完；但堆的内部结构已经损坏，后续某个完全无关的 new/delete 才会暴露问题。Debug 模式下反而会在释放时立即触发断言，把问题暴露在发生现场。所以 Debug 下崩溃其实是好事，Release 下”没崩”才更值得警惕。

栈溢出也有一个反直觉点： 把两个大数组放在同一个函数里，即使分别包在 __try/__except 中，也无法在函数入口阶段捕获栈溢出。因为 MSVC 会在函数 prologue 阶段一次性分配整个栈帧，此时 SEH 作用域还没生效。大块内存应该优先用堆分配，或把每个大栈分配隔离到独立函数中。

并发问题：本地不复现，线上偶发

多线程竞争通常不会立即崩溃，但它是很多奇怪崩溃的幕后推手：

竞争会破坏内存结构（如链表节点丢失）。
竞争会诱发野指针、双重释放、use-after-free。
结果依赖线程调度，Debug 模式可能掩盖问题，Release 才偶发。
dump 中的崩溃点往往不是根因，真正的破坏发生在之前某次无保护写操作。

一个经典例子：10 个线程无保护地自增同一个计数器，每次自增在汇编层面是”读 - 改 - 写”三步，线程切换会让多个线程基于同一个旧值加 1，最终计数远小于预期。

治理三件套：互斥锁（std::mutex）、原子变量（std::atomic）、无共享设计。

大型工程问题：平时用不上，一出事就抓瞎

有两个问题在小型项目里几乎不会出现，但在大型 C++ 工程里却是经典噩梦。

静态初始化顺序（SIOF）

C++ 只保证同一编译单元内全局对象的初始化顺序，跨编译单元由链接器决定，顺序不确定。如果全局对象 A 的构造函数依赖全局对象 B，而链接器先初始化 A，A 访问到的就是未初始化的 B，崩溃发生在 main() 之前的 _initterm() 里，调用栈不在业务代码中，极难排查。

核心解法：Meyers’ Singleton，把”程序启动时初始化”改成”第一次用到时初始化”。

// 不推荐：裸全局对象，初始化顺序不可控
B g_b;

// 推荐：函数内 static，首次访问时才构造
B& GetB() {
    static B instance;  // C++11 起线程安全
    return instance;
}

跨模块内存分配

使用 /MT 静态链接 CRT 时，每个 DLL/EXE 都有独立的 CRT 堆。DLL 中 new 的内存，在主程序中 delete 会崩溃，因为两个堆管理器不是同一个。

// DLL 中
char* buffer = new char[100];

// 主程序中
delete[] buffer;  // 危险：跨 CRT 堆释放

两条黄金原则：

不要让全局对象互相依赖（用 Meyers’ Singleton）。
不要跨模块分配 / 释放内存（谁分配谁释放，或统一 /MD）。

工具链：把”看懂崩溃”变成”定位线上崩溃”

代码层面的理解只是第一步。真正的分水岭是工具链实战：

工具	用途	入门方式
WinDbg	分析 MiniDump，还原调用栈	`.ecxr` → `k`
gflags + Page Heap	精确定位堆破坏	`gflags /p /enable yourapp.exe /full`
AddressSanitizer	编译期插桩，抓越界 / UAF	VS 项目属性开启 ASan
Application Verifier	系统级验证堆、句柄、锁	配合 WinDbg 使用
Crashpad / Breakpad	生产级 dump 采集与上报	替换自研 UEF 方案
PDB 符号服务器	线上 dump 还原符号	symsrv + `_NT_SYMBOL_PATH`

一个完整的崩溃治理闭环应该是：

事前预防（代码规范 + 静态检查 + ASan）
    ↓
事中捕获（UEF / Crashpad 生成 dump）
    ↓
事后分析（WinDbg + PDB 还原调用栈）
    ↓
持续优化（统计崩溃率、修复率、新崩溃占比）

本系列文章安排

这个主题会按以下顺序展开，每篇聚焦一个技术层面：

总览篇（本文）：全景地图与治理链路。
异常处理机制篇：VEH / SEH / UEF 的调用顺序、MiniDump 生成、调试器对异常处理的影响。
常见崩溃类型篇：空指针、堆破坏、栈溢出、未初始化、内存耗尽、纯虚调用的现象与治理。
并发与工程问题篇：多线程竞争、DLL 加载、断言、SIOF、跨模块内存分配。
工具链实战篇：WinDbg 分析 dump、ASan、gflags、Crashpad 集成、PDB 符号服务器。

每篇都会保留可运行的代码片段、运行现象和工程结论，力求让读者既能看懂原理，也能落地实践。

写在前面

Windows C++ 崩溃治理不是背几个 API 就能解决的事情。它需要一个完整的认知框架：异常是怎么被一层层处理的、不同类型崩溃在 Debug / Release 下为什么表现不同、为什么有些 bug 本地不复现客户环境才崩、大型工程中有哪些”防御性知识”平时用不上但一出事就致命。

当这些知识点连成网络之后，再拿到一个 dump 文件，你就不会只盯着调用栈发呆，而是能判断：这大概是哪一类问题、应该用什么工具验证、修复后如何回归。到那时候，这些知识才真正变成生产力。