一：背景1. 讲故事

昨天有位朋友找到我，说他的程序内存存在泄露导致系统特别卡，大地址也开了，让我帮忙看一下怎么回事？今天上午看了下dump，感觉挺有意思，在我的分析之旅中此类问题也蛮少见，算是完善一下体系吧。

二：WinDbg 分析1. 到底是哪里的泄露

在.NET高级调试训练营中，我多次告诉学员们，在分析此类问题时一定要搞清楚是托管还是非托管的问题，否则就南辕北辙啦，接下来使用 !address -summary观察下内存段。

0:000:x86> !address -summary--- Usage Summary ---------------- RgnCount ----------- Total Size -------- %ofBusy %ofTotal                             17673          cd777000 (   3.210 GB)  83.76%   80.26%Image                                  3087          1c14c000 ( 449.297 MB)  11.45%   10.97%Free                                   1418           aae6000 ( 170.898 MB)            4.17%Heap32                                   11           6ee0000 ( 110.875 MB)   2.82%    2.71%Stack32                                 186           39c0000 (  57.750 MB)   1.47%    1.41%Stack64                                 186            f80000 (  15.500 MB)   0.39%    0.38%Other                                    24            1da000 (   1.852 MB)   0.05%    0.05%Heap64                                    4            190000 (   1.562 MB)   0.04%    0.04%TEB64                                    62             7c000 ( 496.000 kB)   0.01%    0.01%TEB32                                    62             3e000 ( 248.000 kB)   0.01%    0.01%Other32                                   1              1000 (   4.000 kB)   0.00%    0.00%PEB64                                     1              1000 (   4.000 kB)   0.00%    0.00%PEB32                                     1              1000 (   4.000 kB)   0.00%    0.00%--- Type Summary (for busy) ------ RgnCount ----------- Total Size -------- %ofBusy %ofTotalMEM_PRIVATE                           16566          be8c2000 (   2.977 GB)  77.67%   74.43%MEM_IMAGE                              4210          245be000 ( 581.742 MB)  14.82%   14.20%MEM_MAPPED                              421          12403000 ( 292.012 MB)   7.44%    7.13%--- State Summary ---------------- RgnCount ----------- Total Size -------- %ofBusy %ofTotalMEM_COMMIT                            18901          e2904000 (   3.540 GB)  92.36%   88.50%MEM_RESERVE                            2296          1297f000 ( 297.496 MB)   7.58%    7.26%MEM_FREE                               1519           ad6d000 ( 173.426 MB)            4.23%

仔细观察卦中信息：可以看到总的提交内存 MEM_COMMIT = 3.5G都被 =3.2G这块给吃掉了，这表示当前是一个赤裸裸的 非托管内存泄露，是某种代码通过 VirtualAlloc这种方式直取 Windows内存管理器内存，既然能用上 VirtualAlloc肯定就不是业务程序员造成的，要想洞察 VirtualAlloc的调用栈除了对程序安插监控和挂钩子，其余也没什么好办法了，仅仅从现有的 dump 中观察其实很难。

【资料图】

2. 真的没有希望吗

既然不知道是谁分配的，我们只能观察事发现场，或许能从内存现场中找到点答案，那怎么找事发现场呢？熟悉 Windows内存管理的朋友都知道，要想分配内存，首先要在 虚拟地址上分配一个内存段，然后将我们的数据放在内存段中的内存页上，所以思路就是找到所有 COMMIT的 SEGMENT 即可，使用 !address -f:Unk,MEM_COMMIT观察所有 Unk的提交内存段。

0:000:x86> !address  BaseAddr EndAddr+1 RgnSize     Type       State                 Protect             Usage-----------------------------------------------------------------------------------------------79530000 79550000    20000 MEM_PRIVATE MEM_COMMIT  PAGE_READWRITE                       [................]79550000 79570000    20000 MEM_PRIVATE MEM_COMMIT  PAGE_READWRITE                       [................]79580000 795a0000    20000 MEM_PRIVATE MEM_COMMIT  PAGE_READWRITE                       [NatK............]795a0000 795c0000    20000 MEM_PRIVATE MEM_COMMIT  PAGE_READWRITE                       [........d.......]795c0000 795e0000    20000 MEM_PRIVATE MEM_COMMIT  PAGE_READWRITE                       [................]79620000 79640000    20000 MEM_PRIVATE MEM_COMMIT  PAGE_READWRITE                       [................]79640000 79660000    20000 MEM_PRIVATE MEM_COMMIT  PAGE_READWRITE                       [................]79660000 79680000    20000 MEM_PRIVATE MEM_COMMIT  PAGE_READWRITE                       [................]79690000 796b0000    20000 MEM_PRIVATE MEM_COMMIT  PAGE_READWRITE                       [................]796c0000 796e0000    20000 MEM_PRIVATE MEM_COMMIT  PAGE_READWRITE                       [..d.i.v...c.l.a.]796e0000 79700000    20000 MEM_PRIVATE MEM_COMMIT  PAGE_READWRITE                       [t...p.r.o.t.o.t.]79700000 79720000    20000 MEM_PRIVATE MEM_COMMIT  PAGE_READWRITE                       [t...p.r.o.t.o.t.]79720000 79740000    20000 MEM_PRIVATE MEM_COMMIT  PAGE_READWRITE                       [........8..z....]79740000 79760000    20000 MEM_PRIVATE MEM_COMMIT  PAGE_READWRITE                       [................]79760000 79780000    20000 MEM_PRIVATE MEM_COMMIT  PAGE_READWRITE                       [........d.......]79780000 797a0000    20000 MEM_PRIVATE MEM_COMMIT  PAGE_READWRITE                       [.....OP...vy....]797a0000 797c0000    20000 MEM_PRIVATE MEM_COMMIT  PAGE_READWRITE                       [................]797c0000 797c1000     1000 MEM_PRIVATE MEM_COMMIT  PAGE_EXECUTE                         [U...E.....H..E.P]797c1000 797e0000    1f000 MEM_PRIVATE MEM_COMMIT  PAGE_READWRITE                       [................]797e0000 797e1000     1000 MEM_PRIVATE MEM_COMMIT  PAGE_EXECUTE                         [U...E.....H..E.P]797e1000 79800000    1f000 MEM_PRIVATE MEM_COMMIT  PAGE_READWRITE                       [................]...

卦中信息太多了，刷了好久才刷完，Break 之后观察内存段，发现 RgnSize = 20000的段貌似要多一些，为了发现 0x20000的size到底有多少，这里需要写一段脚本进行统计，截图如下：

从卦中看 128k的内存段个数就占用了 9000+，应该是什么东西分配了内存但没有合理释放。

由于没有给程序装监控，只能看内存段的地址上的内容了，这里使用 windbg 自带的 .writemem命令将内存写到文件中观察，简单观察之后，发现里面有很多的 js 代码以及 html，比如下面的 PopupCalendar方法，截图如下：

3. 继续乘胜追击

既然抽到的几个内存段有这些 网页内容，但不见得大部分内存段都有这些内容，那怎么去验证呢？可以使用 s搜索内存去求证一下，比如我全内存搜索包含 PopupCalendar的内存段有多少。

0:000:x86> s-a 0 L?0xffffffff "PopupCalendar"08a4ed7c  50 6f 70 75 70 43 61 6c-65 6e 64 61 72 53 74 79  PopupCalendarSty096f8fa3  50 6f 70 75 70 43 61 6c-65 6e 64 61 72 28 22 6f  PopupCalendar("o096f9026  50 6f 70 75 70 43 61 6c-65 6e 64 61 72 28 22 6f  PopupCalendar("o096ff5bb  50 6f 70 75 70 43 61 6c-65 6e 64 61 72 28 22 6f  PopupCalendar("o096ff63e  50 6f 70 75 70 43 61 6c-65 6e 64 61 72 28 22 6f  PopupCalendar("o...f5fec996  50 6f 70 75 70 43 61 6c-65 6e 64 61 72 28 22 6f  PopupCalendar("of5ff2f2b  50 6f 70 75 70 43 61 6c-65 6e 64 61 72 28 22 6f  PopupCalendar("of5ff2fae  50 6f 70 75 70 43 61 6c-65 6e 64 61 72 28 22 6f  PopupCalendar("of5ff9543  50 6f 70 75 70 43 61 6c-65 6e 64 61 72 28 22 6f  PopupCalendar("of5ff95c6  50 6f 70 75 70 43 61 6c-65 6e 64 61 72 28 22 6f  PopupCalendar("o

从内存地址看：PopupCalendar从虚拟地址开头的 08a4ed7c到虚拟地址快结束的 f5ff95c6都遍布着这样的字符，而且高达 1532处，这也就说明当前非托管内存中有大量的 html页面被分配，但没有被释放，这也就是问题所在。

有了这些信息后接下来就找朋友反馈，为什么非托管内存中有这么多的 html 页面，是不是在 WPF 中不合理的使用了什么 浏览器引擎，分配之后未合理释放导致的泄露？

三：总结

这次事故应该是第三方组件在使用 html 的方式上造成的泄露，把包围圈缩小到这里相信朋友能很快的找到问题，验证问题。

PS：在 dump 中寻找非托管内存泄露其实很多时候都比较绝望，需要你对 Windows内存管理有一个比较深入的理解，还需要一个不骄不躁的分析心态。