SEH无法捕获Windows内核崩溃（如BSOD），因其仅作用于用户态；内核崩溃发生在Ring 0，CPU已切换至内核栈，用户态SEH链、堆栈帧全部失效，__try/__except根本不会执行。
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。
立即学习“C++免费学习笔记（深入）”；
典型可用场景：
- 加载第三方插件 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版) — 实时语音转写、关键词检测、场景自动切换、告警推送、大屏可视化。支持 Windows VB-Cable 虚拟声卡音频采集，阿里云 ASR 实时识别。一键启动脚本，自动安装环境。
想监控内核问题？只能靠外部机制
对内核级故障，唯一可行路径是脱离崩溃进程本身：
- 用
WerRegisterRuntimeExceptionModule注册运行时模块，配合 Windows Error Reporting（WER）接收APPCRASH或DRIVER_FAULT事件（但仅限用户态触发的驱动错误，非纯内核蓝屏） - 部署内核模式驱动（KMDF/UMDF）配套的 ETW trace session，监听
Microsoft-Windows-Kernel-Boot或Microsoft-Windows-DriverFrameworks-UserMode日志，定位驱动超时、资源泄漏等软性故障 - 在启动时用
sc config <driver_name> start= demand</driver_name>+ 进程守护程序，检测服务意外退出后检查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 的操作——堆管理器可能已损坏
真实案例：某程序在 __except 中调用 FormatMessage 获取错误字符串，结果因语言 DLL 被卸载而再次触发访问违例，形成二次异常，系统直接终止进程而非弹窗。
内核崩溃不是“异常处理没写好”，而是设计层面的不可达区域。盯紧用户态边界，把防御点放在驱动调用前、内存操作前、DLL 加载后——这些地方才真正受你控制。
