Windows C++ 崩溃 dump 生成失败排查指南

简介：面向 C++ Windows 开发者的崩溃诊断代码示例，聚焦程序未捕获异常时的 dump 文件生成与故障定位需求，适合具备一定 C++ 和 Visual Studio 基础、希望补齐线上排错手段的中级开发者参考。压缩包仅含 1 个 cpp 源码文件，体积约 731B，内容围绕 MiniDumpWriteDump、dbghelp 头文件与库链接、异常过滤器及 SetUnhandledExceptionFilter 展开，并涉及转储级别选择、发布版调试信息配置等工程要点。已有 1629 人学习，该主题在 Windows 崩溃分析场景中具有实际参考价值。读者可从中理解从异常捕获到 dump 落盘的调用关系，掌握 dump 生成的关键 API 与配置思路，为后续借助 WinDbg 或 Visual Studio 分析堆栈、线程状态和内存快照打下基础。

1. 崩溃之后只剩一句“程序已停止工作”：为什么你的 C++ 进程没留下 dump

凌晨的电话响了，接到的是某个服务又挂了的消息。连上机器一看，事件查看器里只有一条 Windows 错误报告，日志里写着“应用程序发生异常”，然后什么都没有。这就是 Windows 上 C++ 程序崩溃最典型的样子：进程瞬间消失，调用栈、寄存器、各线程状态全被一起带走，能剩下的只有系统那句“程序已停止工作”。C++ 在 Windows 上生成 dump这件事本身不复杂，无非是用MiniDumpWriteDump把崩溃那一刻的内存状态按需落盘，但真上手之后会发现，权限、路径、位数、异常上下文、符号文件这几处只要错一个，dump 要么根本写不出来，要么写出来打不开、栈里全是问号。下面按报错顺序展开，适合正在给项目补崩溃捕获、或者被线上偶发崩溃折腾过的 Windows C++ 开发者照着排查。

2. MiniDumpWriteDump 返回 FALSE：四种 GetLastError 对应的真实原因

MiniDumpWriteDump的返回值只有 TRUE 和 FALSE，函数本身不告诉你失败在哪，唯一的信息源是紧随其后的GetLastError()。这里有个极易翻车的细节：GetLastError必须紧跟在调用之后取，中间哪怕插一句CloseHandle、一次日志输出、一个std::wstring拼接，错误码都可能被覆盖成别的值，排查方向直接跑偏。我一般会把错误码先存进局部变量，再去做收尾动作。

// 错误示范：CloseHandle 之后才取错误码，拿到的多半是 0 或别的值 BOOL ok = MiniDumpWriteDump(hProcess, pid, hFile, MiniDumpNormal, &mei, nullptr, nullptr); CloseHandle(hFile); DWORD err = GetLastError(); // 这里已经不可信了

正确写法是先把GetLastError()落下来，再SetLastError(err)还原回去，交给上层统一处理。

2.1 0x80070005 拒绝访问：先看文件是不是已经存在

5（ERROR_ACCESS_DENIED）是出现频率最高的一个。多数人第一反应是“权限不足”，跑去给程序加管理员权限，其实最常见的根因是目标.dmp文件已经存在并且被别的进程以不共享的方式打开着，或者被设置成了只读属性。MiniDumpWriteDump打开文件时如果用的是CREATE_NEW，那么第二次崩溃就永远写不进去；如果用CREATE_ALWAYS，遇到只读文件同样会失败。

// 用 CREATE_ALWAYS 覆盖旧文件，并且不共享句柄，避免自己挡住自己 HANDLE hFile = CreateFileW( path.c_str(), GENERIC_WRITE, 0, // 不共享：防止别的进程同时持有写句柄 nullptr, CREATE_ALWAYS, // 覆盖模式，比 CREATE_NEW 更适合崩溃转储 FILE_ATTRIBUTE_NORMAL, nullptr); if (hFile == INVALID_HANDLE_VALUE) { // 这一步的错误码才反映真实原因：5 拒绝访问 / 3 路径不存在 return GetLastError(); } MINIDUMP_EXCEPTION_INFORMATION mei{}; mei.ThreadId = GetCurrentThreadId(); mei.ExceptionPointers = pep; mei.ClientPointers = FALSE; // 进程内写自己，指针属于本进程地址空间 BOOL ok = MiniDumpWriteDump(GetCurrentProcess(), GetCurrentProcessId(), hFile, MiniDumpWithDataSegs, &mei, nullptr, nullptr); DWORD err = GetLastError(); // 立刻取值 CloseHandle(hFile);

参数上还有两处容易写错。第一个是ClientPointers，进程内给自己写 dump 必须传FALSE，跨进程写别人的 dump 才传TRUE，传反了会出现“dump 能生成但异常上下文是空的”这种迷惑现象。第二个是hProcess和pid必须是同一个目标，曾经见过把GetCurrentProcess()配上一个从别处抄来的 pid，函数返回 FALSE 且错误码为 0，因为内部校验就过不去。

如果确认文件可写、目录也有权限，仍然返回 5，那就往安全软件方向查：部分 EDR 会拦截对.dmp扩展名的写入，或者扫描时短暂锁住刚创建的空文件，于是你的程序拿到的就是拒绝访问。

2.2 0x80070003 找不到路径：相对路径与宽窄字符混用

3（ERROR_PATH_NOT_FOUND）和2（ERROR_FILE_NOT_FOUND）经常成对出现，本质都是路径拼错了。崩溃现场和正常运行时的环境不一样：进程的当前工作目录可能已经被SetCurrentDirectory改过，可能是个网络映射盘已经断开，也可能因为崩溃发生在一个临时目录里，相对路径".\\crash.dmp"就落到了一个你根本找不到的地方。

稳妥做法是用绝对路径，基准目录取 exe 自身所在目录或者%ProgramData%，绝不用 CWD。

// 以 exe 所在目录为基准拼绝对路径，避免 CWD 漂移 std::wstring GetDumpDir() { wchar_t exePath[MAX_PATH]{}; GetModuleFileNameW(nullptr, exePath, MAX_PATH); std::wstring dir(exePath); size_t pos = dir.find_last_of(L"\\/"); if (pos != std::wstring::npos) { dir = dir.substr(0, pos) + L"\\dumps"; } // 目录必须提前建好，CreateFile 不会替你递归创建父目录 CreateDirectoryW(dir.c_str(), nullptr); return dir; }

宽窄字符混用是另一个隐蔽的坑。项目里如果定义了UNICODE，CreateFile会展开成CreateFileW，而路径却来自一个std::string转换出来的临时std::wstring，中文目录名在转换过程中被截断或替换，最终就是一个不存在的路径。统一改成全程std::wstring，从GetModuleFileNameW一路传到CreateFileW，能省掉大量排查时间。另外 Windows 默认单路径上限 260 个字符，超长路径需要在前面加\\?\前缀，否则同样报路径不存在。

2.3 299 ERROR_PARTIAL_COPY：位数不匹配与目标进程已退出

299（ERROR_PARTIAL_COPY）看起来像内存读取失败，实际上最常见的原因有两个：写 dump 的进程位数低于目标进程，或者目标进程已经终止、栈被回收。

第一条经常被忽略：用 32 位进程去给 64 位进程调MiniDumpWriteDump，读不到完整的 64 位线程上下文，函数就会以 299 收场。反过来 64 位给 32 位写是可行的。所以线上方案要按目标进程的实际位数部署对应位数的写 dump 组件，服务端进程是 64 位，就别让 32 位的守护程序去抓。

第二条是时序问题。崩溃处理函数执行期间，其他线程还在跑，一旦它们把栈上的数据覆盖掉，dbghelp 去抓上下文时就会读到半截数据。常见做法是在写之前先把崩溃线程挂起。

// 跨进程写 dump：先挂起目标线程，再抓上下文，最后恢复 BOOL DumpOnBehalf(HANDLE hProcess, DWORD pid, DWORD tid, EXCEPTION_POINTERS* pep) { HANDLE hThread = OpenThread(THREAD_SUSPEND_RESUME, FALSE, tid); if (hThread) SuspendThread(hThread); HANDLE hFile = CreateFileW(L"D:\\dumps\\remote.dmp", GENERIC_WRITE, 0, nullptr, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, nullptr); if (hFile == INVALID_HANDLE_VALUE) { if (hThread) { ResumeThread(hThread); CloseHandle(hThread); } return FALSE; } MINIDUMP_EXCEPTION_INFORMATION mei{}; mei.ThreadId = tid; mei.ExceptionPointers = pep; // 指向目标进程地址空间里的异常记录 mei.ClientPointers = TRUE; // 跨进程写必须是 TRUE BOOL ok = MiniDumpWriteDump(hProcess, pid, hFile, static_cast<MINIDUMP_TYPE>(MiniDumpWithFullMemory | MiniDumpWithThreadInfo), pep ? &mei : nullptr, nullptr, nullptr); CloseHandle(hFile); if (hThread) { ResumeThread(hThread); CloseHandle(hThread); } return ok; }

还有一种是目标进程句柄拿到了、但进程刚好处于退出流程中，hProcess还在，内存已经不可读。判断办法很简单：写之前用WaitForSingleObject(hProcess, 0)探一下，返回WAIT_OBJECT_0就说明已经没了，别白费力气。

2.4 链接期就翻车：dbghelp.lib 与头文件顺序

有人根本走不到运行期，编译链接阶段就报：

error LNK2019: 无法解析的外部符号 __imp_MiniDumpWriteDump，该符号在函数 ... error LNK2001: 无法解析的外部符号 __imp_MiniDumpWriteDump

原因只有两个。要么是没链接dbghelp.lib，项目属性里“附加依赖项”漏了，或者 x86/x64 两套库路径配错；要么是头文件包含顺序不对，DbgHelp.h依赖Windows.h里的一批基础类型，放在前面会连锁报一堆类型未定义的错误。

// 顺序不能换：windows.h 在前，DbgHelp.h 在后 #include <windows.h> #include <DbgHelp.h> #pragma comment(lib, "dbghelp.lib") // 如果项目里用了 WIN32_LEAN_AND_MEAN，DbgHelp.h 仍能正常编译， // 但会缺少一部分调试相关声明，按需在包含前取消该宏

还有一个运行期版本坑：系统目录里的dbghelp.dll版本可能偏旧，对MiniDumpWithThreadInfo这类较新的类型直接返回ERROR_INVALID_PARAMETER（87），表现为“参数看着都对，就是返回 FALSE”。解决办法是把新版dbghelp.dll放到 exe 同目录，用自带的那份，而不是系统目录里的。这个坑没有明显报错，只能靠错误码 87 反推。

3. dump 生成了但打开是空的：异常上下文、dump 类型与符号

文件写出来了，几百 KB 摆在那，拖进 WinDbg 一看：只有一个线程，异常信息里写着“没有可用的异常记录”，栈上全是模块名加偏移。这时候问题已经不在“能不能写”，而在“写了什么”。下面是三类最常见的“空壳 dump”。

3.1 异常指针的生命周期：别把 EXCEPTION_POINTERS 存到队列里

SetUnhandledExceptionFilter注册的回调里拿到的EXCEPTION_POINTERS*，以及它指向的CONTEXT、EXCEPTION_RECORD，只在本次回调执行期间有效。很多项目为了“不阻塞崩溃流程”，把指针塞进一个无锁队列，交给另一个线程慢慢写 dump。等那个线程真正开始写的时候，原线程早已终止，内存被回收，dbghelp 读到的是野指针，结果就是 dump 里没有异常上下文，栈也断在半截。

LONG WINAPI CrashFilter(EXCEPTION_POINTERS* pep) { // pep 只在本次回调内有效，必须同步写完，不能异步延后 std::wstring dir = GetDumpDir(); WriteDumpSync(GetCurrentProcess(), GetCurrentProcessId(), pep, dir); // EXCEPTION_EXECUTE_HANDLER：不再往上传，进入终止流程 // 若返回 EXCEPTION_CONTINUE_SEARCH，会继续交给系统错误报告处理 return EXCEPTION_EXECUTE_HANDLER; } int main() { // 尽早注册，且全进程只保留一个有效过滤器 SetUnhandledExceptionFilter(CrashFilter); // ... 业务代码 }

还要清楚它覆盖不到哪些情况：CRT 的terminate()、纯虚函数调用、栈溢出、堆管理器检测到的破坏，都可能绕过这个回调或者根本没机会执行。所以它是必要不充分，不能指望它兜住所有崩溃。

3.2 MINIDUMP_TYPE 怎么选：小 dump 为什么分析不出堆问题

类型选小了，dump 里只有线程栈和模块列表。栈上那些std::string、std::vector的对象只留一个地址，没有对应的内存内容，打开就是一堆无效指针，根本看不出业务数据长什么样。

类型标志	额外包含的内容	体积量级	适用场景
MiniDumpNormal	线程栈、模块列表、线程上下文	几十 KB 到几 MB	线上默认，只要能看出崩在哪个函数
MiniDumpWithDataSegs	全局变量、静态数据段	增加数 MB	需要看全局配置、单例状态
MiniDumpWithHandleData	进程句柄表	变化大	怀疑句柄泄漏、死锁
MiniDumpWithThreadInfo	线程时间、优先级、亲和性	很小	卡死、挂起类问题
MiniDumpWithUnloadedModules	已卸载模块的残留信息	很小	崩溃栈里出现未知模块
MiniDumpWithFullMemory	完整用户态内存	接近进程内存占用	堆破坏、难以复现的偶发崩溃

实践中的折中是双档策略：默认写MiniDumpWithDataSegs | MiniDumpWithThreadInfo，体积可控；对内存占用已知不大的进程（比如 200 MB 以内的客户端），直接上MiniDumpWithFullMemory，省得事后反复找用户要第二次。MINIDUMP_TYPE是位掩码，用|组合，也可以强转static_cast<MINIDUMP_TYPE>(...)把多个标志拼起来。

3.3 栈里全是问号：PDB 匹配与符号路径

打开 dump 看到这行，基本可以确定是符号问题：

*** ERROR: Symbol file could not be found. Defaulted to export symbols for xxx.exe

dump 里存的是模块基址加相对偏移，函数名和行号要靠 PDB 还原。没有 PDB 就只能显示xxx!SomeFunc+0x1a或者干脆只有模块名。另一个典型提示是WARNING: Stack unwind information not available，x86 程序在缺 PDB 时尤其容易出现，栈会直接断在中间某个帧。

排查顺序是这样的：

0:000> .sympath D:\symbols\MyApp 0:000> .reload /f 0:000> lm // 看目标模块有没有加载符号 0:000> !analyze -v // 让调试器给一次完整分析

.sympath指向本地归档的符号目录，.reload /f强制重载，lm输出的模块行首如果是(private pdb symbols)就说明符号对上了。生产上要做的是把每次发版的 exe 和 pdb 按版本号归档到固定目录，dump 文件旁边附一个版本号文本，事后拿 dump 时能直接找到对应符号。PDB 版本对不上会报Unable to verify checksum，看到这句就别再往下分析了，先换正确的 pdb。

3.4 进程自己写 dump 的并发问题：卡死与 0 字节

进程在崩溃处理里自己调MiniDumpWriteDump，会遇到一个不太好复现的问题：其他线程还活着，某个线程正好卡在加载器锁或者堆锁上，dbghelp 枚举模块、遍历线程时也在等同一把锁，于是双方互等，进程挂住不退出，dump 文件停在 0 字节。表现就是“程序没退出、也没有转储、任务管理器里能看到进程”。

两种绕过方式。一种是彻底交给系统：在注册表里配 WER 的 LocalDumps，崩溃时由系统进程写盘，完全不依赖你自己的代码，也不受进程内死锁影响。

:: 为指定进程配置本地转储：目录、类型（1=mini，2=full）、保留数量 reg add "HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\MyApp.exe" ^ /v DumpFolder /t REG_EXPAND_SZ /d "D:\dumps" /f reg add "HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\MyApp.exe" ^ /v DumpType /t REG_DWORD /d 1 /f reg add "HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\MyApp.exe" ^ /v DumpCount /t REG_DWORD /d 10 /f

DumpFolder必须是目标进程有写权限的目录，服务账户的配置目录和当前用户目录不是一回事；DumpCount控制保留份数，不设会一直堆到磁盘满。

另一种是起一个独立的 watchdog 进程，通过命名管道或者共享内存接收崩溃信号，再由它挂起目标、写 dump。这种方式能把进程内死锁的风险彻底挪出去，代价是多一个进程和一套通信协议。

4. 常见问题排查：dump 生成失败最容易被忽略的五个细节

下面是这些年踩出来、且很难靠搜索一次命中的五个具体问题，每个按现象、原因、解决三段展开。

4.1 文件是 0 字节：句柄建了，后半程失败了

现象：目录里能看到crash_1234.dmp，大小 0 KB，进程也已经退出。

原因：CreateFileW用CREATE_ALWAYS成功创建了空文件，随后的MiniDumpWriteDump返回 FALSE，但代码里只判断了前半段的文件句柄，没检查后半段的返回值，空文件就这么留下了。如果文件是通过 SMB 写网络盘，还有一种可能是写缓冲没来得及刷盘进程就终止了。

解决：把文件句柄和 dump 调用分开两次校验，任何一步失败都要记录GetLastError()；写完之后显式FlushFileBuffers(hFile)再关闭，尤其是目标目录在网络盘或者虚拟磁盘上。另外在写完之后用GetFileSizeEx校验一下大小，小于 1 KB 的直接当失败处理，别让假成功的文件混进收集流程。

4.2 崩溃处理里弹窗、写日志，然后二次崩溃

现象：本该生成 dump 的机器上什么也没有，WER 里能看到两条紧挨着的错误记录。

原因：崩溃回调里调用了业务日志组件、MessageBox、或者某个封装过的字符串格式化函数。崩溃发生时堆已经被破坏，这些调用内部再分配内存就会二次崩溃，第二次崩溃可能带着第一次的上下文一起被系统兜走。

解决：崩溃回调里只允许调用 Win32 API 和已预先分配好内存的代码路径，禁止malloc/new、禁止 C++ 异常、禁止字符串拼接。需要的路径、pid、时间戳全部提前算好放在全局静态缓冲区，回调里只做MiniDumpWriteDump和写一个定长结构。这条规则建议直接写进代码评审清单。

4.3 生产机上文件凭空消失，或始终写不出来

现象：本地开发机一切正常，部署到生产机器后DumpFolder里空空如也。

原因：两个方向。一是服务运行在受限账户下，你配置的目录（比如某个管理员用户目录）它没有写权限；二是安全软件把.dmp当作可疑文件隔离了，尤其是含完整内存的全量 dump，体积大、内容杂，触发规则的概率不低。

解决：把目录设为%ProgramData%下的独立子目录，部署脚本里显式授权给服务账户；同时把该目录和扩展名加入安全软件的白名单。验证方式是让程序在启动时先做一次“自检写盘”：写一个小文件、读回来、删除，失败就把错误码写进启动日志，比等崩溃时才发现要早得多。

4.4 全量 dump 撑爆磁盘，或者写得比崩溃还慢

现象：一次崩溃生成了好几个 GB 的文件，磁盘直接告警；或者写 dump 耗时几十秒，用户以为程序卡死强行结束进程。

原因：MiniDumpWithFullMemory会把整个用户态内存写下来，进程占用 2 GB 就是 2 GB 左右的转储；再加上盘上还留着历史文件，很快堆满。

解决：用DumpCount或者自己写清理逻辑控制份数；对内存占用大的进程改成两档策略，先写 mini dump，需要时再按进程名和版本号触发一次全量采集。写盘路径尽量避开系统盘，也别放在被杀毒软件实时扫描的目录里，否则耗时会被放大好几倍。

4.5 中文路径、超长路径下写不进去

现象：英文目录一切正常，换成带中文的安装目录就写不出来，错误码是 2 或 3。

原因：工程里混用了std::string和宽字符 API，路径在转换过程中编码丢失，或者路径长度超过 260 个字符没有加\\?\前缀。

解决：全链路改成std::wstring，从GetModuleFileNameW到CreateFileW不经过任何窄字符转换；路径超长时统一加前缀。写完在日志里打印最终使用的绝对路径，这条日志能省掉后面 80% 的“为什么文件找不到”的沟通。

5. 快速定位：拿到一个失败结果后先看哪三样东西

真到了排查现场，不要一上来就翻代码。我习惯按固定顺序看三样东西，基本能在五分钟内把范围缩到一两行。

第一步看错误码。拿到FALSE之后立刻取GetLastError()，对着表定位，比读代码快得多。

GetLastError	常量	先查什么
5	ERROR_ACCESS_DENIED	目标文件是否已存在且只读、目录权限、安全软件拦截
2 / 3	ERROR_FILE_NOT_FOUND / ERROR_PATH_NOT_FOUND	父目录是否已创建、是否用了相对路径、中文或超长路径
87	ERROR_INVALID_PARAMETER	MINIDUMP_TYPE 里是否含当前 dbghelp.dll 不支持的类型
299	ERROR_PARTIAL_COPY	写 dump 进程位数是否低于目标、目标是否已终止
0（返回 FALSE）	无	hProcess 与 pid 是否配套、句柄是否有效

第二步看文件本身。dir一下大小，0 字节说明调用失败了但没人检查返回；几百 KB 说明写成功了但类型选小了；几个 GB 说明开了全量内存。用十六进制编辑器看文件头前四个字节是不是MDMP，不是就说明这个文件根本不是 dump，多半是被别的东西占用了同名路径。

第三步看能不能分析。把 dump 和当次发版的 exe、pdb 放在同一目录，按前面的符号路径流程走一遍：

0:000> .sympath D:\symbols\MyApp 0:000> .reload /f 0:000> !analyze -v

!analyze -v的输出里重点看三段：FAULTING_IP指向崩溃指令地址，EXCEPTION_CODE是异常码（c0000005是访问违规，c00000fd是栈溢出，e06d7363是 C++ 异常没被捕获），STACK_TEXT是调用链。如果STACK_TEXT里出现大量Unknown，别急着怀疑业务代码，先回去确认 pdb 版本，这一步出错的概率远高于代码本身。

还有个小技巧：把“写 dump 失败”和“dump 分析失败”分成两条独立的监控指标，出问题时看是哪条先亮。前者说明捕获链路有问题，后者说明符号或类型选得不对，两件事的修法完全不同，混在一起排查只会来回打转。

从那以后我每次给新项目接崩溃捕获，都强制走一遍完整的验证清单：故意在测试用例里触发一次空指针、确认 dump 落盘、确认文件头是 MDMP、确认 pdb 能对上、确认!analyze -v能出栈。这五步里任何一步偷懒，线上就会用一次没有上下文的崩溃把时间还回来。希望帮到你。

本文还有配套的精品资源，点击获取