SEH不能捕获Windows内核崩溃（如BSOD），因其仅作用于用户态，而蓝屏等内核异常发生在Ring 0，SEH帧在CPU切换至内核错误路径时已被清空。
SEH 不能捕获 Windows 内核崩溃（如 BSOD、0x0000007E、0x0000003B），它只作用于用户态代码；试图用 __try/__except 拦截内核级异常，结果只会是无效或进程直接终止。
为什么 __try/__except 对蓝屏无用
Windows 内核崩溃（例如驱动误写内存、IRQL 不当提升、访问已释放的内核池）发生在 Ring 0，而 SEH 是用户态（Ring 3）的结构化异常处理机制，两者隔离严格。当内核触发 bug check，CPU 直接切换到内核错误处理路径，用户进程的 SEH 帧早已被清空。
常见误解场景：
- 在驱动测试程序里加
__try，期望捕获0x0000001A（MEMORY_MANAGEMENT）——实际什么也捞不到，进程通常在蓝屏前就被系统终止或挂起 - 用
SetUnhandledExceptionFilter注册回调，发现蓝屏时回调根本没执行——因为未处理异常发生在内核，不是进程的UnhandledExceptionFilter范围 - 调试器（如 WinDbg）能“看到”内核异常，但那是通过内核调试接口（KD protocol），不是 SEH
真正能做的：捕获用户态触发的内核交互异常
虽然抓不住 BSOD，但你可以拦截那些因调用有问题的驱动接口而引发的用户态异常——比如驱动在 DeviceIoControl 中触发了 STATUS_ACCESS_VIOLATION 或 STATUS_INVALID_PARAMETER，这类异常会以 EXCEPTION_ACCESS_VIOLATION 等形式回传到用户层，SEH 可以捕获。
立即学习“C++免费学习笔记（深入）”；
实操要点：
- 所有对可疑驱动的
DeviceIoControl、ReadFile、WriteFile调用，必须包裹在__try/__except中 - 在
__except块里检查GetExceptionCode()是否为EXCEPTION_ACCESS_VIOLATION、EXCEPTION_PRIV_INSTRUCTION等，而非假设它代表蓝屏 - 避免在
__except块中调用可能再次触发异常的函数（如malloc、printf），优先用栈变量和OutputDebugString - 注意：某些驱动会故意将错误包装成
ERROR_INVALID_HANDLE等 Win32 错误码返回，这时 SEH 根本不触发——得靠GetLastError()配合判断
替代方案：用 WER + 自定义 dump 收集现场
当驱动问题导致你的进程异常退出（即使没蓝屏），SEH 捕获后最务实的做法不是“恢复”，而是保现场：
- 在
__except分支中调用MiniDumpWriteDump，生成用户态 minidump，包含线程上下文、模块列表、堆栈——这对后续分析驱动哪条 IOCTL 出错很关键 - 配合
SetErrorMode(SEM_NOGPFAULTERRORBOX)防止弹窗阻塞，再用WerRegisterRuntimeExceptionModule向 Windows 错误报告（WER）注册自定义 handler - 不要依赖
UnhandledExceptionFilter全局捕获：它可能被其他 DLL（如 .NET 运行时、Qt）覆盖；SEH 块更可控 - 若需关联内核日志，记得同时采集
etl文件（用xperf或logman开启Microsoft-Windows-Kernel-Process等 provider）
调试与验证的关键细节
光写 __try 没用，不验证等于没做：
- 用
!analyze -v在 WinDbg 中确认异常是否真来自用户态（看KiUserExceptionDispatcher是否在栈顶） - 在 x64 下，SEH 要求启用 /EHsc 编译选项，且不能在
noexcept函数里使用__try——否则编译报错C3938 - 用 Application Verifier 开启 “Heaps” 和 “Exceptions” 检查，可提前暴露驱动引发的堆破坏，比等蓝屏更早发现问题
- 注意：SEH 在 DLL 中使用时，若 DLL 被热卸载（
FreeLibrary），其 SEH 表可能失效，异常会跳转到调用方的 handler 或直接崩溃
真正难的不是写 __try，而是分清异常源头在哪一层——用户栈、内核栈、还是驱动的中断服务例程（ISR）。混淆这个边界，所有异常处理逻辑都会南辕北辙。
