C++ 利用 SEH 结构化异常捕获 Windows 内核崩溃处理方案及实战【干货】-C++-PHP中文网

SEH无法捕获Windows内核崩溃（如BSOD），因其仅作用于用户态；内核崩溃发生在Ring 0，CPU已切换至内核栈，用户态SEH链、堆栈帧全部失效，__try/__except根本不会执行。

c++ 利用 seh 结构化异常捕获 windows 内核崩溃处理方案及实战【干货】

SEH 不能捕获 Windows 内核崩溃（如 BSOD），它只作用于用户态，内核崩溃时整个进程上下文已不可用，__try/__except 根本不会执行。

为什么 `try`/`except` 对蓝屏完全无效

Windows 内核崩溃（例如 KERNEL_SECURITY_CHECK_FAILURE、IRQL_NOT_LESS_OR_EQUAL）发生在 Ring 0，此时 CPU 已切换至内核栈，用户态线程被强制终止，所有 SEH 链表、TLS 数据、堆栈帧全部失效。你写的 __except 块甚至不会被加载进内存——因为系统已跳转至 KeBugCheckEx 并开始 dump 内存。

常见误判场景：

在驱动测试中看到“程序崩溃”，误以为是用户态异常，实际是驱动触发了内核断言或访问违例，宿主进程只是陪葬
用 SetUnhandledExceptionFilter + __try 双重包裹，仍收不到回调——内核崩溃不走任何用户态异常分发路径
在调试器中单步到 __try 块后蓝屏，误以为“刚进 try 就崩了”，实则是前一条指令已污染内核对象（如释放了正在被 IRP 引用的 MDL）

真正能拦截的只有用户态异常：访问违例、除零、栈溢出

SEH 的有效范围严格限定在当前线程的用户态上下文中。只要异常源在用户空间（比如野指针解引用、向只读页写入、调用已卸载 DLL 的函数），__except 就能捕获并返回 EXCEPTION_EXECUTE_HANDLER。

典型可用场景：

加载第三方插件 DLL 时做沙箱兜底：__try { ((PFN_FUNC)proc)(); } __except(GetExceptionCode() == EXCEPTION_ACCESS_VIOLATION ? EXCEPTION_EXECUTE_HANDLER : EXCEPTION_CONTINUE_SEARCH) { /* 记录日志并清理 */ }
解析不受控的二进制数据（如自定义协议包）前临时设置 __try，避免 memcpy 越界导致进程退出
与旧版 COM 组件交互时，对方可能抛出未文档化的结构化异常（非 C++ exception），SEH 是唯一捕获手段

注意：EXCEPTION_STACK_OVERFLOW 需提前用 SetThreadStackGuarantee 预留空间，否则连 __except 块都压不了栈。

想监控内核问题？只能靠外部机制

对内核级故障，唯一可行路径是脱离崩溃进程本身：

windows-auto

Windows 桌面自动化技能，支持鼠标控制（移动/点击/拖拽/滚轮/截图）、键盘输入（文字输入/按键/组合键）、窗口管理（查找/聚焦/最大化/最小化/关闭/移动）、截图并发送文件。提供两种截图方式：Python pyautogui 截图（集成在自动化流程中）和 PowerShell + .NET 零依赖截图（支持区域截图和多显示器）。当用户需要自动化 Windows 桌面操作、控制鼠标键盘、管理窗口、执行 GUI 自动化任务、截图发送文件时使用。

下载

用 WerRegisterRuntimeExceptionModule 注册运行时模块，配合 Windows Error Reporting（WER）接收 APPCRASH 或 DRIVER_FAULT 事件（但仅限用户态触发的驱动错误，非纯内核蓝屏）
部署内核模式驱动（KMDF/UMDF）配套的 ETW trace session，监听 Microsoft-Windows-Kernel-Boot 或 Microsoft-Windows-DriverFrameworks-UserMode 日志，定位驱动超时、资源泄漏等软性故障
在启动时用 sc config start= demand + 进程守护程序，检测服务意外退出后检查 SYSTEM\CurrentControlSet\Control\CrashControl\LastCrashTime 注册表项和 %SystemRoot%\Minidump\*.dmp

别试图在崩溃进程中“自救”——蓝屏发生时，你的 main() 线程早已被 KeTerminateThread 杀死，所有句柄、内存映射、注册的 APC 全部释放完毕。

实战中最容易踩的坑：混用 SEH 和 C++ exception

Visual C++ 默认开启 /EHsc，此时 throw 不会进入 __except，而 __try 块里抛 C++ 异常会导致未定义行为（常见表现：直接进程终止，不走 catch 也不走 __except）。

必须明确选择一种异常模型：

纯 Win32 SEH：编译加 /EHa，所有异常（包括 C++ exception）都走 __except，但需手动判断 GetExceptionCode()，且 std::string 析构可能失败
混合使用：用 __try 包裹易出错的 C API（如 VirtualAlloc、ReadProcessMemory），内部用 try/catch 处理逻辑异常，二者边界要清晰隔离
绝对禁止：在 __except 块里调用 std::make_shared 或任何可能触发 new-handler 的操作——堆管理器可能已损坏