最近，我们的实时服务器出现问题，导致我们的Web应用程序停止响应。我们得到的都是503错误，直到重新启动服务器，然后一切正常。最终，我将其追溯到httperr.log，发现了很多1_Connections_Refused错误。
进一步的调查似乎表明我们已经达到了非分页池限制。从那时起，我们一直在使用Poolmon.exe监视未分页的池内存，并且我们认为我们已经确定了导致问题的标签。
Tag Type Allocs Frees Diff Bytes Per Alloc
Even Nonp 51,231,806 50,633,533 684,922 32,878,688 48
如果我们使用poolmon.exe / g，它将映射的驱动程序显示为[<未知>事件对象]。
这根本没有帮助。我的团队花费了大量时间来研究此问题，但是还没有找到将其范围缩小到特定应用程序或服务的过程。我感觉到，大多数人似乎通过杀死计算机上的进程来解决问题，直到他们看到未分页的内存重置为止。这并不是在生产机器上工作时想要看到的。
如果我打开任务管理器并查看进程列表。我看到MailService.exe的NP池值为105K，比第二个列出的进程的值高36K。由于过去我们的邮件服务器存在一些问题（可能与此问题相关，也可能与该问题无关），我的直觉是这是导致此问题的原因。
但是，在我们重新启动服务之前，我想拥有的不仅仅是确定的感觉。
我也尝试使用poolmon.exe / c，但这总是返回错误：
unable to load msvcr70.dll/msvcp70.dll
而且它不会创建localtag.txt。我的同事不得不从互联网上下载pooltag.txt，因为我们无法确定它的位置。我们没有安装Win调试器或Win DDK（我可以看到）。可能是由于没有安装上述任何一个错误而导致的，但我不知道。
最后我尝试了：
C:\windows\system32\driver\findstr /m /l Even *.sys
这返回了相当大的.sys文件列表，再次对当前的问题完全没有帮助。
所以我的问题是：还有其他方法可以缩小导致此内存泄漏的原因吗？
更新：
如下所示，我已经记录了最后一天左右的池未分页字节数，以查看是否有任何趋势。在大多数情况下，所有过程的使用似乎都是静态的。他们中的两个看起来略有滴答声。在接下来的几天中，我将继续进行监视。
我也忘记了前面提到的任何一个进程似乎都没有使用过多的句柄。
更新2：
最近几周我一直在监视它。在此期间，单个进程的非分页字节池和总的非分页字节池都保持相对稳定。在此期间，Windows已更新，服务器重新启动，因此我想知道是否已经解决了问题。现在，我肯定没有看到非分页字节池的持续增长。