为什么资源监控器和任务管理器的总RAM使用量甚至没有相加就等于总物理内存使用量？[重复]

我已经在许多不同的Windows机器上注意到了这一点，在许多不同的情况下：任务管理器或资源监视器报告的RAM使用量经常加起来明显低于实际使用量。

例如，在笔记本电脑或台式机上，很多次我都看到7GB的内存在使用中，而工作RAM的总容量却更接近3GB。我只是不知道它在哪里使用！

这是我今天在服务器上的资源监视器中注意到的一个极端示例：

^{点击查看原图}

如果右键单击图像并在新选项卡中打开并查看数字，您会注意到工作集（不包括非物理虚拟内存）总计约为1.7GB。当启用“显示所有用户的进程”时，通过在任务管理器中累加RAM使用量，我得到了相似的数字。

现在，这是任务管理器的“性能”选项卡的屏幕截图：

^{点击查看原图}

这表示正在使用7.6GB的物理内存。

我一直在个人计算机，便携式计算机以及现在的服务器上看到这种情况：系统工具报告的总RAM使用率仅占我观察到的RAM使用率的1/4。WTF正在进行中？？？

关于我所有RAM的位置，是否有令人满意的解释？是什么在吞噬它，为什么它没有留下痕迹？

编辑：这是图形RAM使用情况的图片，因为用户要求：

^{点击查看原图}

编辑2：为回应James的回应，以下是poolmon.exe按大小排序的中未分页的进程的图片：

这些结果使我感到困惑。poolmon正确地指出我正在使用6GB的非页面缓冲池，但是所有非页面缓冲池进程的大小都小于8MB。

这意味着什么？是否poolmon无法使用非页面缓冲池检测某些进程？

抱歉，我知道这听起来像个flip昧的回答……但是标题中问题的答案是“因为他们不应该这样做”。

或者更客气地说：进程私有工作集中没有大量使用RAM。其中一些存在于流程的共享工作集中-但是由于共享，您无法在那里获得关于实际用法的可靠概念。将流程编号相加会给您带来太大的结果。

其他占用RAM的内容，例如非页面缓冲池，页面缓冲池的驻留部分以及其他内核空间使用的驻留部分，根本不会出现在任务管理器的“进程”显示中。

关于您的特定问题：

在任务管理器显示中，请参见“内核内存”部分？您有6 GB的“非分页内存”（即非分页池）。这是第二张图中“使用中”部分的一部分。未分页的池不计入任何进程费用，这就是为什么在任务管理器中将每个进程的数量加起来不会接近正在使用的总数。一些驱动程序最有可能使用它。这是一个完全过量的数目；它应该在1 GB以下。毫无疑问，任何驱动程序负责非页面缓冲池使用的过多部分都是错误的。

RAMmap可以确认这一点（在其“使用计数”选项卡上，查看“非分页池”的总数），但是它无法帮助您找到引起此问题的驱动程序。

找到它的方法如下：获取Microsoft工具“ poolmon”的副本。它是Windows驱动程序工具包中分发的字符模式工具（男孩，曾经有过）。对于Windows 7，可以免费下载 WDK 。您必须下载整个程序（这是一个ISO）并从中进行安装，但是如果您想要的话，可以选择仅安装工具。

在WDK目录中找到poolmon-确保选择正确的32位或64位-并在管理员命令提示符下运行它。您将得到如下显示：

现在，按“ p”键（不，我不是在开玩笑。这里没有菜单！），直到“类型”列仅显示“ Nonp”。然后按“ b”键（必要时可按两次），按“字节”列按降序对显示进行排序（此处已在示例中完成）。

然后查看最上面一行的“标签”列。在此处显示的（显然是人为的）情况下，它是“泄漏”。（此系统运行的驱动程序被故意错误地导致了此问题-它在“泄漏”非页面缓冲池。）

顺便说一句，突出显示的行是自上次对此旧屏幕进行更新以来更改的行。

现在，在c：\ Windows \ System32 \ Drivers中搜索包含该字符串的.sys文件。在这种情况下，您将寻找“泄漏”，如下所示：

c:\windows\system32> findstr /s Leak *.sys

然后在网上搜索对该字符串和/或该驱动程序名称的引用。

返回此处并报告.sys文件的全名，制造商名称等也将很有帮助。

（我敢打赌，您找到的标签将是ECMC，驱动程序是intmsd.sys，并且与名为ExpressCache或IntelliMemory的产品相关联。我会“卸载”该产品。有一个更新程序可以解决此问题，但即使使用固定版本时，我从未见过该产品提高系统的性能；它本质上是复制Windows中已经存在的功能。）

如果找不到这种方式，则下一步是使用“ Windows Performance Toolkit”。在此论坛中搜索该字符串，并附上magicandre1981的答案以获取操作方法。忽略提及xperf的答案-它是该工具的较旧版本。

更新：根据评论，OP进行了上述操作，发现尽管poolmon报告非分页池的总大小确实很大，但分配的所有块显然很小。我的猜想（也在评论中）是由于我称之为“膨胀的”池：分配了池，然后释放了池，但是由于某种原因，分配给池的RAM量没有减少以反映“释放” 。按照魔术师在此答案中描述的过程，可以找出罪魁祸首。