如何分别监视Windows下KernelMode与UserMode程序的内存泄漏

最近系统侧的程序不定时地发生条码读取超时的错误。简单调查过后发觉是缓慢地内存泄漏造成的系统性能低下。由于这次客户ERP的架构对于我们是从未接触过的，所以这一侧也引入了不少全新的组件，内存泄漏的原因一时无法判明，于是展开了全面监视。

这里的监视主要还是利用了Windows自带的性能计数器（Performance）。

首先观察内存总体的使用情况，关注Memory性能对象中Available Bytes值的变化，在系统进入稳定运行后，如果在一个较长时间内如果呈现单调的下降，就说明发生了内存泄漏。

但KernelMode的内存泄漏，在这里就不是那么显而易见。对于32位windows，内核内存地址总量（包括分页与未分页）与全部的虚拟内存地址相比要小上许多。由物理内存数量与各种设置决定，最大也不会超过1GB（64位系统达到了128GBx2），使用量的变化上更是微乎其微。如果变化激烈，那系统崩溃便近在眼前。

对于KernelMode的内存泄漏，可以关注Memory性能对象中的Pool nonpaged bytes和Pool paged bytes计数器。其中Pool paged（已分页）表示可以被交换到硬盘上的部分，Pool nonpaged（未分页）表示需长期驻留物理内存（即无法允许缺页错误）的部分，两者之和就是全部的内核内存了。

关注这两个计数器，如果任何一个呈现单调的上升，则内存已经泄漏了。

接下来要将泄漏特定到具体的程序。

对于UserMode程序（一般的应用程序），这是就可以对值得怀疑的程序惊醒具体排查了。首先还是要让系统稳定运行起来，然后关注Process性能对象中相应进程的Private bytes和Working set计数器，Handle Count也可以关注一下（各计数器具体的含义这里就不赘述了，MSDN上有官方解释，网络上有很多介绍）。随程序功能的不同，Private bytes可能会有很大浮动，但总趋势如果越来越高的话，说明发生了泄漏。之后就可以展开针对代码的分析。

对于KernelMode程序（系统、驱动及其他内核态代码），一般应用程序中的内核态代码，可以通过关注他们各自进程的Pool nonpaged bytes和Pool paged bytes计数器来进行判断。但对于驱动程序等，因为他们没有相应进程则无能为力了。

这时可以利用微软提供的Poolmon来实现监视。

具体可参照下面链接：

How to use Memory Pool Monitor (Poolmon.exe) to troubleshoot kernel mode memory leaks

按照上述链接中的方法，启用内存池的标记模式（Tag Mode），就可以很方便地利用Poolmon.exe来查看当前所有内核态代码所占用的内存大小了。