Windows硬件异常必须用SEH的__try/__except捕获，filter-expression须返回EXCEPTION_EXECUTE_HANDLER等标准常量；混用SEH与C++异常时需统一使用/EHa编译选项，否则析构函数不执行；__finally是唯一可靠的清理入口，但不可抛异常或触发新SEH。
不能用 try/catch 捕获 Windows 硬件异常（如除零、访问违规、栈溢出），必须用 SEH 的 __try/__except —— 这是唯一能在崩溃前介入的机制。
__except 块里 filter-expression 必须返回标准常量
SEH 不是 C++ 异常，__except 后面的表达式不是布尔值，而是必须明确返回 EXCEPTION_EXECUTE_HANDLER、EXCEPTION_CONTINUE_SEARCH 或 EXCEPTION_CONTINUE_EXECUTION。返回任意非标准整数（比如 1 或 true）会导致未定义行为，常见表现是程序直接终止，不进 __except 块。
常见错误写法：
__except (GetLastError() != 0) { ... } // ❌ 错误：返回值非标准常量正确写法示例：
立即学习“C++免费学习笔记（深入）”；
__except (EXCEPTION_EXECUTE_HANDLER) { /* 处理 */ }或带条件判断的典型模式：
将提醒同步至 Windows/Outlook 日历。用户提及「提醒我」「设置提醒」「加到日历」「同步到日历」「日程」「calendar」「日历」时触发。支持Microsoft Graph API 设备代码流认证，无需 Web 服务器，直接写入用户 Outlook 日历。
__except (GetExceptionCode() == EXCEPTION_ACCESS_VIOLATION ? EXCEPTION_EXECUTE_HANDLER : EXCEPTION_CONTINUE_SEARCH)
-
GetExceptionCode()返回当前异常类型，必须在__except表达式中调用，不能提前存到变量里再用 -
GetExceptionInformation()只在__except块内部有效，不能在 filter-expression 中调用 - filter-expression 执行期间不允许抛 C++ 异常，否则触发嵌套崩溃
混用 SEH 和 C++ 异常时编译选项必须匹配
如果你的项目同时用了 throw 和 __try，编译器选项不一致会破坏对象生命周期管理。关键点是：/EHa 开启“异步异常”支持（即允许捕获 SEH 异常并调用 C++ 析构函数），而 /EHsc 只处理同步 C++ 异常，遇到 SEH 会跳过析构。
后果很实际：
- 用
/EHsc编译 +__try/__except→ 局部std::vector、std::unique_ptr等对象的析构函数**不会被调用**，资源泄漏 - 用
/EHa编译 → 析构函数会被调用，但性能略低，且可能掩盖某些未定义行为（如在析构中抛异常） - 混合模块（C++ 代码调用含 SEH 的 C 静态库）时，主工程必须用
/EHa，否则链接后崩溃位置不可预测
__finally 块是唯一可靠的资源清理入口
当发生访问违规等严重异常时，__try 块内普通 return、goto、甚至 exit() 都可能被跳过，但 __finally 块保证执行（进程终止除外）。这是释放 HANDLE、CloseHandle、VirtualFree、DeleteCriticalSection 的最后机会。
注意点：
-
__finally块里不能再 throw C++ 异常，也不能触发新 SEH 异常（比如又除零），否则系统直接终止进程 - 不要在
__finally里调用可能失败的 API 并忽略返回值（如ReleaseSemaphore失败时不记录），这会让问题更难定位 - 若需记录日志，优先用
OutputDebugString或写入内存映射文件，避免依赖可能已损坏的堆或文件句柄
SEH 无法捕获所有崩溃，别把它当万能兜底
SEH 能拦截大多数结构化异常，但以下情况它完全无能为力：
- 栈溢出（
EXCEPTION_STACK_OVERFLOW）—— 默认 handler 已接管，你的__except块通常收不到 - 调试器附加状态下，部分异常被调试器先截获，你的 filter-expression 可能根本没机会执行
- AVX/SIMD 指令引发的浮点异常，需额外启用
_set_se_translator或控制 MXCSR 寄存器 - 堆损坏（如 double-free、buffer overflow）触发的
HeapValidate失败，属于用户态检查，不是 SEH 异常
真正健壮的做法是：SEH 仅用于记录现场（线程 ID、寄存器快照、调用栈）、生成 minidump、快速退出；长期稳定性靠 ASAN/Dr. Memory 检测、/RTC 启用运行时检查、以及把高危操作隔离进独立进程。
