SEH不能捕获Windows内核崩溃，因其仅作用于用户态（Ring 3），而内核崩溃（如BSOD、0x7E、0xD1）发生在内核态（Ring 0），受特权级隔离和硬件异常分发机制阻隔，异常根本不会到达SEH链。
SEH 能捕获 Windows 内核崩溃吗？不能
直接说结论：SEH（Structured Exception Handling）是用户态机制，运行在 ring 3，而内核崩溃（如 BSOD、KMODE_EXCEPTION_NOT_HANDLED、IRQL_NOT_LESS_OR_EQUAL）发生在 ring 0，SEH 完全无法触及。任何试图用 __try/__except 捕获“蓝屏”的想法，从架构上就走不通。
常见误解是：程序触发了空指针解引用或页错误，然后蓝屏了，所以“是不是没捕获好”。其实——
- 用户态访问非法地址（如
*(int*)0 = 1）会触发EXCEPTION_ACCESS_VIOLATION，这个 可以 被__try/__except捕获 - 但若该操作因驱动缺陷导致内核栈破坏、IRQL 错误或未处理的内核异常，系统已跳转至内核错误分发流程，用户进程早被终止，SEH 根本没机会执行
-
SetUnhandledExceptionFilter也仅作用于当前进程的用户态未处理异常，对内核态事件无效
哪些崩溃能用 SEH 实际拦截？明确边界
SEH 真正能起作用的，仅限于 Windows 用户态结构化异常，典型包括：
-
EXCEPTION_ACCESS_VIOLATION（读/写非法地址） EXCEPTION_INT_DIVIDE_BY_ZERO-
EXCEPTION_STACK_OVERFLOW（需配合/STACK和栈探针检测） EXCEPTION_ILLEGAL_INSTRUCTION- 通过
RaiseException主动抛出的自定义异常
注意：EXCEPTION_GUARD_PAGE 和 EXCEPTION_DATATYPE_MISALIGNMENT 也属此列，但后者在现代 x64 上通常被忽略（硬件自动修正）。实际编码中，最常遇到且值得拦截的是前两项。
立即学习“C++免费学习笔记（深入）”；
Windows 桌面自动化技能，支持鼠标控制（移动/点击/拖拽/滚轮/截图）、键盘输入（文字输入/按键/组合键）、窗口管理（查找/聚焦/最大化/最小化/关闭/移动）、截图并发送文件。提供两种截图方式：Python pyautogui 截图（集成在自动化流程中）和 PowerShell + .NET 零依赖截图（支持区域截图和多显示器）。当用户需要自动化 Windows 桌面操作、控制鼠标键盘、管理窗口、执行 GUI 自动化任务、截图发送文件时使用。
示例：安全访问可能为 nullptr 的结构体字段
__try {
int val = ptr->field; // ptr 可能为 nullptr
} __except (GetExceptionCode() == EXCEPTION_ACCESS_VIOLATION ? EXCEPTION_EXECUTE_HANDLER : EXCEPTION_CONTINUE_SEARCH) {
// 安全降级处理
val = 0;
}
为什么 __try/__except 在 DLL 中容易失效？
关键原因：SEH 表依赖编译器生成的栈展开信息（.pdata / .xdata），而默认 /MD 或 /MT 下，若 DLL 与 EXE 使用不同 CRT 版本或异常处理模型（如一个用 /EHsc，另一个用 /EHa），会导致异常分发链断裂，__except 块不被执行，直接跳到上级过滤器或进程终止。
- 确保所有模块统一使用
/EHa（支持 SEH + C++ 异常混合） - DLL 导出函数若可能抛出 SEH 异常，调用方必须也在兼容模式下链接，否则
__except不生效 - 避免在
DllMain中使用__try—— 此时 loader lock 持有，SEH 基础设施可能未就绪，行为未定义 - Release 模式下启用
/Oy-（禁用帧指针省略）有助于调试期 SEH 定位，但非必需
想诊断内核级问题？别靠 SEH，换工具链
当现象是“程序一跑就蓝屏”，真正要做的不是加 __try，而是定位哪个驱动或内核模块引发了问题：
- 用
WinDbg加载MEMORY.DMP，执行!analyze -v，重点关注MODULE_NAME和IMAGE_NAME - 用
verifier.exe开启驱动验证（特别是勾选 “Special pool”、“Force IRQL checking”）可提前暴露多数驱动违规 - 用户态程序若频繁触发内核异常，检查是否调用了不兼容的旧驱动 API（如直接操作
\.PHYSICALDRIVE0而未校验权限/IRQL） - 用
Process Monitor观察是否有异常的DeviceIoControl调用或驱动加载行为
SEH 是兜底用户态错误的绳子，不是伸进内核空间的钩子。越想用它抓蓝屏，越说明问题不在代码异常处理逻辑里，而在环境、驱动或硬件交互层。
