在 Windows 平台上，dbghelp（配合 MiniDump）和 ASAN（AddressSanitizer）是两种定位崩溃/内存问题的思路，它们的工作阶段、检测原理和适用场景有本质区别。
核心差异
| 维度 | dbghelp（MiniDump） | ASAN（AddressSanitizer） |
|---|---|---|
| 检测阶段 | 事后分析（Post-mortem） | 运行时实时检测（Runtime） |
| 核心原理 | 崩溃后生成内存快照（.dmp），用 WinDbg 离线分析 | 编译器插桩 + 影子内存，在非法访问发生时立即拦截 |
| 触发条件 | 程序已经崩溃（未处理异常） | 程序运行过程中发生非法内存访问 |
| 依赖 | dbghelp.dll + PDB 符号文件 | 编译时加/fsanitize=address，链接 ASAN 运行时库 |
dbghelp 方式：事后"法医鉴定"
工作原理
1、程序通过 SetUnhandledExceptionFilter 注册全局异常处理器。
2、当程序崩溃（如空指针解引用、栈溢出等）时，系统触发异常，回调函数调用 MiniDumpWriteDump 将进程的关键状态写入 .dmp 文件。
3、开发者用 WinDbg 或 Visual Studio 打开 dump 文件，配合 PDB 符号文件，通过 !analyze -v、kb、kv 等命令还原崩溃时的调用栈、寄存器状态和异常信息。
能定位的问题
空指针解引用、非法地址访问
整数除零、栈溢出等硬件异常
崩溃点的完整函数调用链（精确到源码行号）
局限性
只能捕获"已崩溃"的问题：如果程序存在内存越界但没有立即崩溃（如写入了"malloc slop"区域），dbghelp 无法感知。
无法检测"静默"内存错误：use-after-free、堆溢出等如果不立即触发异常，dump 中不会体现。
分析依赖符号文件：缺少 PDB 文件时，只能看到裸地址，无法还原函数名和行号。
ASAN 方式：运行时"实时监控"
工作原理
1、编译时通过 /fsanitize=address（MSVC）或 -fsanitize=address（Clang/GCC）启用，编译器在每次内存读写前插入检查代码。
2、运行时库接管 malloc/free/new/delete，在分配内存前后插入红区（Redzone），并标记为"中毒"（不可访问）。
3、通过影子内存（Shadow Memory）机制，用 1 字节映射 8 字节应用内存，快速判断目标地址是否合法。一旦访问中毒区域，立即终止程序并输出详细报告。
能定位的问题
堆缓冲区溢出（heap-buffer-overflow）
栈缓冲区溢出（stack-buffer-overflow）
Use-After-Free（释放后使用）
全局变量越界
双重释放（double-free）
内存泄漏（需配合 LeakSanitizer）
局限性
性能开销大：内存开销约 2 倍，运行时性能下降 2~3 倍，不适合生产环境。
不检测未初始化内存读取（需要 UBSan 补充）。
不检测多线程数据竞争（需要 TSan 补充）。
Windows 上 ASAN 支持相比 Linux 稍晚成熟，部分场景可能存在兼容性问题。
对比总结
| 对比项 | dbghelp | ASAN |
|---|---|---|
| 何时生效 | 程序崩溃之后 | 程序运行期间 |
| 检测范围 | 仅能捕获导致崩溃的异常 | 能捕获"未崩溃"的内存错误 |
| 错误报告 | 需要离线用 WinDbg 分析 dump | 运行时直接输出到控制台，含源码行号 |
| 性能影响 | 几乎为零（仅在崩溃时写 dump） | 2~3 倍运行时开销 |
| 适用阶段 | 生产环境 + 测试环境 | 仅测试/开发环境 |
| 典型场景 | 线上服务偶发崩溃，无法复现 | 开发阶段全面扫描内存安全问题 |
实践方案
两者并非替代关系，而是互补关系：
1、开发/测试阶段：优先启用 ASAN，主动发现潜在的内存越界、use-after-free 等"定时炸弹"，把问题消灭在崩溃之前。
2、生产/线上环境：部署 dbghelp 方案（注册 SetUnhandledExceptionFilter + MiniDumpWriteDump），确保程序万一崩溃时能留下完整的现场信息，供事后分析。