关于笔记本电脑使用外接显示器可能导致严重内存泄露的问题

最近我在使用win8.1系统时遇到一个严重的问题。即是当使用笔记本电脑并连接外接显示器作为仅第二屏使用时，在特定情形下会导致严重的虚拟内存消耗及占用。根据长时间的测试来看，这是一个及其严重的BUG，希望在今后的更新中能够尽快修正。

    先简单介绍一下基本情况和过程。我的笔记本电脑是宏碁S7-392超极本，我一般是把它放在家里当做主机使用，即屏幕盖合上，用它自带的HDMI接口向外输出信号。因为本人的HDMI设备比较多，如PS4、蓝光播放器等，所以使用了一个Marantz的AV receiver NR1604，它可以同时输入多个HDMI设备的信号，并由前端的旋钮选择希望输出到显示器的信号，这样我可以很方便的切换信源，而无需多次拔插接头。这样电脑输出的信号首先会通过功放，再由功放输出到显示器。

    我有时会下载一些大型文件，将电脑上的下载客户端设置好之后，我会关闭功放和显示器电源，或者直接做其他事，待他们自己自动进入待机状态。最近一段时间，当每次我回来打开显示器时，总会出现一个警告窗口，提示“虚拟内存不足，为了保证windows的正常运行，需要关闭以下程序”，但实际上提示的那几个程序根本就仅占很小一部分内存，根本达不到占满的情形。原先以为是下载软件导致的，所以我卸载的那个软件，然而问题依旧。后来我也卸载了近期安装的个别软件，结果仍是这样。我也查找了很多资料，然而都没有帮助。倒是找到了些跟我情况类似的情况，可以参阅：

    http://social.technet.microsoft.com/Forums/windows/en-US/1cd1b862-a5ab-48c8-ba33-bd6b673eb467/virtual-memory-exhaustion-when-idle?forum=w8itprogeneral

    我在这个帖子下面也留了言，说是用系统还原可以解决问题，这个仅仅是一个不是办法的办法，但是原因依旧未明。

    为了彻底搞清楚这个原因，我还是还原成了问题状态。这一次卸载了更多的软件，结果毫无改变，即便开机未主动运行任何程序，依旧会在50分钟左右后弹出虚拟内存警告窗口。有趣的是我发现在正常使用下，即屏幕和功放电源都打开，显示器正常出现图像，从未出现过警告和报错，查看资源管理器一切正常，而且如果单独使用笔记本电脑自己的屏幕也不会有问题。后来我又做了更多的实验，当笔记本电脑信号线不通过功放，直接连接显示器，即便因长时间没有动作导致屏幕进入省电模式黑屏，也是没有问题的。然而当连接上功放，而功放因待机没有供电时，问题会出现，顺便提一下功放里有类似继电器的东西，在手动关闭电源或者无操作自动关机时，能听到清脆的跳转声，料想是切断电源的声音。这一次我将已经合盖的笔记本电脑的HDMI线扯掉，以模拟前述的情况，50分钟之后同样的内存不足发生了，看来与功放的驱动以及显示器无关。整个事件似乎清晰了起来，于是乎这个问题貌似仅仅发生在：笔记本电脑使用外置显示器仅作第二屏输出，而输出的信号线掉电，此时的掉电指的是接收方没有任何供电，如上述的功放自动待机跳闸以及人为扯掉线材。这不同于直连显示器，显示器进入省电模式，因为即便是进入待机状态，显示器是有供电保持的，猜想笔记本电脑能通过HDMI线感知到另一端的存在。

    为了更进一步探究发生的过程，我并利用windows自带的性能监视器有选择的监控内存状态，这里我选择了Committed Bytes、Commit Limit以及Committed百分比，依旧是在笔记本合上屏幕状态下测试，因已排除功放的问题，故之后接口直连显示器。此时电脑已合盖，首先利用外接显示器将参数等选好，将监视器调整为监控状态，然后直接拔出HDMI输出线，等待几分钟后再将线材插回，此时显示器重新显示内容，可将此时的曲线进行分析解读。如果笔记本电脑不合盖，即拔掉外接线之后，笔记本会自动使用其自带屏幕显示内容，此时仅会在这切换的短暂时刻看到内存占用的一些波动，快速稳定之后会趋平，该情况下不会出现问题。也就是说，在笔记本电脑合盖状态下，即自身的屏幕不工作，使用HDMI接口向外输出信号情况下，若此时强行断开输出信号，内存提交量会不断上升，以致最终到达上限，系统警告报错。有如原本有一个渠道放水，若渠道被堵，则水池自溢。但不知真实内存情况是否如此。

    此时原因仍然是个谜。我备份了个人数据，利用自带的windows回收程序，将电脑恢复成了出厂状态，按同样的方式测试，惊奇的发现任何使用情形都没有出现问题。此时问题可以缩小到补丁和应用程序。在不安装任何其他第三方程序下，我更新了所有的系统补丁，发现问题又出现了。这难道是由于补丁引起的？

    我再一次重置了电脑，小心翼翼的安装每一个补丁，将windows自动更新关闭，手动选择更新。每安装完一个，测试一次，终于我发现当安装完KB2930275后会出现问题，为了稳妥起见，我卸载了这个补丁以查看是否正常，我很欣喜的发现问题消失了。为了确信是这个补丁的问题，我先后安装卸载了三次，结果使然。是什么补丁有如此大的问题，查询内容不甚详实，只是知道这个补丁是跟内核有关。感觉跟我的问题是有因果关系的。但因现在已为2014年6月，需要安装测试的补丁甚多有近100个，找到这个补丁之后，我无力再进行其他补丁的测试。料想其他未测试的补丁中也有可能导致问题的，这一次我安装了除KB2930275外的其他所有补丁，遗憾的是问题又冒出来了。

    所以这个问题产生原因的结论就是：KB2930275等其他潜在补丁在修补漏洞时，不慎改动了系统在信号输出、内存管理的其他参数，导致了关屏使用中内存溢出的问题。这是一个严重的BUG。

    如我使用功放集线管理HDMI设备的人也不在少数，而且有些信号传输中间设备或显示器终端若其待机模式真为切断物理电源，那么作为信号输出方的电脑就会出现如此严重的虚拟内存爆棚的情形。

    所以在此，真诚的希望微软公司能尽快提供后续补丁，以修正该模式下使用中出现的错误。也欢迎大家在此讨论更多细节与处理办法，谢谢你们！

    附录：

    下面是图片及日志文档数据的讨论。

    首先是问题出现时，弹出windows内存资源不足需要关闭的窗口，这里就没截屏了，只列出日志文件的信息：

    依次，这是同一时间系统自己诊断的内容，说一些程序占用了大部分虚拟内存，但实际上从数据就可以看出，那三个程序根本就不怎么占内存。这里猜想是有系统隐藏进程参与了提交内存的不断拔高。

    下面是系统安装的补丁情况，浅蓝色那一行便是问题补丁之一：

    性能监视器其中一次的检测曲线如下，这里仅选择了两条线条，提交百分比和提交量。可以看出当HDMI连接正常时，线条走向是水平的，但当插头拔出后，绿线代表的内存提交不断上升，百分比也是上升趋势，以最终将达到临界值。

    下面一张图会更加全面一些，包含了占用百分比达到100%的整个过程。可以看到输出线拔出之后，提交量不断上升，在短时间内因虚拟内存上限没有调整，故占用百分比也呈现出线性上升的趋势。但随着提交量的不断增加，百分比到达90%临界值，系统做出反应，将上限值提高1GB。于是乎每一次占用百分比到达90%，系统总会提额1GB的上限，所以占用百分比呈现锯齿形的上下波动。直到提交上限到达30GB，系统无法再为增长的内存申请空间，于是上限值犹如溢出一般线性增加到32GB，直到与绿线相交，此时占用百分比达到100%。从发生时间可以看出，此时电脑弹出内存不足警告窗口，日志记录ID号为2004的诊断事件。或许系统还有内存应急回收机制，在到达顶峰之后，绿色代表的提交值恢复到正常水平，上限值也同样回复了回去，占用百分比重新还原，可以看出之后便开始了一个新的周期。直到最后人为将HDMI插口插回电脑，结束此次监控过程。可以发现，插回插口显示器重新点亮，此时内存所有参数重回正常值，有如什么事情都从未发生一般。

    下面是警告窗口发生时，即虚拟内存占用达到100%时日志文件中记录的一些数值：

MemoryExhaustionInfo

  - SystemInfo

   SystemCommitLimit 34249924608

   SystemCommitCharge 34235064320

   ProcessCommitCharge 895049728

   PagedPoolUsage 291729408

   PhysicalMemorySize 8480120832

   PhysicalMemoryUsage 1709752320

   NonPagedPoolUsage 178434048

   Processes 98

• ProcessInfo

  - Process_1

   Name 360Tray.exe

   ID 5328

   CreationTime 2014-06-05T07:58:38.992816500Z

   CommitCharge 125030400

   HandleCount 860

   Version 7.7.3.1051

   TypeInfo 201

  - Process_2

   Name Dropbox.exe

   ID 5300

   CreationTime 2014-06-05T07:58:38.945940000Z

   CommitCharge 74350592

   HandleCount 583

   Version 2.8.3.0

   TypeInfo 210

  - Process_3

   Name explorer.exe

   ID 3532

   CreationTime 2014-06-05T07:58:31.676628700Z

   CommitCharge 62156800

   HandleCount 1974

   Version 6.3.9600.17039

   TypeInfo 219

    可以看到Commit Charge已经非常接近Commit Limit，系统虚拟内存资源几乎消耗殆尽。但将此情况的发生推给360，dropbox，explorer感到不可理解。

    以上便为附录内容，如有需要我也可以提供其他可参考的信息。