SEH不能捕获Windows内核崩溃（如BSOD、0x0000007F、0x0000003B），因其仅作用于Ring 3用户态，而内核崩溃发生在Ring 0，异常不经过用户态调度链，__except块根本无执行机会。
SEH（Structured Exception Handling）不能捕获 Windows 内核崩溃，这是根本性限制——内核态异常（如 0x0000007F、0x0000003B 等蓝屏错误）根本不会传递到用户态 SEH 框架中，任何尝试“用 __try/__except 捕获 BSOD”的做法都注定失败。
为什么 __try/__except 对内核崩溃完全无效
Windows 的异常分发是严格分层的：内核态异常（如页故障、除零、非法指令发生在 Ring 0）由内核直接处理，触发 KeBugCheckEx，跳过所有用户态异常调度链。SEH 只响应 Ring 3 层面的结构化异常（如 STATUS_ACCESS_VIOLATION 来自访问非法用户地址），而内核崩溃时进程早已被终止或挂起，__except 块根本没有执行机会。
- 典型误判场景：在驱动测试中故意触发
ExAllocatePool(NonPagedPool, 0)或写入0x00000000，期望__except捕获——实际结果是立即蓝屏，你的__except一行都不会执行 -
SetUnhandledExceptionFilter同样无效：它只接管未处理的用户态异常，不介入内核 BugCheck 流程 - 工具链层面验证：用 WinDbg 连本地内核调试，触发崩溃后看调用栈，会发现全程在
ntoskrnl.exe内，毫无用户模块帧
哪些异常能被 __try/__except 实际捕获
SEH 真正适用的是用户态可恢复的硬件/系统异常，且必须满足：发生于当前线程上下文、未被更上层过滤器拦截、未导致进程强制终止。
- 可捕获：
STATUS_ACCESS_VIOLATION（读写空指针、释放后使用）、STATUS_INTEGER_DIVIDE_BY_ZERO、STATUS_STACK_OVERFLOW（需提前预留栈空间） - 需注意：
STATUS_STACK_OVERFLOW默认无法用标准__try捕获，必须配合/STACK链接器选项和SetThreadStackGuarantee预留备用栈 - 不可捕获：
STATUS_POSSIBLE_DEADLOCK（死锁检测警告）、STATUS_GUARD_PAGE_VIOLATION（若已映射为合法内存）、所有以0xC0000xxx开头但由内核主动引发的非用户触发异常
替代方案：如何间接感知或响应系统级崩溃
既然无法捕获，就转向“事后观测”和“环境监控”。重点不是拦截，而是快速识别崩溃是否波及自身进程或服务。
立即学习“C++免费学习笔记（深入）”；
- 用
RegisterApplicationRestart+Application Recovery and Restart (ARR)在进程因系统不稳定被终止后自动拉起（适用于 GUI 应用） - 监听 Windows 事件日志中的
System日志源，过滤Event ID 41（意外关机）、6008（关机未正常完成）——需EVENTLOG_SYSTEM_SOURCE权限 - 对关键服务，用
OpenSCManager+QueryServiceStatus定期检查依赖驱动状态；崩溃后驱动通常变为SERVICE_STOPPED或SERVICE_STOP_PENDING - 避免轮询：用
NotifyAddrChange或WTSRegisterSessionNotification捕获会话断开信号，常是蓝屏后的第一表现
真正容易被忽略的点是：很多开发者把用户态堆损坏（如 Heap Corruption 导致的 STATUS_HEAP_CORRUPTION）误认为“内核崩溃”，其实它仍属用户态 SEH 可捕获范围——关键看异常代码是否为 0xC0000374 而非 0x0000007F。查清异常代码来源，比强行套用 SEH 更重要。
