SetUnhandledExceptionFilter仅捕获SEH异常（如空指针、除零），不捕获C++异常；需全局静态函数注册，避免在回调中调用CRT，配合std::set_terminate实现混合兜底。
SetUnhandledExceptionFilter 能捕获哪些异常
它只捕获结构化异常（SEH），比如访问空指针、除零、栈溢出等底层硬件/系统级错误，不捕获 C++ 标准异常（throw std::exception）。如果你 throw 了一个 std::runtime_error 却没被 catch，SetUnhandledExceptionFilter 完全无感知——那是 std::terminate 的职责范围。
常见误判场景：
- 在 VS 调试器下运行时，很多 SEH 会被调试器先截获，导致你的过滤器根本没机会执行
- 多线程环境下，该过滤器是进程全局的，但只对主线程或未显式设置过滤器的线程生效；新线程需单独调用
SetThreadExceptionFilter（Windows 10 1803+）或依赖全局设置 - 如果程序启用了 /SAFESEH 或 /DYNAMICBASE，某些异常可能被系统安全机制拦截，绕过你的回调
如何正确注册并保证回调被调用
必须在程序早期注册，且确保回调函数地址有效、具备正确的调用约定（LONG WINAPI）。典型错误是把 lambda 或普通成员函数直接传入——它们无法满足 SEH 回调签名要求。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 回调函数必须是
static或全局函数，声明为LONG WINAPI MyExceptionHandler(PEXCEPTION_POINTERS) - 注册前检查返回值：
LPTOP_LEVEL_EXCEPTION_FILTER old = SetUnhandledExceptionFilter(MyExceptionHandler);，若返回NULL，说明已被其他库（如 Qt、.NET 混合代码）覆盖，你得协调或链式调用原过滤器 - 避免在回调里做复杂操作：不要 new/malloc、不要调用 STL 容器、不要加载 DLL；推荐只做最小快照（如写 minidump、记录寄存器和栈帧）后快速退出
- 在 Release 模式下测试，Debug 模式下 Visual Studio 默认勾选“启用本机运行时检查”，会干扰 SEH 流程
为什么写完回调却收不到崩溃信息
最常见原因是异常发生在 DLL 中，而该 DLL 是以 LOAD_WITH_ALTERED_SEARCH_PATH 或延迟加载方式注入的，其异常未路由到主模块的过滤器。另一个隐蔽问题是：如果崩溃点在 DllMain、TLS 回调或静态构造函数中，SEH 链可能尚未建立完全，SetUnhandledExceptionFilter 无效。
验证是否生效的小技巧：
- 在回调开头写一行输出到文件或 OutputDebugString，并用
__debugbreak()触发断点，确认函数真被进了 - 用
ReadProcessMemory在回调中读取EXCEPTION_POINTERS->ExceptionRecord->ExceptionAddress，再用MiniDumpWriteDump生成 dump，比单纯打日志更可靠 - 注意 x64 下 Structured Exception Handling 是基于 RtlDispatchException 的栈展开机制，若栈已损坏（如 buffer overflow 覆盖了 RBP/RSP），回调可能根本不会触发
替代方案：C++ 异常 + SEH 混合兜底更实用
单靠 SetUnhandledExceptionFilter 无法覆盖全部崩溃路径。真实项目中应分层处理：
- 用
std::set_terminate捕获未捕获的 C++ 异常，配合std::current_exception记录类型与 what() - 用
SetUnhandledExceptionFilter捕获 SEH，重点保存上下文（线程 ID、模块基址、栈回溯） - 二者都应避免调用 CRT 函数（如
fopen、malloc），改用 Windows API（CreateFileW、VirtualAlloc）确保内存与句柄安全 - 若使用第三方 crash 上报 SDK（如 Crashpad、Breakpad），它们内部已封装好 SEH + terminate + signal 多路捕获，直接集成比手写更稳
真正难的不是注册这个 Filter，而是确保它在各种编译选项、注入场景、内存破坏状态下依然能拿到可用现场——多数崩溃日志为空白，问题往往出在回调里用了不安全的 API 或假设了堆可用。
