C++如何利用SEH捕获程序崩溃错误 _ Windows异常处理框架【干货】-C++-PHP中文网

seh 仅能捕获系统抛出的结构化异常（如访问违规），无法处理栈溢出等底层崩溃；__try/__except 可捕获硬件异常，但需确保代码实际触发运行时异常且过滤表达式返回合法值。

c++如何利用seh捕获程序崩溃错误 _ windows异常处理框架【干货】

SEH 不能直接捕获所有崩溃，比如栈溢出、堆损坏、访问已释放内存——它只处理系统抛出的结构化异常（如 EXCEPTION_ACCESS_VIOLATION），且必须在异常发生时栈帧完整、未被破坏。

如何用 `try / except` 捕获访问违规等系统异常

Windows SEH 的核心是编译器扩展语法，不是 C++ 异常机制，不走 throw/catch 流程。它能拦截 CPU 触发的硬件异常（如除零、空指针解引用、越界读写）和系统主动抛出的异常（如 RaiseException）。

关键点：

__try 块内必须有实际可能触发 SEH 异常的代码，纯逻辑错误（如 int x = 1/0;）在优化开启时可能被编译器提前报错或优化掉，不一定触发运行时异常
__except 的过滤表达式必须返回 EXCEPTION_EXECUTE_HANDLER、EXCEPTION_CONTINUE_SEARCH 或 EXCEPTION_CONTINUE_EXECUTION；返回值错误会导致未定义行为
过滤表达式中调用函数需谨慎：若该函数又触发异常，会进入未定义状态（栈可能已不稳定）

示例：

LONG WINAPI TopLevelExceptionHandler(EXCEPTION_POINTERS* pEx) {
    // 全局异常兜底，但此时栈很可能已损坏，仅适合记录日志+快速退出
    return EXCEPTION_EXECUTE_HANDLER;
}
<p>SetUnhandledExceptionFilter(TopLevelExceptionHandler);</p><p><strong>try {
int<em> p = nullptr;
</em>p = 42; // 触发 EXCEPTION_ACCESS_VIOLATION
} </strong>except (GetExceptionCode() == EXCEPTION_ACCESS_VIOLATION ? 
EXCEPTION_EXECUTE_HANDLER : EXCEPTION_CONTINUE_SEARCH) {
printf("捕获到访问违规\n");
}</p>

为什么 `try / finally` 比 `__except` 更安全

__finally 块保证在 __try 块退出时（无论是否异常、是否被捕获）都会执行，适合资源清理；而 __except 处理后继续执行后续代码，容易掩盖问题或引发二次崩溃。

常见误用场景：

C++ Code Review Master

组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。

下载

在 __except 中尝试“修复”指针并继续运行（如把 nullptr 改成有效地址）——这违反内存安全模型，下一次访问仍可能崩溃
在 __except 中调用复杂函数（如 malloc、std::string::append）——堆管理器可能已处于不一致状态
嵌套 __try 时未正确判断异常来源，导致本该上抛的异常被意外吞掉

推荐做法：用 __try / __finally 确保文件句柄、内存映射、临界区等资源释放；崩溃捕获交给顶层 SetUnhandledExceptionFilter 或向量化异常处理（Vectored Exception Handling）。

SEH 与 C++ 异常混用时的致命陷阱

VC++ 默认启用 /EHsc（仅处理 C++ 异常），此时 __try / __except 仍可用，但若在 __try 块中抛出 throw，SEH 过滤器**不会触发**；反过来，在 C++ catch 块里触发访问违规，也不会被外层 __except 捕获——两者异常分发路径不同。

真正危险的是启用 /EHa（异步异常模式）：

它让 catch(...) 能捕获 SEH 异常，但会极大拖慢所有 C++ 异常处理路径（插入额外检查）
编译器可能为每个函数生成额外的异常展开表，增大二进制体积
标准库容器（如 std::vector）内部操作若触发 SEH，/EHa 下可能进入未定义状态（因析构函数调用顺序不可控）

结论：不要为“统一捕获”启用 /EHa。SEH 和 C++ 异常应分层使用——SEH 处理底层系统错误（记录+退出），C++ 异常处理业务逻辑错误（可恢复）。

崩溃转储与调试信息必须配套才有效

仅用 SEH 捕获异常却不生成 minidump，等于只听见警报没查现场。调用 MiniDumpWriteDump 时注意：

必须传入当前线程的 EXCEPTION_POINTERS*（来自 __except 或异常回调），否则 dump 缺失上下文
dump 类型至少包含 MiniDumpWithIndirectlyReferencedMemory 和 MiniDumpScanMemory，否则无法还原 STL 容器内容
PDB 文件必须和二进制严格匹配（时间戳、校验和），否则 WinDbg 无法解析符号——尤其注意 CI 构建时禁用 PDB 时间戳随机化（/Zi + /Fd）

最易忽略的一点：SEH 异常处理器运行在崩溃线程上下文中，此时主线程可能卡在 malloc 锁里，调用任何依赖堆分配的 API（包括 std::ofstream）都可能死锁。dump 写入必须用 WriteFile 直接操作句柄，且避免跨 DLL 边界调用。