1. 项目概述为什么Windows C异常捕获是个“老大难”问题干了这么多年C开发尤其是在Windows平台上最让人头疼的莫过于程序在客户现场莫名其妙崩溃日志里就留下一句“已停止工作”然后留下一脸懵的你和暴怒的客户。这种场景相信每个Windows C开发者都经历过。问题的核心往往就在于异常没有被妥善地捕获和处理。Windows环境下的C异常处理远比教科书上讲的try/catch要复杂得多它是一个涉及操作系统机制、编译器实现、运行时库和程序自身架构的复合型难题。所谓“尽可能捕获所有异常”并不是指写出一个能catch(...)所有C标准异常的“银弹”代码。在Windows语境下这指的是构建一套健壮的防御体系能够拦截并妥善处理多种“异常”事件包括但不限于C标准异常如std::runtime_error、结构化异常SEH如访问违规、除零错误、系统未处理异常、甚至是一些由第三方库或系统组件抛出的、难以预料的信号。我们的目标不是阻止所有崩溃那是不可能的而是要在崩溃发生前获取尽可能多的现场信息调用栈、寄存器、内存快照等进行优雅降级或安全退出并留下足够清晰的诊断日志为后续的问题定位和修复提供决定性线索。这不仅仅是写几行try-catch那么简单。它要求你对Windows的异常分发机制、Visual C运行时CRT的异常处理链、以及像Vectored Exception Handling这样的高级特性有深入的理解。同时你还需要考虑如何在多线程环境、动态加载的DLL、以及使用了不同异常模型如/EHavs/EHs的模块之间确保异常处理策略的一致性。接下来我将结合多年的踩坑经验拆解构建这套防御体系的完整思路和实操细节。2. 异常捕获体系的核心架构设计要实现“尽可能捕获所有异常”不能依赖单一机制必须构建一个分层的、纵深防御的体系。这个体系从内到外大致可以分为四个层次每一层都有其特定的职责和捕获范围。2.1 第一层C标准异常处理try/catch及std::terminate这是最内层也是开发者最熟悉的一层。它的核心是C语言标准定义的异常机制。捕获对象所有由throw关键字抛出的、继承自std::exception或其派生类的对象。作用范围仅限于当前线程内且遵循栈展开Stack Unwinding规则会调用局部对象的析构函数。关键限制它无法捕获硬件异常如访问违规0xC0000005、除零错误0xC0000094或操作系统发起的结构化异常SEH除非使用微软扩展的/EHa编译选项。设计考量这一层是我们的业务逻辑错误处理主力。对于可预见的错误条件如文件不存在、网络超时、无效参数应优先使用C标准异常。为了增强健壮性可以在main()函数或线程入口函数的最高层放置一个catch (const std::exception e)防止标准异常逃逸导致std::terminate被调用。我们还可以通过std::set_terminate()设置一个自定义的终止处理器在terminate被调用时例如有异常未被捕获且未被noexcept规范抑制执行一些紧急日志记录和清理工作但这已经是“最后防线”了。注意滥用catch (...)捕获所有异常而不加区分是危险的因为它会拦截你本应处理的特定类型异常也可能意外捕获系统抛出的、本应导致立即退出的严重错误掩盖真正的问题。2.2 第二层结构化异常处理SEH与__try/__except这是Windows平台特有的机制用于处理硬件和操作系统产生的异常。捕获对象结构化异常Structured Exception Handling, SEH包括所有硬件异常访问违规、非法指令、断点等和系统产生的软件异常。语法使用微软扩展的__try、__except、__finally关键字。关键能力__except过滤器表达式可以访问一个EXCEPTION_POINTERS结构其中包含了异常发生时的完整上下文信息寄存器、地址等这是事后调试的黄金数据。设计考量SEH是捕获访问违规等严重错误的关键。通常我们不会在业务代码中到处使用__try/__except而是将其用于关键代码段的保护或者在应用程序的顶层如WinMain或线程入口设置一个全局的SEH过滤器。一个常见的模式是使用SetUnhandledExceptionFilterAPI设置一个顶层的未处理异常过滤器它本质上是一个进程级别的SEH过滤器当异常没有被任何__except块处理时最终会落到这里。这是我们获取崩溃现场信息生成MiniDump的最重要位置。2.3 第三层向量化异常处理VEH与AddVectoredExceptionHandler这是比SEH更底层的机制允许你安装一个回调函数该函数会在任何异常处理包括调试器发生之前被调用。捕获对象所有第一次机会异常First-chance exception。异常发生时系统会首先通知所有已注册的VEH处理器然后才去查找SEH过滤器链。关键特性VEH处理器可以决定是否处理这个异常。如果返回EXCEPTION_CONTINUE_EXECUTION异常会被认为已处理程序继续执行如果返回EXCEPTION_CONTINUE_SEARCH则系统继续按SEH链寻找处理程序。应用场景主要用于高级调试、内存访问监视、或实现一些非常底层的错误恢复机制。对于一般的应用程序错误处理应谨慎使用VEH因为不当的处理如盲目继续执行可能导致程序状态更加混乱。设计考量在追求“捕获所有”的体系中VEH可以作为一个“监控哨兵”。例如我们可以安装一个VEH处理器它不处理任何异常只是将所有第一次机会异常的类型和地址记录到日志中。这对于诊断那些被后续SEH处理掉、没有导致崩溃但可能预示潜在问题的“静默异常”非常有用。但切记VEH回调中应避免进行复杂的堆分配或调用可能不安全的CRT函数。2.4 第四层CRT错误处理与信号C运行时库CRT也有自己的错误报告机制主要针对一些严重的运行时错误。_set_invalid_parameter_handler当CRT函数检测到无效参数如传递NULL指针给一个不允许为NULL的参数时默认会调用_invalid_parameter并终止进程。通过设置自定义处理器我们可以接管这个行为记录错误并决定是否终止。_set_purecall_handler处理纯虚函数调用错误。signal函数可以处理一些传统的C信号如SIGABRT、SIGFPE等。在Windows上SIGFPE浮点异常有时可以通过信号处理器捕获但更可靠的方式仍是使用SEH。设计考量这一层是防止程序因CRT内部断言失败而突然退出的重要补充。在程序初始化时设置这些处理器将错误信息记录到日志并可能触发一个可控的关闭流程比直接弹出“Debug Assertion Failed!”对话框或静默退出要友好得多。体系总结一个健壮的应用程序应该将这四层机制有机结合。通常的实践是业务逻辑错误用C异常在main/WinMain和关键线程入口设置顶层的catch(std::exception)和SetUnhandledExceptionFilter在初始化时设置CRT错误处理器根据需要决定是否使用VEH进行深度监控。这样无论异常来自代码逻辑、硬件故障、还是运行时库我们都有相应的防线进行拦截和响应。3. 核心实现细节与关键代码剖析理解了架构我们来看看每一层具体怎么实现有哪些坑需要注意。3.1 编译选项的基石/EHa与/EHsc之争这是所有工作的前提。Visual C编译器提供了几个关键的异常处理模型选项/EHsc默认启用C异常处理并假设外部函数如C函数不会抛出C异常。它不会生成捕获硬件异常的代码。如果硬件异常发生它不会触发你的catch块而是直接走SEH路径或导致崩溃。/EHa启用C异常处理并允许捕获异步硬件和SEH异常。当发生访问违规等SEH异常时它会被转换为一个C异常类型为std::exception或其派生类不实际上它被转换为一个特殊的...捕获或_se_translator_function翻译的结果从而可以被catch(...)或特定的catch块捕获。如何选择如果你希望用try/catch来捕获像访问违规这样的错误必须使用/EHa。但这会带来轻微的性能开销和更大的代码体积因为编译器需要生成更复杂的栈展开代码来处理可能发生在任何位置的异步异常。对于大多数需要高健壮性的桌面或服务应用程序我推荐使用/EHa。对于性能极度敏感、且能确保不会发生此类错误的模块如经过严格验证的数学库可以考虑使用/EHsc。实操配置CMake示例:if(MSVC) # 为整个项目或特定目标添加 /EHa add_compile_options(/EHa) # 或者针对特定目标 # target_compile_options(my_app PRIVATE /EHa) endif()3.2 顶层未处理异常过滤器的实现这是整个异常处理体系的“安全网”。当异常未被任何处理程序捕获时SetUnhandledExceptionFilter注册的函数将被调用。#include windows.h #include DbgHelp.h // 用于生成MiniDump #include string #include fstream // 生成MiniDump文件的函数 bool GenerateMiniDump(EXCEPTION_POINTERS* exception_pointers) { wchar_t dump_path[MAX_PATH]; GetModuleFileNameW(nullptr, dump_path, MAX_PATH); wcsrchr(dump_path, L\\)[1] L\0; // 去掉文件名只保留目录 wcscat_s(dump_path, LCrashDump.dmp); HANDLE hDumpFile CreateFileW(dump_path, GENERIC_WRITE, 0, nullptr, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, nullptr); if (hDumpFile INVALID_HANDLE_VALUE) return false; MINIDUMP_EXCEPTION_INFORMATION dump_info {0}; dump_info.ThreadId GetCurrentThreadId(); dump_info.ExceptionPointers exception_pointers; dump_info.ClientPointers FALSE; BOOL success MiniDumpWriteDump( GetCurrentProcess(), GetCurrentProcessId(), hDumpFile, MiniDumpWithDataSegs | MiniDumpWithHandleData | MiniDumpWithUnloadedModules, dump_info, nullptr, nullptr ); CloseHandle(hDumpFile); return success TRUE; } // 未处理异常过滤器函数 LONG WINAPI MyUnhandledExceptionFilter(EXCEPTION_POINTERS* exception_pointers) { // 1. 立即记录一些关键信息到文件因为后续操作可能不稳定 std::ofstream log(crash.log, std::ios::app); if (log) { log Fatal Exception std::endl; log Exception Code: 0x std::hex exception_pointers-ExceptionRecord-ExceptionCode std::endl; log Exception Address: 0x exception_pointers-ExceptionRecord-ExceptionAddress std::endl; log Time: __TIME__ __DATE__ std::endl; // 可以调用 SymFromAddr 等函数尝试解析符号需要提前初始化 DbgHelp log End std::endl std::endl; } // 2. 生成MiniDump文件这是最重要的 GenerateMiniDump(exception_pointers); // 3. 尝试执行一些紧急清理谨慎此时堆可能已损坏 // ... 例如关闭网络连接保存临时数据等。 // 4. 返回处理结果 // EXCEPTION_EXECUTE_HANDLER: 表示已处理系统将终止进程。 // EXCEPTION_CONTINUE_SEARCH: 继续搜索其他过滤器通常没有最终会弹出Windows错误报告。 // 通常我们选择终止进程并希望之前生成的Dump已被保存。 return EXCEPTION_EXECUTE_HANDLER; } // 在程序入口点main/WinMain开始处安装 int main() { // 设置未处理异常过滤器 SetUnhandledExceptionFilter(MyUnhandledExceptionFilter); // ... 你的程序逻辑 ... return 0; }关键点与避坑指南尽早安装必须在程序主要逻辑开始前尤其是任何可能产生异常的第三方库初始化之前调用SetUnhandledExceptionFilter。MiniDump是核心EXCEPTION_POINTERS包含了崩溃瞬间的线程上下文、异常记录等信息。MiniDumpWriteDump函数能将这些信息连同当时进程的内存状态保存到一个.dmp文件中。这个文件配合你的程序PDB符号文件可以在Visual Studio或WinDbg中重现崩溃现场是定位问题的终极武器。过滤器函数要简单可靠在异常过滤器中应假设堆内存可能已损坏避免复杂的C对象操作如std::string分配、调用可能依赖堆的库函数。优先使用栈变量和低级API如WriteFile。生成Dump和写入日志文件是相对安全的操作。注意“过滤器被重置”问题某些第三方库特别是某些旧版的CRT或图形库或系统组件可能会在内部调用SetUnhandledExceptionFilter(nullptr)清空你的过滤器。一个常见的应对方法是“过滤器钩子”定期例如在消息循环中检查并重新设置你的过滤器或者使用更底层的方法如VEH来确保最终控制权。3.3 使用_set_se_translator翻译SEH异常为C异常如果你使用了/EHa并且希望用C的try/catch语法来捕获和处理SEH异常可以使用_set_se_translator设置一个翻译函数。#include windows.h #include eh.h // 需要包含此头文件 // 自定义的SEH异常类 class seh_exception : public std::exception { public: seh_exception(unsigned int code, const char* context) : m_code(code), m_context(context) {} virtual const char* what() const noexcept override { // 注意这里返回静态字符串或使用 thread_local 存储避免分配内存 static thread_local char buffer[256]; sprintf_s(buffer, SEH Exception (0x%08X) at %s, m_code, m_context); return buffer; } unsigned int get_code() const { return m_code; } private: unsigned int m_code; const char* m_context; }; // SEH翻译函数 void seh_translator(unsigned int code, _EXCEPTION_POINTERS* info) { // 这里可以基于 info 获取更多上下文但注意异常安全 throw seh_exception(code, SEH translated); } int main() { // 设置翻译器 _set_se_translator(seh_translator); try { // 模拟一个访问违规 int* p nullptr; *p 42; // 这将触发SEH异常并被翻译器转换为抛出 seh_exception } catch (const seh_exception e) { std::cerr Caught SEH exception: e.what() std::endl; // 这里可以记录日志、尝试恢复等 // 注意在 catch 块中栈展开已经发生局部对象已析构。 } catch (const std::exception e) { // 处理其他C异常 } return 0; }注意事项翻译函数seh_translator本身是在异常上下文中被调用的应保持极其简单避免任何可能引发新异常的操作。抛出的是你自定义的异常对象。这让你可以用统一的C异常处理流程来处理硬件错误但必须清楚此时程序状态可能已经非常危险例如内存已损坏。catch块中的恢复操作需格外小心通常只适合记录日志和优雅退出不适合继续执行业务逻辑。这种方式只对使用/EHa编译的代码块有效。3.4 多线程环境下的异常处理策略异常处理是线程局部的。每个线程都有自己的未处理异常过滤器通过SetUnhandledExceptionFilter设置的是进程全局的但异常最终在触发异常的线程上下文中处理。关键策略线程入口点包装对于你创建的每一个工作线程都应该在其入口函数的最外层包裹一个try/catch块和/或__try/__except块以防止线程因未处理异常而静默退出导致主线程等待或资源泄漏。unsigned int __stdcall my_thread_func(void* param) { __try { try { // 实际的线程工作逻辑 do_work(param); } catch (const std::exception e) { // 记录线程内C异常 log_thread_error(e.what()); } } __except (MyUnhandledExceptionFilter(GetExceptionInformation()), EXCEPTION_EXECUTE_HANDLER) { // 这里调用了同一个过滤器生成Dump并终止线程 // 注意GetExceptionInformation() 是 __except 过滤器表达式中的特殊标识符 // 实际项目中可能需要一个线程安全的日志和Dump生成机制 return -1; // 线程异常退出码 } return 0; }资源清理确保在异常发生时线程持有的资源如锁、文件句柄、堆内存能被正确释放。利用RAII资源获取即初始化技术是C的最佳实践确保即使发生异常栈上局部对象的析构函数也会被调用从而释放资源。向主线程报告线程内捕获到异常后不应只是记录日志。通常需要通过线程安全的队列、Promise/Future或自定义事件机制将错误信息传递给主线程或监控线程以便进行统一的错误处理和用户通知。4. 高级话题与疑难杂症排查即使搭建了上述框架在实际项目中还是会遇到各种诡异的问题。这里分享几个典型案例和排查技巧。4.1 第三方库与异常规范的冲突许多C语言编写的库或某些保守的C库并不使用或兼容C异常。当你的代码使用/EHa调用这些库而库内部发生错误时情况会变得复杂。问题第三方库可能通过返回错误码、设置全局errno、调用abort()或直接触发SEH来报告错误。如果你的代码在调用库函数后继续运行可能会因为状态不一致而崩溃。对策仔细阅读文档了解第三方库的错误报告机制。封装隔离将第三方库的调用封装在独立的模块或类中。在封装接口处将库的错误机制转换为你项目统一的异常或错误码机制。使用__try/__except隔离对于已知可能触发严重SEH的库函数例如某些解析不可信输入的解码库可以将其调用放在__try块中在__except中将其转换为可控的错误。注意资源管理确保在异常发生时第三方库申请的资源能被正确释放。如果库提供了清理函数必须在__finally块或RAII包装器中调用。4.2 “无效参数”与纯虚函数调用处理这些错误由CRT内部抛出不通过标准的SEH或C异常路径。处理无效参数#include stdlib.h #include crtdbg.h void my_invalid_parameter_handler(const wchar_t* expression, const wchar_t* function, const wchar_t* file, unsigned int line, uintptr_t pReserved) { // 记录错误信息。注意这个处理器在错误发生时被调用此时程序通常即将终止。 // 应避免在此进行复杂操作。 LOG_ERROR(LInvalid parameter detected in %s. File: %s, Line: %d, function, file, line); // 如果想阻止CRT调用 abort()可以在这里 longjmp 或抛出异常如果环境允许但极不推荐。 // 通常的做法是记录并让程序终止。 } int main() { _set_invalid_parameter_handler(my_invalid_parameter_handler); // 在某些调试配置下还需要调用 _CrtSetReportMode 来抑制对话框 _CrtSetReportMode(_CRT_ASSERT, 0); // ... 其余代码 ... }处理纯虚函数调用#include stdlib.h void my_purecall_handler() { LOG_ERROR(Pure virtual function called!); // 同样这里程序状态已异常应尽快终止。 std::abort(); // 或触发一个自定义的严重错误流程 } int main() { _set_purecall_handler(my_purecall_handler); // ... 其余代码 ... }4.3 调试器附着与异常处理交互当你的程序在调试器如Visual Studio中运行时异常处理的行为会有所不同。第一次机会异常调试器会在任何异常处理程序包括VEH获得控制权之前先收到通知。你可以在Visual Studio的“异常设置”对话框中配置调试器是否在特定异常类型被抛出时中断。第二次机会异常如果异常没有被任何处理程序处理即未处理异常调试器会再次收到通知。这是你检查崩溃现场的最后机会。对过滤器的影响在调试器附着时SetUnhandledExceptionFilter注册的函数可能不会被调用因为调试器接管了未处理异常。这意味着你在调试时可能看不到生成Dump的流程。测试异常处理逻辑时需要同时测试“有调试器”和“无调试器”两种情况。4.4 生成高质量MiniDump的进阶技巧仅仅调用MiniDumpWriteDump生成Dump可能还不够。为了事后调试的便利我们需要更丰富的信息。包含完整内存信息使用MiniDumpWithFullMemory标志可以生成包含整个进程空间内存的Dump文件巨大但信息最全。折衷方案是使用MiniDumpWithDataSegs | MiniDumpWithHandleData | MiniDumpWithUnloadedModules | MiniDumpWithProcessThreadData这在大多数情况下足够。添加自定义信息可以使用MiniDumpCallback机制在生成Dump时向其中添加自定义数据流例如将程序当前的配置、日志片段、用户操作记录等嵌入Dump文件这对复现问题有极大帮助。符号文件PDB管理确保为发布版本生成并妥善保存PDB文件。PDB文件必须与对应的EXE/DLL版本严格匹配。建立一套自动化的构建符号服务器系统是大型项目的标配。Dump文件上传与分析可以集成像Google Breakpad或Microsoft Crash Reporting系统实现Dump文件的自动上传、符号化、聚合和分析极大提升线上问题的诊断效率。5. 实战构建一个完整的应用程序级异常防护框架理论说了这么多我们来看一个简化但完整的示例展示如何将这些点串联起来。假设我们有一个名为RobustApp的Windows桌面应用程序。第一步全局头文件定义异常类型和函数// RobustException.h #pragma once #include exception #include windows.h #include string namespace Robust { // 自定义异常类型 class SystemException : public std::exception { // ... 类似前面的 seh_exception包含错误码、地址等 }; // 初始化异常处理框架 void InitExceptionHandling(const std::wstring appName); // 设置线程的异常处理包装 void SetThreadExceptionHandler(); // 生成Dump的辅助函数 bool WriteMiniDump(EXCEPTION_POINTERS* pep, const std::wstring dumpPath); }第二步核心实现文件// RobustException.cpp #include RobustException.h #include DbgHelp.h #include iostream #include fstream #include sstream #include mutex #pragma comment(lib, DbgHelp.lib) namespace { std::wstring g_appName; std::mutex g_dumpMutex; // 防止多线程同时写Dump竞争 LONG WINAPI GlobalUnhandledExceptionFilter(EXCEPTION_POINTERS* pep) { std::lock_guardstd::mutex lock(g_dumpMutex); // 生成Dump文件名包含时间戳和进程ID SYSTEMTIME st; GetLocalTime(st); wchar_t dumpPath[MAX_PATH]; swprintf_s(dumpPath, L%s_Crash_%04d%02d%02d_%02d%02d%02d_%d.dmp, g_appName.c_str(), st.wYear, st.wMonth, st.wDay, st.wHour, st.wMinute, st.wSecond, GetCurrentProcessId()); // 写Dump if (Robust::WriteMiniDump(pep, dumpPath)) { std::wcerr LCrash dump saved to: dumpPath std::endl; } else { std::wcerr LFailed to save crash dump. std::endl; } // 可以在这里尝试同步刷新日志文件等简单清理操作 // ... // 让程序终止 return EXCEPTION_EXECUTE_HANDLER; } void InvalidParameterHandler(const wchar_t* expr, const wchar_t* func, const wchar_t* file, unsigned int line, uintptr_t) { std::wstringstream ss; ss LCRT Invalid Parameter: expr L\nFunction: func L\nFile: file L Line: line; OutputDebugStringW(ss.str().c_str()); // 输出到调试器即使发布版也可能有收集工具 // 触发一个自定义的异常或直接终止避免不可控状态 RaiseException(0xE0000001, 0, 0, nullptr); // 使用一个自定义的异常码会被我们的全局过滤器捕获 } void PureCallHandler() { OutputDebugStringW(LCRT Pure Virtual Function Called.\n); RaiseException(0xE0000002, 0, 0, nullptr); } } namespace Robust { void InitExceptionHandling(const std::wstring appName) { g_appName appName; // 1. 设置全局未处理异常过滤器 SetUnhandledExceptionFilter(GlobalUnhandledExceptionFilter); // 2. 设置CRT错误处理器 _set_invalid_parameter_handler(InvalidParameterHandler); _set_purecall_handler(PureCallHandler); // 可选禁用某些CRT断言对话框 _CrtSetReportMode(_CRT_ASSERT, 0); // 3. 初始化DbgHelp用于生成Dump和符号 SymSetOptions(SYMOPT_UNDNAME | SYMOPT_DEFERRED_LOADS | SYMOPT_LOAD_LINES); if (!SymInitialize(GetCurrentProcess(), nullptr, TRUE)) { std::wcerr LSymInitialize failed: GetLastError() std::endl; } // 4. 可选安装一个VEH用于监控第一次机会异常 // AddVectoredExceptionHandler(1, MyVectoredHandler); std::wcout LException handling framework initialized for appName std::endl; } bool WriteMiniDump(EXCEPTION_POINTERS* pep, const std::wstring dumpPath) { HANDLE hFile CreateFileW(dumpPath.c_str(), GENERIC_WRITE, 0, nullptr, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, nullptr); if (hFile INVALID_HANDLE_VALUE) return false; MINIDUMP_EXCEPTION_INFORMATION mdei {0}; mdei.ThreadId GetCurrentThreadId(); mdei.ExceptionPointers pep; mdei.ClientPointers FALSE; MINIDUMP_TYPE mdt static_castMINIDUMP_TYPE( MiniDumpWithDataSegs | MiniDumpWithHandleData | MiniDumpWithUnloadedModules | MiniDumpWithProcessThreadData | MiniDumpWithThreadInfo ); BOOL ok MiniDumpWriteDump(GetCurrentProcess(), GetCurrentProcessId(), hFile, mdt, (pep ! nullptr) ? mdei : nullptr, nullptr, nullptr); CloseHandle(hFile); return ok TRUE; } void SetThreadExceptionHandler() { // 每个线程可以调用此函数在其入口点设置线程特定的try-catch包装。 // 实际实现可能更复杂例如使用线程局部存储记录线程信息。 } }第三步应用程序入口点集成// main.cpp #include RobustException.h #include windows.h int WINAPI wWinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, PWSTR pCmdLine, int nCmdShow) { // 初始化异常处理框架必须是第一个初始化操作之一 Robust::InitExceptionHandling(LMyRobustApp); __try { try { // 你的应用程序初始化代码和主消息循环 return RunApplication(hInstance, pCmdLine, nCmdShow); } catch (const Robust::SystemException e) { // 处理我们自定义的系统异常 LOG_FATAL(System Exception: %s, e.what()); return -1; } catch (const std::exception e) { // 处理所有其他标准异常 LOG_FATAL(Standard Exception: %s, e.what()); return -1; } catch (...) { // 捕获所有未知异常应尽量避免到达这里 LOG_FATAL(Unknown exception caught in main.); return -1; } } __except (Robust::GlobalUnhandledExceptionFilter(GetExceptionInformation()), EXCEPTION_EXECUTE_HANDLER) { // 这个 __except 块实际上不会执行因为过滤器返回了 EXCEPTION_EXECUTE_HANDLER 导致进程终止。 // 但它保证了顶层SEH的语法完整性。 return -2; } }第四步工作线程包装示例// 在工作线程函数中使用RAII包装器和局部try-catch class ScopedThreadLogger { public: ScopedThreadLogger(const std::string threadName) : m_name(threadName) { LOG_INFO(Thread %s started., m_name.c_str()); } ~ScopedThreadLogger() { LOG_INFO(Thread %s exited., m_name.c_str()); } private: std::string m_name; }; unsigned int WorkerThread(void* data) { ScopedThreadLogger logger(Worker); __try { try { // 线程实际工作 while (!should_stop) { do_work_unit(); } } catch (const std::exception e) { LOG_ERROR(Worker thread caught exception: %s, e.what()); // 通过线程安全队列通知主线程 g_errorQueue.push(ThreadErrorInfo(m_name, e.what())); } } __except (EXCEPTION_EXECUTE_HANDLER) { // SEH异常记录并通知 LOG_CRITICAL(Worker thread fatal SEH.); g_errorQueue.push(ThreadErrorInfo(m_name, SEH)); return 1; // 非零退出码表示异常退出 } return 0; }这个框架提供了一个起点。在实际大型项目中你还需要考虑将Dump和日志上传到服务器、管理符号文件、处理来自不同DLL模块的异常确保它们使用相同的异常处理模型/EHa、以及在Final构建中平衡信息收集和性能开销。记住没有一种策略能捕获100%的异常但通过这样一套组合拳你能将那些“莫名其妙”的崩溃减少90%以上并将剩下的问题定位时间从数天缩短到数小时。