如何通过SEH机制高效捕捉Windows系统崩溃？

本文共计1083个文字，预计阅读时间需要5分钟。

Windows下的C++程序崩溃（如访问空指针、除零、栈溢出等）默认会触发未处理的异常，直接弹出系统错误对话框或静默终止。要完全捕获这类底层/系统级异常，必须使用Windows原生异常处理（SEH），而不是C++异常机制。

为什么 try/catch 捕不到访问违规？

C++ 的 try/catch 只处理 C++ 标准异常（throw 抛出的对象）和部分编译器扩展异常（如 MSVC 的 /EHsc 下的 Win32 SEH 转发，但默认不开启且不可靠）。而 0xC0000005（ACCESS_VIOLATION）、0xC0000094（INTEGER_DIVIDE_BY_ZERO）等属于操作系统内核抛出的结构化异常，绕过 C++ 异常栈 unwind 流程。

常见错误现象：

• 写了 try { int* p = nullptr; *p = 1; } catch(...) { }，程序仍崩溃
• 启用 /EHsc 后看似能 catch，但实际是未定义行为：栈可能已损坏，catch 块内调用 printf 或 new 极易二次崩溃
• Release 版本中因优化导致 SEH 表丢失，__try/__except 失效

用 __try/__except 捕获并安全处理

SEH 是 Windows 内核与用户态协作的机制，__try/__except 是 MSVC 提供的语法糖，最终生成 __except_handler3 或 __except_handler4 注册帧信息。关键不是“捕获”，而是“安全响应”。

立即学习“C++免费学习笔记（深入）”；

实操建议：

• 只在顶层函数（如 WinMain、main 入口）或明确隔离的模块中使用，避免嵌套过深
• __except 过滤表达式必须极快完成（不能调用 malloc、printf、std::string 等），推荐仅用 GetExceptionCode() 和简单判断
• 不要在 __except 块中尝试“恢复执行”（如 EXCEPTION_EXECUTE_HANDLER 后 return），除非你 100% 确认寄存器/栈完好（几乎不可能）
• 典型写法：

  LONG WINAPI TopLevelExceptionHandler(EXCEPTION_POINTERS* info) { // 更可靠的方式：用 SetUnhandledExceptionFilter return EXCEPTION_EXECUTE_HANDLER; } SetUnhandledExceptionFilter(TopLevelExceptionHandler);

用 SetUnhandledExceptionFilter 替代局部 __try

对大多数应用（尤其是 GUI 或服务进程），全局异常过滤器比分散的 __try/__except 更实用：它在所有线程、所有未处理异常时触发，且不依赖编译器生成的 SEH 表（不受 /O2 优化影响）。

使用场景：

• 崩溃现场 dump 收集（调用 MiniDumpWriteDump）
• 记录寄存器上下文（info->ContextRecord->Rip, Rsp）和模块信息（GetModuleHandleEx）
• 弹出友好提示后退出，而非让 Windows 显示“该程序已停止工作”
• 注意：DLL 中调用 SetUnhandledExceptionFilter 有线程安全风险；多线程下需确保首次调用在主线程

调试与部署中的关键坑

SEH 在 Debug/Release、静态/动态 CRT、不同 Windows 版本下行为不一致，容易误判：

• /MD（动态 CRT）下，CRT 自身注册了异常过滤器，可能提前截获异常并调用 abort()，导致你的 SetUnhandledExceptionFilter 不生效——解决：在 main 开头立即调用，或链接 /NODEFAULTLIB:libcmt.lib
• 64 位 Windows 使用基于表的 SEH（Table-based SEH），__try/__except 在非主模块（如插件 DLL）中可能被忽略；必须用 SetUnhandledExceptionFilter + AddVectoredExceptionHandler 组合
• Windows 10 1809+ 对 SetUnhandledExceptionFilter 加了限制：若进程启用了 HeapEnableTerminationOnCorruption 或 CFG（控制流防护），某些堆破坏异常无法被捕获——此时需配合 HeapSetInformation 和 IsProcessorFeaturePresent(PF_FASTFAIL_AVAILABLE) 判断

真正棘手的从来不是“怎么写个 __except”，而是如何在优化、多线程、模块加载、安全策略共存的环境下，让崩溃上下文不丢失、不二次崩溃、还能拿到有效诊断信息。