应通过事件查看器→Windows日志→应用程序筛选错误/警告事件，依据事件ID（如1000）、来源（Application Error）、错误模块名（如VCRUNTIME140.dll）及异常代码（如0xc0000005）定位C++多线程崩溃根源。
用Windows事件查看器捕获C++多线程崩溃原始日志
Win10下C++多线程程序闪退，往往不弹错误框、不留dump，但系统一定记了——关键在eventvwr.msc里。别依赖程序自己写log，Windows内核会在崩溃瞬间把堆栈快照、异常代码、线程ID、模块路径全塞进系统日志。
操作步骤很简单：
– 按 Win + R，输入 eventvwr.msc 回车
– 左侧展开「Windows 日志 → 应用程序」
– 右侧点「筛选当前日志」，勾选「错误」和「警告」
– 找「来源」为 Application Error 的条目，双击打开，重点看「事件数据」里的 Exception Code（如 0xc0000005 表示访问违例）和 Module Name（比如 myapp.exe 或某个DLL）
注意：如果程序用了 /MD 链接运行时，崩溃常关联到 VCRUNTIME140.dll 或 MSVCP140.dll；若看到模块名是这些，说明不是你代码逻辑问题，而是运行库加载或初始化失败。
用WerFault生成用户模式dump文件
默认情况下，Win10对用户态崩溃只记录日志，不保存内存镜像。要拿到可调试的 .dmp 文件，得手动开启WER（Windows Error Reporting）自动转储功能。
执行以下命令（管理员权限的CMD）：reg add "HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps" /v DumpType /t REG_DWORD /d 2 /freg add "HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps" /v DumpFolder /t REG_SZ /d "C:\dumps" /f
立即学习“C++免费学习笔记（深入）”；
然后创建目录：mkdir C:\dumps
下次闪退后，C:\dumps 下会出现以进程名命名的 .dmp 文件。用Visual Studio或WinDbg打开，!analyze -v 就能定位到具体哪条线程、哪个函数、哪行代码触发了异常（比如 std::thread 构造时未join、std::mutex 被重复unlock）。
常见坑：
– 如果程序以服务方式运行，WER默认不捕获，需额外配置 LocalDumps 的 CustomDumpFlags
– /MT 静态链接运行时的程序，dump里看不到 VCRUNTIME140.dll，但可能暴露CRT内部锁竞争问题
在代码里加SetUnhandledExceptionFilter兜底
事件日志和WER dump 是被动捕获，有时来不及写入就进程退出。最可靠的方式，是在程序启动时注册自己的异常处理器：
LONG WINAPI MyCrashHandler(EXCEPTION_POINTERS* pExceptionInfo) {
// 写入自定义日志，比如线程ID、异常地址、调用栈（可用CaptureStackBackTrace）
// 然后强制生成mini dump：MiniDumpWriteDump(...)
return EXCEPTION_EXECUTE_HANDLER;
}
// 主函数开头调用：
SetUnhandledExceptionFilter(MyCrashHandler);这个函数能捕获所有未处理的SEH异常，包括多线程环境下的 0xc0000005、0xc0000409（栈溢出）、0xc0000374（堆损坏）。但要注意：
– 必须在主线程调用，且早于任何 std::thread 创建
– 不要在这个回调里调用 printf、std::cout 或任何可能分配堆内存的函数，否则二次崩溃
– 如果用了 boost::thread 或第三方线程库，需确认其是否屏蔽了SEH传播
为什么多线程闪退特别难复现
根本原因不是“随机”，而是竞态条件（race condition）和未定义行为（UB）在不同调度顺序下触发点不同。比如：
– 两个线程同时对同一个 std::shared_ptr 调用 reset()，可能破坏引用计数器
– std::condition_variable::wait() 前没加 std::unique_lock，或锁对象生命周期短于wait调用
– 使用 std::async 返回的 std::future 未调用 get() 或 wait()，析构时抛异常却未捕获
这类问题在日志里通常只显示 0xc0000005 或 0xc0000409，看不出上下文。必须配合dump里的线程栈+源码符号文件（.pdb）才能确认。没有符号文件的dump，连函数名都看不到，只剩一堆地址。
