seh无法捕获内核级崩溃，因__try/__except仅作用于ring 3用户态异常，而内核崩溃（如0x0000001e）发生在ring 0，此时seh链已失效，进程可能被直接终止或蓝屏。
SEH 不能捕获内核级崩溃
直接说结论：__try/__except 完全无法捕获 Windows 内核态引发的崩溃，比如访问无效内核地址、驱动触发的 0x0000001E（KMODE_EXCEPTION_NOT_HANDLED）、0x0000003B（SYSTEM_SERVICE_EXCEPTION）等蓝屏前的异常。SEH 是用户态机制，运行在 Ring 3；而内核崩溃发生在 Ring 0，此时用户栈已不可靠，SEH 链早已失效。
常见误解是：在主线程包一层 __try 就能“兜住”驱动导致的崩溃——实际执行到那行代码之前，进程可能已被系统强制终止，或直接触发 BSOD，根本不会进入你的 __except 块。
哪些崩溃能被 __try/__except 捕获
SEH 只对当前进程用户态中由 CPU 产生的异常有效，典型包括：
-
ACCESS_VIOLATION（如野指针解引用、向只读页写入） -
INTERRUPTED或STACK_OVERFLOW（需配合/STACK和SetThreadStackGuarantee） - 显式调用
RaiseException抛出的自定义异常
注意：__try/__except 不处理 C++ 异常（throw），那是 C++ EH（try/catch）的职责；二者底层机制不同，混用需谨慎（如未启用 /EHsc 时，C++ 异常可能穿透 SEH 块）。
直播话术巡检系统(Windows版) — 实时语音转写、关键词检测、场景自动切换、告警推送、大屏可视化。支持 Windows VB-Cable 虚拟声卡音频采集，阿里云 ASR 实时识别。一键启动脚本，自动安装环境。
想响应驱动/内核问题，只能靠外部监控
真正可行的方案是脱离进程自身控制流，用独立进程监听目标进程状态：
- 用
WaitForDebugEvent开启调试模式（需DEBUG_PROCESS权限），可捕获EXCEPTION_DEBUG_EVENT，包括部分内核侧转交的异常（如驱动调用KeBugCheckEx前的最后用户态异常） - 监听 Windows 事件日志中的
System日志，过滤Event ID 41（意外关机）、1011（WHEA 错误）等内核错误线索 - 部署
Windows Error Reporting (WER)自定义 handler（注册WerRegisterRuntimeExceptionModule），它能在进程终止前拿到 mini-dump 和异常上下文，比 SEH 更早介入
例如，通过 WerRegisterRuntimeExceptionModule 注册的回调，可能收到 0xE06D7363（MSVC 异常）或 0xC0000005（ACCESS_VIOLATION），但绝不会是 0x0000007E（SYSTEM_THREAD_EXCEPTION_NOT_HANDLED）的原始内核异常码。
调试驱动崩溃必须用 WinDbg + 符号服务器
如果你的程序频繁伴随蓝屏，别在应用层打转。关键动作是：
- 开启内核内存转储（
Control Panel → System → Advanced → Startup and Recovery → Settings → Write debugging information） - 用
WinDbg Preview加载MEMORY.DMP，执行.symfix; .reload; !analyze -v - 检查崩溃模块是否为你的驱动（
lm列出模块，!drvobj查驱动对象），重点关注STACK_TEXT中的调用链和MODULE_NAME
应用层代码里加再多 __try，也掩盖不了驱动中 ExAllocatePoolWithTag 返回 NULL 后未校验就直接解引用的问题——那个空指针最终会变成内核态 ACCESS_VIOLATION，而你连异常发生的位置都看不到。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
