笔记本内屏黑屏，系统却说 “显示器一切正常“：一次 Intel PSR2 导致的 eDP 排查实录

早上开机，笔记本自带的屏幕全黑，外接显示器倒是一切正常。我本来以为半小时能搞定，结果一路查下去，把自己前面的判断推翻了三回，中间还差点去更新一个 2020 年的显卡驱动。这篇把整个过程记下来，包括走错的路 ------ 说真的，我觉得弯路比结论有价值。

机器是神舟 N9x0TC（蓝天模具），i7 配 GTX 1660 Ti 加 Intel UHD 630，内屏 15.6 寸 1080p 144Hz，外接一台 24 寸，Win 11，九月初刚重装过系统。黑屏的是内屏，外接好好的，鼠标键盘都活着。

按我的老经验，内屏黑屏无外乎这么几种：显卡驱动崩了（TDR）、亮度被拉到 0、投影模式切成了 "仅第二屏"，再严重一点就是背光或排线这种硬件问题。我按这个顺序一路查下去，前三个全被排除，最后一个看着也不像。

先查显卡状态和系统日志。如果真是 TDR，System 日志里应该有 nvlddmkm、dxgkrnl 或者 Display 相关的错误事件。我捞了最近 8 小时的日志：

复制代码

$ev = Get-WinEvent -FilterHashtable @{LogName='System';StartTime=(Get-Date).AddHours(-8)} -MaxEvents 500 |
      Where-Object { $_.Level -le 3 -and ($_.ProviderName -match 'nvlddmkm|igfx|Display|Kernel-Power|Monitor|dxgkrnl') }

一条都没有。近 8 小时零错误，两块显卡 Status=OK。驱动没崩，TDR 这条路直接断了。

再看亮度，查一下当前值：

复制代码

Get-CimInstance -Namespace root/WMI -ClassName WmiMonitorBrightness

Instance=DISPLAY\CMN1602\4&21c2c8ff&1&UID265988_0  Current=26

26%，正常值。而且这个值可读可写 ------ 说明系统跟面板之间的通信是通的。这里当时给了我一个误导性很强的信号，后面会讲。

顺手把显示模式也试了。跑了一次 displayswitch.exe /extend 强制切到扩展模式，ExitCode=0，没用。又把内屏的 PnP 设备禁用再启用：

复制代码

Disable-PnpDevice -InstanceId "DISPLAY\CMN1602\4&21C2C8FF&1&UID265988" -Confirm:$false
Start-Sleep -Seconds 2
Enable-PnpDevice  -InstanceId "DISPLAY\CMN1602\4&21C2C8FF&1&UID265988" -Confirm:$false

成功执行，屏幕纹丝不动。

到这儿我有点懵了：设备状态 OK、亮度能调、日志没报错、切换投影模式没反应。系统坚称这块屏幕一切正常，可肉眼看到的就是一片黑。

这块屏到底挂在谁下面

我一开始下意识以为内屏是独显直连的，很多游戏本都这么设计，还盘算着要不要把那个老掉牙的 NVIDIA 驱动更新掉。顺带说一句，那台机器的独显驱动版本是 27.21.14.5720，日期显示 2020-11-02，落后了整整五年，离谱程度你们自己体会。

好在动手之前我决定先确认一下拓扑。查每个显示器的父设备：

复制代码

Get-PnpDeviceProperty -InstanceId "DISPLAY\CMN1602\4&21C2C8FF&1&UID265988" `
                      -KeyName 'DEVPKEY_Device_Parent'

结果直接把我之前的假设推翻了：

复制代码

内屏  CMN1602  → Parent = PCI\VEN_8086&DEV_3E92\...   ← Intel UHD 630
外接  HWV6E4E  → Parent = PCI\VEN_10DE&DEV_2191\...   ← NVIDIA GTX 1660 Ti

内屏走的是核显，外接显示器走独显，标准的 Optimus 混合输出。同一时间另一条数据也对上了：Win32_VideoController 报的两个模式分别是 NVIDIA 1920x1080@60、Intel 1920x1080@144。144Hz 是内屏的规格，@60 是外接，完全吻合。

这一步的价值在于：如果当时我直接去更新 NVIDIA 驱动，纯属浪费时间，内屏根本不是它输出的。所以排查显示问题，先搞清楚 "这块屏归谁驱动" 再动手，真的能少走很多弯路。

真凶：PSR2 面板自刷新

方向锁定到 Intel 核显的 eDP 输出之后，去看它的驱动注册表项：

复制代码

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4d36e968-e325-11ce-bfc1-08002be10318}\0001

这个 GUID 是显示适配器的类 GUID，0001 是 Intel 卡的实例号，不同机器编号可能不一样，认 DriverDesc 去找就行。筛出跟电源、自刷新相关的键值：

复制代码

PSR2Disable                = 0     ← PSR2 开着
Psr2DrrsEnable             = 1     ← 动态刷新率切换开着
PowerGpsAggressivenessLevel= 1
PowerDpstAggressivenessLevel= 0
FeatureTestControl         = 33280
NoFastLinkTrainingForeDP   = 1

PSR2Disable = 0 就是 "不禁用 PSR2"，也就是面板自刷新开着。

说下 PSR 是什么。PSR（Panel Self Refresh）是 eDP 1.3 引入的省电特性：面板内部自带一小块 framebuffer，画面静止时，GPU 停止向面板发送图像数据，面板用自己缓存里的那一帧继续显示，链路进入低功耗状态。PSR2 是改进版，支持局部区域刷新。

听起来很美好，实际问题出在状态机上：某些面板和驱动的组合，进入自刷新之后退不回来。面板停在自己的缓存里不再接收新的图像流，GPU 那边该渲染渲染、该提交提交，双方都觉得对方没问题。

于是就有了开头那种诡异状态：系统认为显示器 Active=True，设备管理器状态 OK，事件日志零报错，亮度能读能写 ------ 肉眼看到的却是一片黑。

这里有个值得记住的点：亮度可调不能证明有画面 。亮度走的是 eDP 的 AUX 通道，跟主链路 Main-Link 的图像传输是两套独立通路。我一开始就被这个信号带偏了，以为能读亮度说明链路没事，其实 AUX 通着跟 Main-Link 有没有图像数据是两码事。

Psr2DrrsEnable = 1 是雪上加霜。DRRS 允许面板在 60Hz/144Hz 之间动态切换来省电，切换过程本身就有失败概率，两个特性叠在一起，更容易卡死。

修复，和一个差点没发现的岔子

改两个值：

复制代码

$key = "HKLM:\SYSTEM\CurrentControlSet\Control\Class\{4d36e968-e325-11ce-bfc1-08002be10318}\0001"
Set-ItemProperty $key -Name 'PSR2Disable'    -Value 1 -Type DWord
Set-ItemProperty $key -Name 'Psr2DrrsEnable' -Value 0 -Type DWord

改完注册表不会立刻生效，需要让核显重新初始化。不用重启整机，重启 PnP 设备就行：

复制代码

$iid = "PCI\VEN_8086&DEV_3E92&SUBSYS_951D1558&REV_00\3&11583659&0&10"
Disable-PnpDevice -InstanceId $iid -Confirm:$false
Start-Sleep -Seconds 3
Enable-PnpDevice  -InstanceId $iid -Confirm:$false

屏幕闪了几秒，内屏回来了。

不过这里有个差点没发现的岔子。第一次改的时候我手滑把 PSR2Disable 设成了 0------ 注意这个键名是 "Disable"，设 0 等于保持开启。刚好 Psr2DrrsEnable 那边从 1 改成了 0，看起来像是 "改了东西"，如果当时不复查一遍，就会误以为配好了。教训就是改完一定要回读验证，尤其是这种语义反转的键名（Disable / Enable / Deny 前缀），写错了不会报错，只是不生效。

第二个坑：注册表活不过重启

修好之后我以为完事了，结果重启了一次电脑，再复查，值全回去了：

复制代码

PSR2Disable                = 0    ← 又变回去了
Psr2DrrsEnable             = 1
PowerGpsAggressivenessLevel= 1

原因是 Intel 显卡驱动在每次初始化时，会把自己这组注册表值刷回默认 。也就是说，靠一次性导入 .reg 文件根本挡不住，重启即失效。

顺带一提，同一批配置里的 HiberbootEnabled 就活得好好的，因为它属于系统电源设置，没有驱动会去覆盖它。这也是判断 "谁在改这个值" 的一个思路。

既然驱动每次开机都要重置，那就让设置在开机之后自动补回来。写了个脚本做三件事：检查这 5 个值，不对就写回，然后重启核显让设置立即生效；值都正确时什么都不做 ------ 不会写注册表，也不会闪屏；再注册一个登录时触发的计划任务，保证以后每次开机自动兜底。核心逻辑：

复制代码

$targets = @(
    @{ Path=$igpuKey; Name='PSR2Disable';                  Value=1 }
    @{ Path=$igpuKey; Name='Psr2DrrsEnable';               Value=0 }
    @{ Path=$igpuKey; Name='PowerGpsAggressivenessLevel';  Value=0 }
    @{ Path=$igpuKey; Name='PowerDpstAggressivenessLevel'; Value=0 }
    @{ Path=$wuKey;   Name='ExcludeWUDriversInQualityUpdate'; Value=1 }
)

$changed = @()
foreach ($t in $targets) {
    $cur = (Get-ItemProperty -Path $t.Path -Name $t.Name -ErrorAction SilentlyContinue).$($t.Name)
    if ($cur -ne $t.Value) {
        Set-ItemProperty -Path $t.Path -Name $t.Name -Value $t.Value -Type DWord
        $changed += $t.Name
    }
}

if ($changed.Count -gt 0) {
    Disable-PnpDevice -InstanceId $iGpuId -Confirm:$false
    Start-Sleep -Seconds 3
    Enable-PnpDevice  -InstanceId $iGpuId -Confirm:$false
}

注册计划任务：

复制代码

$action  = New-ScheduledTaskAction -Execute 'powershell.exe' `
           -Argument "-NoProfile -NonInteractive -ExecutionPolicy Bypass -File `"$PSCommandPath`""
$trigger = New-ScheduledTaskTrigger -AtLogOn
$settings= New-ScheduledTaskSettingsSet -AllowStartIfOnBatteries -StartWhenAvailable
Register-ScheduledTask -TaskName 'InnerScreenBlackoutGuard' -Action $action `
                       -Trigger $trigger -Settings $settings -RunLevel Highest -Force

最后加上 ExcludeWUDriversInQualityUpdate = 1，是因为那台机器的老驱动本来就是 Windows Update 推的（472.20，2020 年的版本）。不堵住这个口子，哪天 WU 又推一版驱动下来，一样会把这些设置冲掉。

几个跟故障无关，但挺烦的环境坑

排查过程中还撞上几件跟故障没关系但挺烦的事。.ps1 的右键菜单没有 "以管理员身份运行"，这是 Windows 的设计，只有 .exe / .bat / .msi 才有。变通办法是写个自提权的 .bat 当启动器：

复制代码

net session >nul 2>&1
if %errorlevel% neq 0 (
    powershell.exe -NoProfile -Command "Start-Process -FilePath '%~f0' -Verb RunAs"
    exit /b
)
powershell.exe -NoProfile -ExecutionPolicy Bypass -File "Fix.ps1"

检测不到管理员权限就自己申请提权，双击即可。另外 PowerShell 会话是不是管理员要显式确认，同一个环境下有时能写 HKLM 有时不能，别猜：

复制代码

([Security.Principal.WindowsPrincipal][Security.Principal.WindowsIdentity]::GetCurrent()
  ).IsInRole([Security.Principal.WindowsBuiltInRole]::Administrator)

还有某些受限环境里 reg.exe 不在 PATH，Add-Type 也被策略拦掉，这种时候需要用 Set-Content -Encoding Unicode 生成 .reg 文件（UTF-16LE，带中文注释也不会乱码）。

复盘

回头看，能沉淀下来的经验其实就几条。显示问题先问 "这块屏归谁管"，DEVPKEY_Device_Parent 一条命令就能查清拓扑。Optimus 机器内屏常常挂核显，凭直觉判断容易南辕北辙 ------ 我这次就差点去更新独显驱动。"系统报告正常" 不等于正常：设备状态 OK、亮度可调、日志无报错，都只说明控制面（AUX 通道、PnP 枚举、驱动对象）是通的，不代表数据面（Main-Link 图像流）在跑，这次的三个 "正常" 信号全是误导。

改完必回读，特别是 Disable / Enable / Deny 这类语义反转的键名，写反了不会有错误提示。显卡驱动初始化时刷新自己的配置项是常规行为，涉及驱动注册表项的加固，都要考虑 "重启后怎么办"，不能假设一次写入永久生效。最后，老驱动是隐患源，Windows Update 推的驱动往往滞后很多，显示相关的疑难杂症，先看一眼驱动版本和发布日期，比什么都快。

机器是神舟 N9x0TC，如果你的也是蓝天模具或者类似 Optimus 配置，遇到内屏黑屏但系统一切 "正常" 的情况，可以直接按这个路径查 PSR2。也欢迎说说你们遇到的黑屏都是什么引起的，这类问题的成因比想象中杂。

附：本次用到的关键命令

复制代码

# 显示设备与状态
Get-PnpDevice -Class Display,Monitor | Select-Object Status,Class,FriendlyName
Get-CimInstance Win32_VideoController | Select-Object Name,DriverVersion,CurrentRefreshRate

# 显示器挂在哪个显卡下
Get-PnpDeviceProperty -InstanceId "<显示器实例ID>" -KeyName 'DEVPKEY_Device_Parent'

# 显示器是否活动 / 亮度（注意：亮度走 AUX 通道，只说明控制面通，不代表有画面）
Get-CimInstance -Namespace root/WMI -ClassName WmiMonitorBasicDisplayParams |
    Select-Object InstanceName,Active,VideoInputType
Get-CimInstance -Namespace root/WMI -ClassName WmiMonitorBrightness

# 显卡驱动注册表（Intel 核显 eDP 相关项）
Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\Class\{4d36e968-e325-11ce-bfc1-08002be10318}\0001" |
    Select-Object PSR2Disable,Psr2DrrsEnable,PowerGpsAggressivenessLevel,PowerDpstAggressivenessLevel

# 重启显卡设备使设置生效
Disable-PnpDevice -InstanceId "<显卡 PCI 实例ID>" -Confirm:$false
Start-Sleep -Seconds 3
Enable-PnpDevice  -InstanceId "<显卡 PCI 实例ID>" -Confirm:$false