Windows平台VEH与UnhandledExceptionFilter选型及异常处理问询

1. VEH vs UnhandledExceptionFilter：官方推荐与原因 #

不推荐使用UnhandledExceptionFilter（UEF） #

Windows官方早已不推荐依赖UEF作为生产环境的异常捕获方案，核心原因包括：

• 优先级与覆盖问题：在Windows Vista及后续版本中，Windows错误报告（WER）会覆盖UEF的行为，导致自定义的UEF逻辑可能无法触发。
• 多线程与CRT冲突：CRT（C运行时库）内部的异常处理会优先拦截异常，若线程未启用SEH，UEF可能无法捕获到CRT抛出的异常；且UEF是全局设置，无法针对特定线程做差异化处理。
• 不可靠的移除机制：一旦调用SetUnhandledExceptionFilter设置了UEF，后续无法安全地恢复到系统默认的异常处理逻辑，容易引发兼容性问题。

VEH的定位：仅用于诊断/调试场景 #

官方明确VEH（向量异常处理）是诊断工具级别的机制，而非生产环境的异常恢复方案，原因如下：

• 异常处理优先级过高：VEH在异常分发流程的最早期触发，优先级高于SEH、UEF甚至系统级的异常处理。若在VEH中强制返回EXCEPTION_CONTINUE_EXECUTION尝试恢复执行，会干扰系统正常的异常处理链，极易导致进程状态混乱、数据损坏。
• 实现复杂度高：VEH需要手动管理异常链（通过AddVectoredExceptionHandler和RemoveVectoredExceptionHandler），且线程级的VEH需要逐个线程注册，维护成本高。
• 无官方恢复保障：微软从未承诺VEH可以作为可靠的异常恢复手段，仅建议用它来捕获异常信息、生成崩溃dump，用于问题排查。

注：如果你的场景需要生产环境的全局异常捕获，官方更推荐使用**结构化异常处理（SEH）**的__try/__except块（针对特定代码段），或者结合线程本地存储实现线程级的SEH捕获，而非VEH或UEF。

2. 捕获异常后的规范行为 #

工作线程异常（除零、访问违规等硬件异常） #

针对这类会破坏线程状态的异常，规范处理流程如下：

• 收集诊断信息：捕获异常时，记录异常代码、线程ID、调用栈（可通过StackWalk64获取）、寄存器状态等关键信息，用于后续排查。
• 线程安全通知主线程：通过线程安全的通信机制（如命名事件、线程安全队列、原子标志+信号量）将异常信息传递给主线程，避免直接操作UI或共享资源导致竞态条件。
• 安全终止线程：
  • 不要调用TerminateThread，该函数会强制终止线程，导致线程持有的堆内存、文件句柄、临界区等资源泄漏。
  • 应让线程自行退出：在VEH或SEH的处理逻辑中，调用ExitThread返回错误码，或者设置线程退出标志，让线程的主函数自然结束。
• 主线程后续处理：收到异常通知后，可记录日志、标记该线程已失效，若有必要可重启该线程（需保证重启逻辑的独立性，避免复用已损坏的状态）。

主线程异常 #

主线程是进程的核心，一旦出现未处理异常，进程状态已不可靠，规范处理流程如下：

• 优先收集诊断数据：生成崩溃dump（通过MiniDumpWriteDump）、记录完整的调用栈与系统环境信息，这是后续定位bug的关键。
• 优雅清理资源：依次关闭打开的文件句柄、释放堆内存、通知所有工作线程安全退出、断开网络连接或数据库连接，尽量减少资源泄漏。
• 正常终止进程：调用ExitProcess退出进程，避免系统强制终止（系统强制终止会跳过进程的清理逻辑，导致资源泄漏，且无法执行自定义的上报逻辑）。
• 可选的异常上报：若有错误上报机制，在清理资源后将异常信息与dump文件上报到服务器，方便后续修复。

内容的提问来源于stack exchange，提问作者NightFuryLxD