使用DebugDiag和WinDbg调查.Net应用程序中的内存泄漏

时间:2016-07-07 23:51:30

标签: c# .net memory-leaks windbg debugdiag

我正在尝试诊断C#客户端应用程序中的内存泄漏。这个应用程序:

  • 在强化的Windows环境中运行
  • 与本地未管理的第三方API进行通信
  • 通过tcp与服务器应用程序进行通信
  • 通过waveOutWrite()
  • 播放wav文件
  • 通过键盘供应商dll
  • 与自定义USB键盘集成
  • 接受用户输入以对第三方API执行操作

正常使用情况下的应用程序(取决于客户配置)使用50到100 MB的内存。我们对此应用程序的最新更新在几周内没有问题(在此期间确认没有内存问题)。然后,在没有任何代码更改或客户意识到的客户端计算机的任何更改的情况下,我们开始体验以下内容:

  • 不受控制的,快速的和/或渐进的内存增长,直到抛出内存消息
  • 来自自定义键盘的间歇延迟/不稳定响应
  • waveOutWrite()在我们尝试播放音频时返回错误值1(在内存接近最大使用量之前发生)

我使用DebugDiag 1.2来监控泄漏并获得最终的完全转储。分析的初步警告是:

DebugDiag Memory Warnings

转储在Native Heaps中显示1.19 GB的分配。 634MB来自 Microsoft VC Runtime Heap(私有),而来自DebugDiag LeakTrack堆的549MB。 634MB堆有44个段,其中大部分是15.81MB。

但是,分配报告似乎并不对应。按大小分配的最高分配为992KB,也是数量为3的最高分配。以下是634MB堆的最高分配:

Native Heap Top Allocations

我读错了吗?

转到WinDbg,如果我运行!heap -stat -h [634MBheapaddress] -grp B,我得到:

group-by: BLOCKCOUNT max-display: 20  
size     #blocks    total     ( %) (percent of totalblocks)  
    44 9ea51 - 2a23d84  (44.14)  
    1a 1fba7 - 338ef6  (8.83)  
    18 1b3b8 - 28d940  (7.58)  
    10 16913 - 169130  (6.28)  
    12 1222c - 146718  (5.05)  
    22 d9d0 - 1ceda0  (3.79)  
    1c 9bea - 110d98  (2.71)  
    14 9197 - b5fcc  (2.53)  
    26 9115 - 15891e  (2.52)  
    20 6774 - cee80  (1.80)  
    24 5094 - b54d0  (1.40)  
    30 4b03 - e1090  (1.30)  
    78 4a81 - 22ec78  (1.30)  
    28 48d2 - b60d0  (1.27)  
    4 48bb - 122ec  (1.26)  
    58 48aa - 18fa70  (1.26)  
    1e 48a6 - 88374  (1.26)  
    2a 48a3 - beabe  (1.26)  
    16 4898 - 63d10  (1.26)  
    600 4884 - 1b31800  (1.26)  

如果我正确读取它,它会将最高分配显示为68字节并具有650k分配。它是否正确?如果是这样,它可能是一个潜在的问题,但只代表44MB - 远不及650MB我显示为保留。

无论哪种方式,我现在还不确定如何弄清楚这些分配是什么或者是什么。而且我不知道为什么问题会在没有任何代码更改的情况下开始发生。我必须假设他们不知道的客户系统发生了一些变化,并且我们的代码中发现了一个错误,但到目前为止,我没有找到根本原因。

非常感谢任何帮助!

0 个答案:

没有答案