翼度科技»论坛 编程开发 .net 查看内容

记一次 .NET 某手术室行为信息系统 内存泄露分析

11

主题

11

帖子

33

积分

新手上路

Rank: 1

积分
33
一:背景

1. 讲故事

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

1. 到底是哪里的泄露

在.NET高级调试训练营中,我多次告诉学员们,在分析此类问题时一定要搞清楚是托管还是非托管的问题,否则就南辕北辙啦,接下来使用 !address -summary 观察下内存段。
  1. 0:000:x86> !address -summary
  2. --- Usage Summary ---------------- RgnCount ----------- Total Size -------- %ofBusy %ofTotal
  3. <unknown>                             17673          cd777000 (   3.210 GB)  83.76%   80.26%
  4. Image                                  3087          1c14c000 ( 449.297 MB)  11.45%   10.97%
  5. Free                                   1418           aae6000 ( 170.898 MB)            4.17%
  6. Heap32                                   11           6ee0000 ( 110.875 MB)   2.82%    2.71%
  7. Stack32                                 186           39c0000 (  57.750 MB)   1.47%    1.41%
  8. Stack64                                 186            f80000 (  15.500 MB)   0.39%    0.38%
  9. Other                                    24            1da000 (   1.852 MB)   0.05%    0.05%
  10. Heap64                                    4            190000 (   1.562 MB)   0.04%    0.04%
  11. TEB64                                    62             7c000 ( 496.000 kB)   0.01%    0.01%
  12. TEB32                                    62             3e000 ( 248.000 kB)   0.01%    0.01%
  13. Other32                                   1              1000 (   4.000 kB)   0.00%    0.00%
  14. PEB64                                     1              1000 (   4.000 kB)   0.00%    0.00%
  15. PEB32                                     1              1000 (   4.000 kB)   0.00%    0.00%
  16. --- Type Summary (for busy) ------ RgnCount ----------- Total Size -------- %ofBusy %ofTotal
  17. MEM_PRIVATE                           16566          be8c2000 (   2.977 GB)  77.67%   74.43%
  18. MEM_IMAGE                              4210          245be000 ( 581.742 MB)  14.82%   14.20%
  19. MEM_MAPPED                              421          12403000 ( 292.012 MB)   7.44%    7.13%
  20. --- State Summary ---------------- RgnCount ----------- Total Size -------- %ofBusy %ofTotal
  21. MEM_COMMIT                            18901          e2904000 (   3.540 GB)  92.36%   88.50%
  22. MEM_RESERVE                            2296          1297f000 ( 297.496 MB)   7.58%    7.26%
  23. 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 的提交内存段。
  1. 0:000:x86> !address
  2.   BaseAddr EndAddr+1 RgnSize     Type       State                 Protect             Usage
  3. -----------------------------------------------------------------------------------------------
  4. 79530000 79550000    20000 MEM_PRIVATE MEM_COMMIT  PAGE_READWRITE                     <unknown>  [................]
  5. 79550000 79570000    20000 MEM_PRIVATE MEM_COMMIT  PAGE_READWRITE                     <unknown>  [................]
  6. 79580000 795a0000    20000 MEM_PRIVATE MEM_COMMIT  PAGE_READWRITE                     <unknown>  [NatK............]
  7. 795a0000 795c0000    20000 MEM_PRIVATE MEM_COMMIT  PAGE_READWRITE                     <unknown>  [........d.......]
  8. 795c0000 795e0000    20000 MEM_PRIVATE MEM_COMMIT  PAGE_READWRITE                     <unknown>  [................]
  9. 79620000 79640000    20000 MEM_PRIVATE MEM_COMMIT  PAGE_READWRITE                     <unknown>  [................]
  10. 79640000 79660000    20000 MEM_PRIVATE MEM_COMMIT  PAGE_READWRITE                     <unknown>  [................]
  11. 79660000 79680000    20000 MEM_PRIVATE MEM_COMMIT  PAGE_READWRITE                     <unknown>  [................]
  12. 79690000 796b0000    20000 MEM_PRIVATE MEM_COMMIT  PAGE_READWRITE                     <unknown>  [................]
  13. 796c0000 796e0000    20000 MEM_PRIVATE MEM_COMMIT  PAGE_READWRITE                     <unknown>  [..d.i.v...c.l.a.]
  14. 796e0000 79700000    20000 MEM_PRIVATE MEM_COMMIT  PAGE_READWRITE                     <unknown>  [t...p.r.o.t.o.t.]
  15. 79700000 79720000    20000 MEM_PRIVATE MEM_COMMIT  PAGE_READWRITE                     <unknown>  [t...p.r.o.t.o.t.]
  16. 79720000 79740000    20000 MEM_PRIVATE MEM_COMMIT  PAGE_READWRITE                     <unknown>  [........8..z....]
  17. 79740000 79760000    20000 MEM_PRIVATE MEM_COMMIT  PAGE_READWRITE                     <unknown>  [................]
  18. 79760000 79780000    20000 MEM_PRIVATE MEM_COMMIT  PAGE_READWRITE                     <unknown>  [........d.......]
  19. 79780000 797a0000    20000 MEM_PRIVATE MEM_COMMIT  PAGE_READWRITE                     <unknown>  [.....OP...vy....]
  20. 797a0000 797c0000    20000 MEM_PRIVATE MEM_COMMIT  PAGE_READWRITE                     <unknown>  [................]
  21. 797c0000 797c1000     1000 MEM_PRIVATE MEM_COMMIT  PAGE_EXECUTE                       <unknown>  [U...E.....H..E.P]
  22. 797c1000 797e0000    1f000 MEM_PRIVATE MEM_COMMIT  PAGE_READWRITE                     <unknown>  [................]
  23. 797e0000 797e1000     1000 MEM_PRIVATE MEM_COMMIT  PAGE_EXECUTE                       <unknown>  [U...E.....H..E.P]
  24. 797e1000 79800000    1f000 MEM_PRIVATE MEM_COMMIT  PAGE_READWRITE                     <unknown>  [................]
  25. ...
复制代码
卦中信息太多了,刷了好久才刷完,Break 之后观察内存段,发现 RgnSize = 20000 的段貌似要多一些,为了发现 0x20000 的size到底有多少,这里需要写一段脚本进行统计,截图如下:

从卦中看 128k 的内存段个数就占用了 9000+,应该是什么东西分配了内存但没有合理释放。
由于没有给程序装监控,只能看内存段的地址上的内容了,这里使用 windbg 自带的 .writemem 命令将内存写到文件中观察,简单观察之后,发现里面有很多的 js 代码以及 html,比如下面的 PopupCalendar 方法,截图如下:

3. 继续乘胜追击

既然抽到的几个内存段有这些 网页内容,但不见得大部分内存段都有这些内容,那怎么去验证呢?可以使用 s 搜索内存去求证一下,比如我全内存搜索包含 PopupCalendar 的内存段有多少。
  1. 0:000:x86> s-a 0 L?0xffffffff "PopupCalendar"
  2. 08a4ed7c  50 6f 70 75 70 43 61 6c-65 6e 64 61 72 53 74 79  PopupCalendarSty
  3. 096f8fa3  50 6f 70 75 70 43 61 6c-65 6e 64 61 72 28 22 6f  PopupCalendar("o
  4. 096f9026  50 6f 70 75 70 43 61 6c-65 6e 64 61 72 28 22 6f  PopupCalendar("o
  5. 096ff5bb  50 6f 70 75 70 43 61 6c-65 6e 64 61 72 28 22 6f  PopupCalendar("o
  6. 096ff63e  50 6f 70 75 70 43 61 6c-65 6e 64 61 72 28 22 6f  PopupCalendar("o
  7. ...
  8. f5fec996  50 6f 70 75 70 43 61 6c-65 6e 64 61 72 28 22 6f  PopupCalendar("o
  9. f5ff2f2b  50 6f 70 75 70 43 61 6c-65 6e 64 61 72 28 22 6f  PopupCalendar("o
  10. f5ff2fae  50 6f 70 75 70 43 61 6c-65 6e 64 61 72 28 22 6f  PopupCalendar("o
  11. f5ff9543  50 6f 70 75 70 43 61 6c-65 6e 64 61 72 28 22 6f  PopupCalendar("o
  12. f5ff95c6  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内存管理 有一个比较深入的理解,还需要一个不骄不躁的分析心态。

来源:https://www.cnblogs.com/huangxincheng/archive/2023/04/03/17282019.html
免责声明:由于采集信息均来自互联网,如果侵犯了您的权益,请联系我们【E-Mail:cb@itdo.tech】 我们会及时删除侵权内容,谢谢合作!

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有账号?立即注册

x

举报 回复 使用道具