必须在程序启动时注册异常处理器并离线解析符号；setunhandledexceptionfilter需在main开头调用，多线程应使用addvectoredexceptionhandler；崩溃回调中禁用crt函数；minidumpwritedump需校验参数并确保pdb、二进制、dump三件套完整存档。
不能靠崩溃后手动操作来获取和解析 Minidump —— 必须在程序启动时注册异常处理器，且符号解析必须离线做、不能塞进异常回调里。
SetUnhandledExceptionFilter 必须在 main() 最开头调用
晚于任何全局对象构造或 CRT 初始化调用，就可能错过早期崩溃（比如静态变量初始化时的访问违规）。它只对当前线程生效，主线程设了，其他线程崩溃照样静默退出。
- 多线程场景下，要么每个线程入口都调用一次
SetUnhandledExceptionFilter，要么改用AddVectoredExceptionHandler(TRUE, ...)全局捕获 - 回调函数里严禁调用
malloc、new、printf、std::string构造等 CRT 函数，否则极易二次崩溃 - 不要依赖
atexit或 RAII 清理逻辑 —— 崩溃时这些根本不会执行
MiniDumpWriteDump 的参数陷阱特别多
MiniDumpWriteDump 返回 TRUE 只代表 API 调用成功，不代表文件写入磁盘。路径不存在、权限不足、磁盘满都会导致静默失败。
-
hProcess必须是GetCurrentProcess()，不能是继承来的句柄；ProcessId必须匹配，建议统一用GetCurrentProcessId() -
ExceptionParam中的ThreadId必须来自GetCurrentThreadId()，不能硬写 0 或 -1 -
DumpType推荐组合：MiniDumpWithIndirectlyReferencedMemory | MiniDumpWithThreadInfo | MiniDumpWithHandleData—— 比MiniDumpNormal多抓栈引用内存和句柄表，体积可控，排查 GDI/文件泄漏够用 - 漏掉
MiniDumpWithHandleData，分析句柄泄漏时就看不到!handle输出
符号解析不能在崩溃现场做
崩溃回调里加载 PDB、解析符号、调用 dbghelp 函数，等于在悬崖边跳舞。所有符号工作必须交给外部工具或独立进程完成。
- 生成 dump 后，把对应版本的
.exe、.dll和它们的.pdb文件一起打包存档 —— 缺任一文件，WinDbg Preview就会报*** ERROR: Module load failed: 0x80070002 - 本地调试时，用
.sympath+ srv*https://msdl.microsoft.com/download/symbols补微软公符；私有模块必须放本地路径，再用.sympath+ D:\myapp\symbols - 自动化解析推荐
minidump_stackwalk（Breakpad 工具链），但注意它不支持 Windows 原生MiniDumpWithFullMemory格式，只认 Breakpad 生成的 minidump
WinDbg Preview 是目前唯一靠谱的交互式分析工具
VS 自带调试器对 dump 支持弱，尤其遇到多线程死锁或堆损坏时，常卡在“正在加载符号”或直接无响应。
- 用
!analyze -v看根因，但前提是符号路径正确；若提示Unable to load image xxx.dll，先.reload /f xxx.dll强制重载 - 主线程停在
ntdll!NtWaitForMultipleObjects？马上执行~*k查所有线程栈，找谁在等谁 - 怀疑堆破坏？用
!heap -p -a <address></address>查分配上下文，但需要MiniDumpWithFullMemory或至少MiniDumpWithIndirectlyReferencedMemory
真正麻烦的不是生成 dump，而是确保每次构建都保留精确匹配的 PDB + 二进制 + dump 三件套。少一个，分析就断链。别信“我本地有源码就能推出来”的想法 —— 优化、内联、ASLR 都会让地址对不上。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
