内存泄露检测方法

诊断内存泄漏导致的死机问题(2012-11-01 22:01:50) 转载标签： it分类： 工作 在客户这的CASE统计显示，70%左右的VDI问题为连接性问题，就是老登不上去，这其中有相当一部分是由于内存泄漏导致VDI死机引起的，通常表现为VDI一直不关机，一觉醒来就死掉了；或者用户出差好几天没关闭VDI，回来时再使用就发现死机了，VDI此时无法响应DDC或PC/TC终端的连接请求，此时往往就只能通过重启VDI来解决。当然，内存泄漏也会发生在普通PC机当中，这只是操作系统层面的问题，并非说是VDI所独有的现象。先来看看内存泄漏问题的“临床症状”1.系统日志ID2019,非页面共享区(Nonpaged Pool)用完了，是“空的”2.系统日志ID56,显示某些驱动程序无法分配内存3.应用日志ID2001,密集的PerfDisk无法读磁盘性能事件4.系统日志ID50，来源于ntfs无法保存文件。5.在执行命令时的怪异现象，比如cmd这类普通的命令会显示不是内部或外部命令之类6.要打开普通文件都会显示资源不足7.会弹出延迟写入失败，无法保存数据之类8.VDI会自行关机。特别是在夜间或凌晨无人访问的时候。（以前妞妞生病也几乎都在晚上啊，漫长的夜，难熬的夜.)有上述1-8现象之一，就可能发生了内存泄漏问题。如果发生1或2现象，可以肯定发生了内存泄漏。要诊断内存泄漏问题，需要说说2种系统内存池。系统内存池在OS初始化时由内存管理器创建，内核模式的组件（主要是.SYS驱动程序或服务程序）都从以下这两种池中分配系统内存：Paged Pool, 分页池，可以执行换入换出系统操作的一段虚拟内存。WinXP x86的分页池最大限制为492MB。NonPaged Pool,未分页池，一旦加载到该池就始终驻留在物理内存中。任何进程都可以访问到未分页池，NonPaged在WinXP x86系统中最大只允许256MB(在boot.ini中带/3GB参数启动的OS，NonPaged最大值为128MB)，未分页池不执行换入换出操作，一旦发生内存泄漏，后果很严重。发生内存泄漏的进程很多，但是要想产生一定的后果，就需要这个进程是无限循环的，所以通常是服务进程或驱动程序。发生内存泄漏时通常从XenCenter后台或任务栏管理器中查看VDI总的内存使用率并不高，而VDI却运行缓慢甚至死机，这是因为用户模式进程即使发生了内存泄漏，也会通过换入换出到硬盘(pagefile.sys)得到缓解，而内核模式组件，特别是NonPaged发生内存泄漏， 却因为一直占用受限大小的物理内存，最终导致“内存还有很多却还是死机了”的现象。为了进一步诊断是由哪个程序引起的内存泄漏，需要3个工具：gflags.exe,在Windows XP安装光盘的SUPPORTTOOLSSUPPORT.CAB文件中，启动内存池标记(Tag,用于关联驱动程序)的工具poolmon.exe，在Windows 2003 with SP2安装光盘的SUPPORTTOOLSSUPPORT.CAB文件中，WinXP的poolmon不支持/n参数（导出输出到文件），所以用Windows 2003中的。用于分析内存泄漏的工具。filever.exe，在Windows XP安装光盘的SUPPORTTOOLSSUPPORT.CAB文件中，用于列举驱动文件属性的工具，例如驱动程序的厂商及驱动程序所属产品的描述信息。将上述3个文件拷贝到可能存在内存泄漏的VDI中（WinXP系统）以下步骤为诊断过程。首先以管理员权限登录VDI，启动gflags,激活池标志，然后重启VDI增加一个计划任务(在哪添加？)按每10分钟运行一次poolmon命令，以收集内存池分配信息。poolmon可以直接运行在命令行模式下进行实时观察，但是考虑到不影响用户在前台使用，况且死机时也看不到前台输出，所以只能是以计划任务运行在后台，并采用/n参数输出到文本poolog.txt，以便随时查看，/n参数有个极好的地方就是增量输出到poolog.txt，这样我们可以看到全部采样时间段的内存分配变化。/b参数的作用是按照分配内存的大小（以byte为单位）排序，所以持续增加且排在第一的，就是内存泄漏程序。注意计划任务要以管理员身份来运行。设置间隔10分钟运行一次。用VBS脚本定制的计划任务无法设置这里的“高级计划选项”，即某一天当中执行的频度，所以也只能采用手动来设置计划任务。快的话半天，慢的话经过一至二天，把poolog.txt取回来看，就可以看到是哪个Tag标志的驱动程序导致的内存泄漏了。用ultraedit查看时，选中Tag Type Allocs.标题字段，一直按F3往下查找，然后注意排在第一位的Tag，是否是Nonp（属占用非分页池的），且它的Bytes是否一直在增长，如果是，表明由它导致了内存泄漏。为了看得方便，我把每段取样只保留Top 3的Tag（一个Tag对应一个驱动程序，或一个较大驱动程序的一部分），可以看到一个名为Icp的Tag在持续的增长，特别注意它是在未分页池中(Nonp)，由于未分页池是很小的（在多数情况下我只看到128MB左右，后面有如何查看限制值的方法）,根据经验，一个Tag大于10M(10,000,000Bytes)都将是非常可疑的。接下来，我们从C:根目录开始查找这个Icp的Tag与哪个驱动程序相关联。可以使用findstr /s /m /i Icp c:*.sys说明：/s 代表遍例子目录/m 代表搜索结果只显示检索关键字所在的文件名/i 检索关键字不区分大小写如果运气好的话，只会搜索出少量的结果。接下来咱只能用排除法了：1.一个个删除搜索出来的程序，删除poolog.txt文件然后重启2.等待一段时间后再次查看poolog.txt验证Icp是否还是top1，如果不是，则表明刚删除的这个程序便是造成内存泄漏的源头。如果是，继续第1步。我们可以进一步减少排除的范围。1.c:WINDOWS$xxxx$这样的目录是WINDOWS安装文件或补丁文件解包的目录，不用管它2.c:WINDOWSdllcache目录是WINDOWS系统驱动和共享库的备份目录，也不用管它3.重点关注以下画黄色框的两组，一组是Trend反病毒软件，另一组是系统驱动目录，但系统驱动目录的.sys文件一一查看，均为微软出品，也可以忽略，最后最值得怀疑的，便是Trend反病毒软件了。删除Trend反病毒软件删除poolog.txt后重启，等待小半天，再次打开poolog.txt后，可以看到Top1已不再是Icp了。不过，细心的哥有注意到Mmst似乎在一直增长着，尽管看来非常的慢，不过因为它是Paged，就当飘过吧。来对比一下poolmon实时监控，下图为删除Trend之前的输出，可以看到Icp排到了第一，已经达到38.9MB删除Trend后的一段时间的poolmon输出，已看不到Icp了.所以引起这例内存泄漏的源头是Trend 反病毒软件！再来看另一例VDI的内存泄漏，这个稍微有些麻烦。因为Tag叫Thre,而Thre与Thread这个词接近，所以搜索出了一堆的.sys驱动文件。这个名为Thre的Tag的增长非常惊人，几乎达到了整个Nonpaged池256MB的最大上限，而且也只用了1天不到时间很不幸，清单列表实在是长，在删除Trend，升级VDA以及删除Wireshark后，Thre还是挂在Top1.于是我重点关注起drivers目录下的一长串文件。现在，我动用第三个工具filever.exe /v先把所有.sys文件的详细信息导到一个文件里。我只关注每个文件输出中的2行，公司名称CompanyName和产品名ProductName。如果公司是微软的，我权当飘过。产品名告诉我应该删除哪个程序。如果文件少，也可以右击文件属性看到所属公司和产品描述信息。下面这个mvagtdrv.sys居然没有厂商信息和产品信息，非常神秘的说。我放到bing里一搜就出来，是McAfee的Move AV反病毒程序，必应的准确率很高哦！而且巧的是，搜索来的结果就是手动教你如何删除它的，哈哈！我把非微软的驱动都标注为黄底色，最后也只有4个东东：.McAfee MOVE AV，针对VDI平台的反病毒软件.WINPCAP.某种播放器或视频捕获器的驱动.McAfee DLP,所有文件I/O都会经它过滤，并进行监控记录的程序按指示输几条命令后重启，再通过“添加/删除程序”正常删除了MOVE AV观察了一袋烟的功夫，Thre消失了！此例说明正是McAfee MOVE AV造成内存泄漏问题！再查看实时状态，已经OK！-其他测试：可以用微软官方Not My Fault工具手动触发Memory Leak来进行测试，它还可以触发各种类型的Crash蓝屏效果（以便DUMP出内存）和Hang效果。本篇首的2-7故障现象就是我通过该工具触发内存泄漏后观察到的现象。NotMyFault.zip，下载/files/NotMyFault.zipPooltag.txt，在WINDBG安装目录下的triage目录下，例如：C:Program FilesDebugging Tools for Windows (x86)triagePooltag.txt，用于Poolmon执行时显示已知的关联驱动程序对象。将它拷贝到poolmon同一个目录，然后用/g参数执行时，可以解析出对应的Mapped_Driver。如果是像下面的驱动，依然要用上述的Findstr来找到对应的.sys,非unknown的基本上都是微软的驱动，一般都OK，不会有内存泄漏问题。如何查看当前系统的NonPaged的上限呢，有2种方法：1.用Process Exp