2026-10-06 后续更新： 后来灰屏再次出现。检查发现 GameViewer 虚拟显示适配器已经从禁用恢复为启用。Windows 设备安装日志记录了 16:59:10 的删除命令，以及紧接着的安装命令，调用程序均位于 UU 远程安装目录。下面的首次观察结果仍然成立，但仅禁用一次并不能保证状态长期保持；完整解决方案仍在验证。
我的笔记本通过 DP 外接一台 IPS 显示器。最近出现了一个很别扭的问题：电脑不用了，屏幕没有画面，外接显示器却像蒙着一层灰，背光一直亮着。以前并不会这样。
一开始我把它描述成“休眠后显示器不关闭”。后来才发现，真正的触发方式是 Win+L 锁屏，等待屏幕自动熄灭。而且它并非始终不关背光，而是先彻底黑下去，过一会儿又亮成灰色。
最后，在禁用 GameViewer Virtual Display Adapter 后，同样的锁屏测试没有再出现灰屏。我把过程记下来，也解释一下这个看起来像显卡的设备到底是什么。
黑色画面和关闭背光，不是一回事
IPS 显示器显示纯黑画面时，背光仍可能亮着，在暗处看起来就是灰色。显示器进入待机、背光熄灭，则是另一种状态。
这次故障的表现是：
- 外接屏先完全黑下去，关屏时出现过“无信号”。
- 过一段时间，外接屏的背光重新亮起，但没有正常桌面。
- 笔记本内屏没有一起亮起。
- 灰屏发生时，我没有操作鼠标或键盘。
所以只确认“电脑没有输出桌面”，还不足以判断显示器是否真正进入了待机。
先检查电脑有没有正常睡眠
这台电脑的外接屏是 SANC G7pro Max，物理显卡是 NVIDIA GeForce RTX 4060 Laptop GPU。设备列表里还有一个 GameViewer Virtual Display Adapter。
电源检查表明，电脑支持传统 S3 睡眠和休眠。实际事件记录也有正常睡眠：当天一次睡眠从约 14:03 持续到 14:35，并不是刚睡下就立即醒来。
这里还有个容易误读的地方：仅看系统日志中“进入睡眠”和“从睡眠恢复”的时间，可能判断不准。排查时还核对了 Power-Troubleshooter 事件中的 SleepTime、WakeTime，才确认实际睡眠时长。
管理员执行 powercfg /requests 时，DISPLAY 和 SYSTEM 项都没有阻止请求。不过这只说明检查当时没有相应请求，不能保证此后也不会出现。
后来明确了，我遇到的主要是锁屏后自动息屏问题，并不需要电脑先进入系统睡眠。
第一次测试为什么误判了
最初的办法是禁用 GameViewer 虚拟显示适配器，再直接向 Windows 发送关屏指令。外接屏的背光正常熄灭了。
接着重新启用它，再发送相同指令，背光也正常熄灭。临时把普通闲置关屏时间改成一分钟测试，同样看起来正常。测试结束后，原来的关屏时间也恢复了。
当时以为问题已经解决，后来我发现：它其实会先黑屏，过一会儿才灰屏。
更关键的是，直接发送关屏指令，并没有覆盖 Win+L 锁屏后自动息屏这个真正会出问题的场景。只观察黑下去后的几十秒，也可能漏掉延迟复亮。
微软文档说明，未锁屏和锁屏后的显示关闭使用不同计时设置。这台电脑原本的设置是：
| 场景 | 关屏等待时间 |
|---|---|
| 未锁屏，插电闲置 | 60 分钟 |
| 未锁屏，电池闲置 | 10 分钟 |
| 锁屏后闲置 | 1 分钟 |
这也解释了为什么修改普通“关闭显示器”时间，不能代替锁屏场景的验证。
改用真正的锁屏场景，观察得更久
第二轮排查注册了 Windows 的显示电源状态通知，并记录最后输入时间。记录器不采集按键内容。
在 GameViewer 虚拟显示适配器启用时，我按实际使用方式锁屏，保持无操作并观察超过 11 分钟。外接屏确实先熄灭，后来又灰亮了。
与此同时，Windows 在约 15:20:31 报告“显示关闭”，之后直到我主动恢复操作前，没有新的显示开启通知或输入活动。
也就是说，外接屏灰亮期间，Windows 仍认为显示处于关闭状态。这个结果让排查重点转向显示驱动、DP 链路与显示器的待机交互，而不是把它简单归因于鼠标唤醒。
当时还发现 Wallpaper Engine 在运行，启用了十分钟等待的屏保，“显示器休眠时”的处理是暂停。它也是一条线索，但这轮没有修改这些设置；观察期间也没有查到对应屏保进程启动。
我没有进行拔掉 DP 视频线的物理隔离，因此不能说已经完全排除了线缆和显示器。
有效的处理：只禁用 GameViewer 虚拟显示适配器
随后只做了一项改动：禁用 GameViewer Virtual Display Adapter，保留 UU 远程软件、后台服务和驱动文件。
再次按相同方式锁屏、等待自动息屏，并进行比最初更长的观察后，外接屏没有再灰亮。我确认这次暂时恢复正常。
普通关屏时间仍是原来的插电 60 分钟、电池 10 分钟。没有为了掩盖问题把电脑改成永不关屏，也没有卸载整套显卡驱动。
如果其他人也遇到类似问题，可以在本机做同样的可恢复对照：
- 打开“设备管理器”。
- 展开“显示适配器”。
- 找到 GameViewer Virtual Display Adapter。
- 右键选择“禁用设备”。不要禁用 NVIDIA、AMD 或 Intel 的物理显卡。
- 按 Win+L，等自动息屏后继续观察，至少覆盖原本会复亮的时间。
需要恢复时，在同一个位置选择“启用设备”即可。
我这台电脑的最终设备问题代码为 22，表示设备被禁用。它的实例是 ROOT\DISPLAY\0000，但这个路径不应该直接照搬到别人的电脑。
GameViewer 到底是什么，有什么用
本机 GameViewerServer.exe 的产品名称是“网易UU远程服务”，公司字段是 NetEase，数字签名也属于网易；服务端文件版本是 4.33.0.8907。所以它来自网易 UU 远程，不是 Windows 自带的物理显卡。
UU 远程用于跨设备查看和操作电脑，例如在手机、平板或另一台电脑上远程办公、游戏串流、远程协助和传输文件。官方也提供无线副屏功能，把手机或平板作为电脑的额外显示区域。
GameViewer Virtual Display Adapter 是这套软件的虚拟显示组件。可以把它理解为给 Windows 提供一块由软件实现的显示设备，再让远端设备接收它的画面。它不是 RTX 显卡，也不会给本地游戏增加一块实际 GPU。
微软的间接显示驱动文档说明，虚拟显示驱动会参与显示图像处理、电源管理和即插即用。因此它即使不是实际连着 DP 的物理显卡，也可能影响整体显示行为。不过这还不能解释本次故障在驱动内部的具体机制。
禁用以后有什么影响
这次禁用的范围有限，影响也应该按功能区分：
| 功能 | 当前判断 |
|---|---|
| 笔记本内屏、DP 外接屏、本地操作 | 本次使用和关屏测试正常 |
| NVIDIA 的本地游戏渲染 | 没有禁用物理显卡；游戏性能没有做专门测试 |
| 手机、平板作为无线副屏，创建额外虚拟显示器 | 依赖虚拟显示组件，可能无法正常使用 |
| 在缺少可用物理显示输出时进行远控 | 若需要虚拟屏提供画面，可能受到影响 |
| 捕获现有物理屏幕的普通远控、游戏串流 | 本次未验证，不能保证完全不受影响 |
| 隐私屏、远程调整分辨率等显示相关功能 | 可能依赖虚拟显示组件，需要实测 |
| UU 远程后台服务 | 仍在运行；禁用适配器不等于关闭远控软件 |
如果平时不用无线副屏、虚拟显示器，可以先保留禁用状态。如果确实需要这些功能，就重新启用并确认问题是否复现，再考虑向官方反馈兼容性问题。
这次能够确定到什么程度
在我这台电脑上，启用时，Win+L 后自动息屏会延迟灰亮；禁用后，同样场景的较长观察没有再出现问题。这是目前有效的处理，也是 GameViewer 虚拟显示组件参与问题的有力线索。
但我还没有在这个真实锁屏场景下重新启用它，再观察一次故障是否复现。驱动、显卡和显示器之间的具体兼容机制，也没有查明。前面直接关屏的重新启用测试，不能替代这一轮完整对照。
这次最有用的经验是：测试必须覆盖真实的触发方式和延迟时间。屏幕刚刚黑下去，并不代表它会一直保持待机。
参考资料
后续：虚拟适配器被后台重新安装
首次长时间锁屏测试正常后，灰屏后来再次出现。我没有重启电脑，也没有主动打开或更新 UU 远程、从手机连接这台电脑。
再次检查发现，设备问题代码已从禁用时的 22 变成 0，也就是虚拟适配器重新启用了。Windows 的 setupapi.dev.log 提供了更直接的证据：
- 16:59:10.616，UU 远程目录下的
bin\drivers\devcon.exe执行remove "Root\GameViewerIddDriver"，删除虚拟显示设备。 - 16:59:10.742，同一程序执行
install，使用 UU 远程自带的GameViewerIddDriver.inf重新安装这个设备。 - 16:59:11.528，Windows 记录安装成功。驱动仍是原来的
15.6.5.199，不是一个新版本。
这说明不能直接把这次复发理解成“保持禁用也没有效果”：至少重新检查时，禁用状态已经被一次删除、重装覆盖了。不过日志只证明 UU 远程目录中的程序执行了驱动重装，没有直接确定是哪个后台模块触发，也不能据此断言重装恰好发生在肉眼看到灰屏的同一刻。
下一步改为临时停止 UU 远程后台，再禁用虚拟显示适配器，以隔离后台维护行为。如果还需要经常远控，就必须继续寻找保留远控功能的兼容设置；如果基本不用，可以考虑关闭后台自启。不能在未确认用途前把整套软件卸载掉。
因此，这篇记录目前的结论是：禁用虚拟适配器曾让真实锁屏测试恢复正常，但状态随后被重新安装覆盖；长期修复仍未完成。
评论