MiniDumpWriteDump需配合SetUnhandledExceptionFilter异常处理器调用才有效，其回调函数须为LONG WINAPI类型，参数DumpType建议用MiniDumpWithFullMemory以确保堆内存完整，且需配对符号文件（.pdb）方可调试。
MiniDumpWriteDump 函数怎么调用才有效
直接调用 MiniDumpWriteDump 本身不触发崩溃转储——它只是个“写入工具”，必须配合异常捕获机制才能在程序挂掉时自动保存 dump。最常用且可靠的方式是设置全局异常处理器：SetUnhandledExceptionFilter，并在其回调函数里调用 MiniDumpWriteDump。
关键点：
- 回调函数必须是
LONG WINAPI UnhandledExceptionFilter(EXCEPTION_POINTERS* pExceptionInfo)类型，不能省略WINAPI调用约定，否则栈会被破坏 -
MiniDumpWriteDump的第 5 个参数（MINIDUMP_TYPE）建议至少用MiniDumpWithFullMemory或MiniDumpWithIndirectlyReferencedMemory，否则堆上对象内容可能为空，调试时看不到变量值 - dump 文件路径必须可写，且目录已存在；用
GetTempPath+GetTempFileName比硬编码路径更稳妥
为什么 SetUnhandledExceptionFilter 在某些情况下失效
常见于使用了第三方库（如 Qt、.NET Core 嵌入、某些反作弊 SDK）或启用了 Windows 的“错误报告服务”（WER）时：SetUnhandledExceptionFilter 只能设置**顶层**异常处理器，而 WER 或其他 DLL 可能抢先注册并吞掉异常，导致你的回调根本不执行。
应对方式：
立即学习“C++免费学习笔记（深入）”；
- 在
main或WinMain开头立即调用SetUnhandledExceptionFilter，越早越好 - 补充设置结构化异常处理（SEH）：用
__try/__except包裹主逻辑（仅限 MSVC），捕获EXCEPTION_ACCESS_VIOLATION等硬件异常 - 对多线程程序，需额外为每个线程调用
SetThreadExceptionHandler（Windows 10 1607+），或在线程入口统一安装 SEH
生成的 MiniDump 打开后显示“no symbols loaded”怎么办
dump 文件本身不含符号信息，调试器（如 WinDbg、VS）需要匹配的 .pdb 文件才能解析调用栈和变量。不是 dump 没生成成功，而是调试环境没配好。
确保以下三点：
- 编译时开启生成调试信息：
/Zi（MSVC），链接时保留/DEBUG，且未启用/PDBALTPATH等干扰路径的选项 - dump 和
.pdb文件时间戳要一致（重编译后旧 dump 无法用新 pdb 解析） - 在 WinDbg 中手动设置符号路径：
.sympath+ C:\myapp\debug\，然后用.reload /f强制重载
若发布版本需调试，务必存档对应构建的 .exe、.pdb 和 dump 三者，缺一不可。
Release 版本崩溃但没触发 dump，可能是优化惹的祸
MSVC 的 /O2 或 /Ox 会内联函数、消除栈帧、合并变量，导致 EXCEPTION_POINTERS 中的 ContextRecord 无法准确还原调用栈，甚至让 MiniDumpWriteDump 写出的栈内存区域无效。
折中方案：
- 发布构建时改用
/O1（最小化大小）而非/O2，它保留帧指针（/Oy-默认启用），对性能影响小但显著提升 dump 可调试性 - 在关键模块（如消息循环、网络回调）加
__declspec(noinline)防止内联，确保栈上有清晰函数边界 - 避免在异常处理回调里做复杂操作（如弹窗、日志写磁盘），Release 下这些可能因优化引发二次崩溃
真正难调试的，往往不是 dump 没生成，而是生成了却看不出哪一行代码越界、哪个指针被释放后又用了——这得靠符号、栈完整性、还有你有没有在崩溃前把关键状态打到日志里。
