SEH无法捕获Windows内核崩溃（如BSOD、0x0000007F等），因其运行在Ring 3用户态，而内核崩溃发生在Ring 0，受特权级隔离和硬件异常分发机制阻隔；SEH仅能捕获用户态结构化异常（如ACCESS_VIOLATION）。
SEH 不能捕获 Windows 内核崩溃（如 BSOD、0x0000007F、0x000000D1 等）——它压根收不到这类异常。内核态崩溃发生在 Ring 0，用户态 SEH（__try/__except）运行在 Ring 3，中间隔着完整的特权级隔离和硬件异常分发机制。试图用 SEH “捕获蓝屏”是常见误解，实际能做的只有：提前预防、崩溃后诊断、或拦截用户态触发内核崩溃的临界行为。
为什么 __try/__except 对 BSOD 完全无效
Windows 的异常分发是分层的：KiDispatchException 先在内核中尝试处理（如 IRQL 不匹配、页错误），若无法恢复则直接触发 KeBugCheckEx —— 此时 CPU 已切换到内核栈，所有用户态栈帧、SEH 链、TLS 数据均不可达。__except 块甚至不会被压入 SEH 链，因为异常根本没经过用户态异常调度器（RtlDispatchException）。
- 典型误判场景：驱动调用
MmProbeAndLockPages失败导致 0x000000D1，用户进程里放__try毫无意义 - 真正能被
__except捕获的，仅限于用户态引发的结构化异常（如EXCEPTION_ACCESS_VIOLATION、EXCEPTION_INT_DIVIDE_BY_ZERO） - 内核崩溃发生时，整个进程上下文可能已被销毁，连
SetUnhandledExceptionFilter都来不及响应
哪些内核崩溃前兆能在用户态感知并拦截
部分内核崩溃由用户态操作直接诱发，且存在可检测的中间态。重点盯住三类高危行为：
-
DeviceIoControl调用驱动暴露的 IOCTL 时，若返回STATUS_INVALID_PARAMETER或STATUS_ACCESS_DENIED，可能预示驱动内部已处于不一致状态（后续同请求易触发 0x000000EF） - 映射设备物理内存（
NtMapViewOfSection+OBJECT_TYPE_DEVICE）后执行非法指针解引用，虽触发EXCEPTION_ACCESS_VIOLATION，但若该地址落在 MMIO 区域，可能已导致 PCI 设备锁死，下次中断即蓝屏 - 频繁调用
ZwAllocateVirtualMemory并传入MEM_PHYSICAL标志（需 SeLockMemoryPrivilege），权限缺失时返回STATUS_PRIVILEGE_NOT_HELD，强行提权失败后继续操作易引发 0x0000007E
用户态配合驱动做崩溃前哨：利用 MiniDumpWriteDump + SetThreadErrorMode
当驱动通过 IoRaiseHardError 或写入特定调试寄存器（如 DR0-DR3）向用户态投递“软警告”时，可用以下组合争取诊断窗口：
立即学习“C++免费学习笔记（深入）”；
- 调用
SetThreadErrorMode(THREAD_ERROR_MODE_FAILFAST_ON_UNHANDLED_EXCEPTION, nullptr)防止系统弹窗阻塞线程，确保崩溃路径可控 - 在关键 IOCTL 调用前后，用
MiniDumpWriteDump生成用户态 minidump（注意：必须指定MiniDumpWithFullMemory才能保留驱动映射的物理页信息） - 监听
EVENT_TRACE_FLAG_DISK_FILE_IO类型 ETW 事件，驱动加载/卸载/IRP 完成超时（>5s）是 0x000000ED 的强信号
示例：在 DeviceIoControl 返回非成功码后立即 dump：
if (!DeviceIoControl(hDev, IOCTL_DANGEROUS_OP, &in, sizeof(in), &out, sizeof(out), &bytes, nullptr)) {
DWORD err = GetLastError();
if (err == ERROR_INVALID_PARAMETER || err == ERROR_ACCESS_DENIED) {
HANDLE hFile = CreateFile(L"pre_bsod.dmp", GENERIC_WRITE, 0, nullptr, CREATE_ALWAYS, 0, nullptr);
MiniDumpWriteDump(GetCurrentProcess(), GetCurrentProcessId(), hFile,
MiniDumpWithFullMemory, nullptr, nullptr, nullptr);
CloseHandle(hFile);
}
}
真正有效的内核崩溃分析路径
放弃“捕获”，转向“重建”。用户态唯一能稳定获取的信息是崩溃前最后几个用户调用栈 + 驱动模块时间戳：
- 用
WinDbg -z memory.dmp打开内核内存转储，执行!analyze -v，重点看MODULE_NAME和IMAGE_NAME是否指向你自己的驱动 - 若驱动无符号，用
.symfix+ C:\symbols加载微软公有符号，再用lmvm yourdriver查看基址与时间戳，比对开发机上link /dump /headers yourdriver.sys输出的 timestamp - 在用户态进程崩溃瞬间，用
procdump -ma -e 1 -w yourapp.exe捕获子进程异常，其堆栈中若出现ntoskrnl.exe+0xXXXXX调用，说明正处在内核模式回调中
最常被忽略的一点：内核崩溃日志（C:\Windows\Minidump\*.dmp）默认不包含用户进程完整内存镜像，必须在注册表 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CrashControl 下设置 CrashDumpEnabled = 2 并启用 AlwaysKeepMemoryDump，否则连用户态上下文都丢失。
