SEH无法捕获Windows内核崩溃，因其仅作用于用户态异常；内核态蓝屏（如0x7E、0x D1）由KeBugCheckEx直接处理，不经过用户态SEH链。
SEH（Structured Exception Handling）不能捕获 Windows 内核崩溃，这是根本性限制——内核态异常（如 0x0000007E、0x000000D1 蓝屏错误）根本不会传递到用户态 SEH 框架中，任何试图用 __try/__except 捕获“内核崩溃”的做法都注定失败。
为什么 __try/__except 对蓝屏完全无效
SEH 是用户态的异常分发机制，依赖于 Windows 的用户模式异常调度器（RtlDispatchException）。而内核崩溃（BSOD）发生在内核态，由 KiDispatchException 处理，直接触发 KeBugCheckEx，跳过所有用户态结构体（包括 TEB 中的 SEH 链）。此时进程可能已被终止，线程栈早已销毁，__except 块连入口都进不去。
- 典型误判场景：程序在驱动调用后不久蓝屏，误以为是自己
__try没包住某句代码 - 真实链路：用户态调用
NtWriteFile→ 进入内核 → 驱动访问非法地址 →KeBugCheckEx(0x000000D1, ...)→ 系统重启，无机会回调用户代码 - 能被
__except捕获的只有用户态异常（如STATUS_ACCESS_VIOLATION在用户地址空间触发时），且必须未被更上层（如 Visual C++ 运行时）先行处理
哪些异常实际能被 __try/__except 捕获
仅限明确发生在当前线程用户态上下文、且未被调试器或运行时拦截的同步异常。常见可捕获项：
-
STATUS_ACCESS_VIOLATION（读写非法用户地址，如野指针解引用） -
STATUS_INTEGER_DIVIDE_BY_ZERO（除零） -
STATUS_STACK_OVERFLOW（需配合/STACK和栈探针，且不能在 SEH handler 里再爆栈） -
STATUS_ILLEGAL_INSTRUCTION（执行非法指令，如__emit 0xFF） - 注意：
STATUS_BREAKPOINT（int 3）默认被调试器吞掉，非调试下才进__except
示例（可靠可运行）：
直播间话术巡检-windows
下载
直播话术巡检系统(Windows版) — 实时语音转写、关键词检测、场景自动切换、告警推送、大屏可视化。支持 Windows VB-Cable 虚拟声卡音频采集，阿里云 ASR 实时识别。一键启动脚本，自动安装环境。
立即学习“C++免费学习笔记（深入）”；
__try {
int* p = nullptr;
*p = 42; // 触发 STATUS_ACCESS_VIOLATION
} __except(EXCEPTION_EXECUTE_HANDLER) {
OutputDebugString(L"Caught AV in user mode\n");
}想诊断内核问题，该用什么替代方案
面对疑似驱动或系统调用引发的崩溃，必须跳出 SEH 思维，转向内核可观测性工具链：
- 启用
!analyze -v分析内存转储（MEMORY.DMP或MINIDUMP），重点看BUGCHECK_CODE和DEFAULT_BUCKET_ID - 用
WinDbg Preview加载符号后执行lm kv查看加载模块，k看崩溃时内核栈 - 对可疑驱动，用
verifier.exe开启驱动验证（特别是 “Special Pool” 和 “Force IRQL checking”） - 用户态程序可调用
SetUnhandledExceptionFilter捕获未处理异常，记录堆栈（用StackWalk64），但这只反映崩溃前最后一刻的用户态状态，不是内核原因本身 - 避免用
MiniDumpWriteDump在__except中生成 dump——若异常由内存损坏引起，dump 可能已不完整
SEH 实战中最容易踩的三个坑
即使只处理用户态异常，__try/__except 的行为也和直觉有偏差：
- 不能在
__except块里调用 C++ 异常相关函数（如throw、std::terminate），会引发未定义行为；VC++ 运行时本身用 SEH 实现catch(...)，嵌套易冲突 -
EXCEPTION_CONTINUE_EXECUTION极其危险：它要求异常现场完全可恢复（比如修复了指针再重试），但多数ACCESS_VIOLATION是因内存已释放或映射撤销，强行继续大概率二次崩溃 - 使用 /EHsc 编译时，C++ 异常和 SEH 默认隔离；若需混合（如用
__try包裹可能抛 C++ 异常的代码），必须显式用/EHa，否则 C++ 异常不会进入__except
真正关键的不是“怎么写 __except”，而是先确认异常是否真的在用户态发生、是否值得用 SEH 拦截——多数稳定性问题，日志+符号化 dump+驱动验证比花式 SEH 处理更有效。
