记一次有教益的内存碎片转储文件分析经历

前言

其实，这篇文章早在 2021 年就完成了初稿，后面一直没来得及完善（各种加班各种忙），所以一直没来得及整理发布。而且，我从这个案例里学到的东西太多了，很多内容并没有体现在本篇文章中，后续有机会一定会再写文章分享。话不多说，一起来看正文吧。

缘起

前一阵子，有朋友在微信上发了一段 windbg 的输出信息，大概内容如下：

This dump file has an exception of interest stored in it. The stored exception information can be accessed via .ecxr. (fd0.9bc): Security check failure or stack buffer overrun - code c0000409 (first/second chance not available) For analysis of this file, run !analyze -v

... 省略 N 行

看样子像栈相关的问题。于是简单跟朋友说了下我的猜想，有可能是栈破坏了。没想到，远不是这么简单。

说明： 之所以一定要写这篇总结，是因为我在分析过程中犯了很多想当然的错误，记录下来，以后不要再犯。

另有隐情

过了一会，朋友发了一段更贴近真相的错误提示，并且发送了更详细的语音描述。

FAILURE_ID_HASH_STRING: um:fail_fast_fatal_app_exit_c0000409_server.exe!std::_xbad_alloc

这个提示跟最开始的提示风马牛不相及。一个是栈相关的问题，一个是内存分配的问题。

说明： 经常分析转储文件的小伙伴儿应该都知道，直接打开转储文件时，windbg 给出的提示有可能是不准确的，如果想获取最准确的信息，最好通过 .cxr 切换上下文，然后再执行 k 系列命令查看。但是，很多时候直接执行 !analayze -v 就能拿到正确信息。正式分析之前，不妨先试试 !analyze -v。

又跟朋友又聊了几个相关问题，得到了更多的关键信息。比如，

• 之前解决过类似的内存泄漏问题，当时抓的 dump 有 3GB 多。

• 这次抓取的 dump 只有 905MB，但是确实是 full dump。

  说明： 内存相关问题，最好抓一个 full dump，否则分析到一半，由于转储文件缺少关键信息，没法继续确认，就太尴尬了。

• 程序是 32 位的，并且开启了大地址。

  说明： 64 位程序的虚拟地址空间比 32 位程序大多了，不太容易在短时间内看出问题。

• 前几次出问题时都是运行了很久才出问题，这次只运行了 7 个小时左右就出问题了。

• 几次出问题时，都是在内存比较紧张的时候。

聊了一会，问朋友是否方便发送完整的 !analyze -v 结果。没想到，朋友除了发送 !analyze -v 的分析结果外，还特别贴心的发送了 转储文件和对应的符号文件。必须为朋友点赞，看来没少分析转储文件。

查看分析结果

由于当时在北京出差的路上，于是在地铁里用手机查看了一下 !analyze -v 的分析结果（旁边的小哥哥小姐姐会不会以为我在看小说？），跟朋友说的一样，打开转储文件后，windbg 给出的错误提示确实是栈相关的，但是 !analyze -v 却指向了内存分配相关的问题。

这里简单摘录几个关键的信息：

1. 转储文件中的 comment

Comment: '
*** "D:\software\Procdump_installer\procdump.exe" -accepteula -ma -j "D:\software\Procdump_installer\dumps" 4048 384 00990000
*** Just-In-Time debugger. PID: 4048 Event Handle: 384 JIT Context: .jdinfo 0x990000'

说明此 dump 是注册为 JIT debugger 的 procdump 在程序异常的时候抓取的。

1. 运行环境

Windows 10 Version 14393 MP (2 procs) Free x86 compa