多 GPU 平台出毛病的时候，大多数人的操作顺序都很一致：先重装驱动，不行就把 Display Driver Uninstaller 搬出来跑一遍。我这些年经手过不少这类机器——笔记本双显卡切换失灵、工作站上两块独显轮流失效、外接显卡插上系统认卡但不输出——十次里有六七次，问题并不在新装的驱动上，而在上一份驱动没清干净的尾巴上。所以“用 DDU 清一遍”这个动作本身没错，错的是很多人把它当成万能钥匙，勾两个选项点一下重启，然后发现情况更糟了。
这篇内容讲的就是把这件事做完整：基于 Display Driver Uninstaller 搭一套可重复、可验证、可回滚的多 GPU 平台兼容性检查流程。它不是让你多清几次驱动，而是把“清”当成一个受控实验——清理前有快照，清理中有固定顺序，清理后有逐卡交叉验证和结果记录。适合手里有多卡机器、经常要在不同驱动版本之间来回横跳的人，也适合刚接手一台来路不明的二手工作站、想先把底子摸清楚的新手。文中提到具体显卡时统一用“独显 A”“独显 B”代指，不绑定任何具体品牌型号，流程本身跟厂商无关。
1. 多GPU平台的驱动残留为什么比单卡难缠
单卡机器上，驱动残留的表现通常很直白：装新驱动报错、设备管理器带黄色感叹号、或者干脆装不上。多卡机器完全是另一回事，因为系统里同时存在多套显示类设备栈，它们共享同一个设备类注册表分支、共享同一个驱动存储区、共享同一套显示拓扑管理逻辑。任何一份残留都可能只影响其中一张卡，而症状却表现在另一张卡的输出上，这就是排查最折磨人的地方。
1.1 三种典型多卡组合与它们各自的驱动栈
先把手上的机器归类，这一步决定了后面清理的复杂程度。我一般分成三类：核显加独显的混合平台、双独显平台、以及外接显卡平台。
混合平台最常见，笔记本基本都是这个形态。核显负责内屏和部分视频解码，独显负责重负载渲染，两者通过系统的显示拓扑管理做动态切换。这类平台的特点是驱动之间存在隐式耦合——核显驱动版本过旧时，独显驱动可能装得上但切换逻辑失效；反过来，某些版本的独显驱动会把核显的一部分显示相关组件顶掉。清理时如果只清独显不动核显，大概率留下一个“能渲染但切不回去”的中间状态。
双独显平台多见于工作站和算力机。两张卡可能同厂商同型号，也可能不同厂商。同厂商同型号的情况下，系统里会有两个设备实例指向同一份 INF，清理时容易出现“清了一个另一个还在”的假干净；不同厂商的情况下，两套驱动栈各自独立，但会争抢同一个显示适配器设备类下的注册表键，谁后装谁覆盖，顺序不对就会互相踩。
外接显卡平台的核心问题在热插拔和枚举顺序。外接设备通过雷电或 OCuLink 接入，走的是可热插拔的 PCIe 路径，设备实例 ID 里带着动态生成的父设备标识。每次拔插，实例路径都可能变，旧的设备项就变成了“幽灵设备”躺在系统里。这类残留用常规卸载清不掉，必须靠 DDU 或者手动清设备项。
提示：判断自己属于哪一类，最直接的办法是打开设备管理器，把“显示适配器”展开，数一下有几个条目，再看每个条目的属性里“位置”一栏的 PCI 总线号、设备号、功能号。记下来，后面验证时要用。
1.2 残留实际藏在哪五个位置
大部分人以为卸载驱动就是删个程序，实际上显示类驱动会往至少五个地方写东西，任何一个没清干净都可能引发兼容性问题。
第一个是驱动存储区，也就是系统存放驱动包的仓库。每次安装驱动都会在这里留一份带随机前缀的驱动包，系统回滚、重装、自动更新都从这里取。旧驱动包不删，系统在检测到设备异常时可能自动回滚到那个旧版本，你刚装好的新驱动就被顶掉了。
第二个是显示适配器设备类的注册表分支。这个分支下按 0000、0001、0002 这样编号排列，每个编号对应一个曾经安装过的显示设备，里面存着驱动描述、匹配的设备 ID、INF 路径、各种能力标志。设备拔掉之后这些键不会自动删除，越积越多，编号也会错乱。
第三个是设备枚举树。物理设备已经不在的条目会以“幽灵设备”形式保留，尤其是外接显卡反复拔插之后，同一个物理卡可能对应好几个残留条目，系统启动时会尝试加载它们的驱动，白白拖慢启动还容易冲突。
第四个是用户态组件和配套服务。显示驱动通常附带控制面板、色彩管理、音频输出组件、遥测服务等一堆东西，这些组件的卸载程序往往写得很敷衍，卸载后目录和注册表项还在。
第五个是显示相关的系统级配置，包括每台显示器的 EDID 缓存、色彩配置文件、每应用的显卡偏好设置、多显示器布局。这部分严格来说不算驱动残留，但在做兼容性检查时它们会污染结果——你以为驱动换了表现应该变，实际上还是旧配置在起作用。
1.3 兼容性检查真正要回答的三个问题
把流程设计清楚之前，得先明确这套检查是干什么用的。我总结下来就三个问题，所有步骤都围绕它们展开。
第一个问题：这台机器在完全没有第三方显示驱动的情况下，硬件本身是否正常？也就是裸机状态下，固件能不能正确枚举所有卡，基础显示输出能不能起来。这一步不通过，后面装什么驱动都是白搭，说明问题在固件设置、插槽、供电或者硬件本身。
第二个问题：每张卡单独装驱动时表现如何？这一步是把变量降到最少，一次只引入一张卡的一套驱动，确认它能独立工作。很多“多卡不兼容”其实是某一张卡自己的驱动就有问题，多卡只是让症状更明显。
第三个问题：两张卡（或多张卡）的驱动同时存在时，会不会互相干扰？这是真正的兼容性检验，重点看显示拓扑切换、睡眠唤醒、负载切换、热插拔这几类跨卡行为。
这三个问题必须按顺序回答，跳过第一个直接装驱动，最后你分不清是硬件问题还是驱动问题，只能靠猜。
2. DDU 在多卡环境里的能力边界
Display Driver Uninstaller 好用，但它不是魔法。它的设计目标是“把某个厂商的显示驱动彻底清干净”，这个目标在单卡机器上达成度很高，在多卡机器上就要打折扣。搞清楚它清了什么、没清什么，比盲目多跑几遍有价值得多。
2.1 它到底清什么：从设备类 GUID 说起
系统里所有显示适配器都归在同一个设备类下，这个类有一个固定的 GUID 标识。DDU 的核心动作就是围绕这个类展开的：找到该类下所有注册表子键，逐个读取里面的 INF 路径和设备匹配信息，反查出对应的驱动包，然后把这些驱动包从驱动存储区删掉，同时清理相关的服务项、内核驱动文件、用户态目录和注册表键。
除了显示适配器类，它还会顺带处理几个关联项：与显示驱动捆绑的音频组件（很多显卡通过 HDMI 输出音频，会额外装一个音频设备类驱动）、显示器驱动（部分厂商会装自定义的显示器色彩配置文件）、以及一些安装器留下的临时目录。
这个机制决定了它的一个特点：它是按“厂商 + 设备类”来定位的，不是按“物理卡”来定位的。在单卡机器上这两者等价，在多卡机器上就不一定了。如果你机器上两张卡来自同一厂商，DDU 在选择清理目标时把它们视为一体，理论上会全部清掉，但实际上它对每个设备实例的处理是有先后顺序的，中途出错就可能漏。
我一般会在跑 DDU 之前先手动确认一遍：打开注册表编辑器，定位到显示适配器类分支，看下面有几个有效子键，每个子键的驱动描述和 INF 路径分别是什么。这一步花两分钟，能避免后面反复试错。
2.2 安全模式与断网这两条前置条件的原因
DDU 的界面上明确要求进安全模式、断开网络，很多人当成例行提示直接忽略，结果清理不彻底还找不到原因。这两条背后都有实打实的理由。
安全模式的作用是让系统只加载最基础的一套驱动。正常启动时，显示驱动是常驻的，驱动文件被系统占用，DDU 就算删了注册表项和驱动包记录，正在使用的文件也删不掉，重启之后系统发现文件还在，又给装回去了。安全模式下系统用的是基础显示驱动，第三方显示驱动的文件不被占用，才能真正删除。另外，安全模式下各种显卡配套服务不会启动，也就不会在你清理到一半的时候重新写回注册表。
我自己踩过的坑是用了“带网络连接的安全模式”，结果系统在后台自动下载并安装了一个旧版驱动，等我清理完重启，设备管理器里赫然是个我没装过的版本。所以断网这条必须严格执行：拔网线、关无线，或者在安全模式里直接禁用网络适配器。
还有一个容易被忽略的点：安全模式有新旧两种。老式的那种在启动时按功能键进入，加载的驱动集更精简，DDU 在这种模式下工作最稳定。新式的那种是从系统设置里重启进入的恢复环境，虽然也能跑，但有时候会因为驱动加载策略不同导致清理结果不一致。我一般优先用老式的。
2.3 多卡平台下 DDU 的四个典型失效点
把多卡场景的实际经验汇总一下，DDU 容易出问题的地方集中在四处，提前知道能省很多时间。
| 失效点 | 表现 | 原因 | 应对 |
|---|---|---|---|
| 只清了一家的驱动 | 另一张卡还是旧驱动状态 | 多厂商平台需要分别清理 | 按厂商分批执行，每批之间重启 |
| 同厂商双卡漏清 | 一张卡正常一张卡报错 | 设备实例处理有先后，中途可能中断 | 清理后手动核对设备类注册表分支 |
| 核显被误清 | 内屏黑屏，外接能用 | 混合平台的核显也属于显示适配器类 | 明确选择只清独显，或清完立刻装回核显驱动 |
| 幽灵设备未处理 | 设备管理器有隐藏条目 | DDU 不处理非活动设备项 | 清理后用设备管理器显示隐藏设备手动删 |
第一点最值得展开。多厂商平台的正确做法是分两轮：第一轮只选其中一家厂商，清理完重启；第二轮再选另一家，清理完再重启。中间那次重启不能省，因为第一轮清理后系统需要重新枚举设备，第二轮才能准确定位到剩下的设备实例。我见过有人图省事两轮连着跑不重启，结果第二轮清理时系统状态还没稳定，清了个寂寞。
第二点在同型号双卡上特别隐蔽。表面上看驱动都卸载了，设备管理器里两张卡都变成“Microsoft 基本显示适配器”，好像清干净了。但你去注册表里看，可能还有一个子键残留着旧 INF 路径，下次装驱动时系统会优先匹配这个残留项，导致其中一张卡用上了错误的驱动版本。核对的方法很简单：清理后进注册表看显示适配器类下还有几个子键，正常情况下应该只剩系统自带的基础显示驱动那一两个。
第三点是混合平台最容易翻车的地方，后面第 5 章会专门讲。
第四点经常被当成“不影响使用”而忽略，但幽灵设备会让系统启动时多做一轮驱动匹配，某些情况下还会导致新插入的同类设备被关联到旧条目上，出现“插上了但系统认为是另一张卡”的诡异现象。
3. 动手之前：把机器状态拍成快照
我见过太多人清理前什么都不记，清理后想回滚发现还原点没开、驱动包没备份、原始配置也说不清。兼容性检查本质上是受控实验，实验的第一步永远是记录初始状态。这一章讲的都是“花十分钟省十小时”的活。
3.1 硬件拓扑与驱动信息的一次性采集
采集要覆盖三层信息：物理层、驱动层、配置层。
物理层看的是卡插在哪、走多少通道。设备管理器里每张卡属性中的“位置”字段会给出总线号、设备号、功能号，配合主板手册能反推出插槽。更直接的办法是用系统自带的系统信息工具导出完整报告，里面会列出每个 PCIe 设备的链路宽度和速率。多卡平台尤其要看这个，因为很多主板在插满卡之后会自动拆分通道，比如原本 x16 的插槽变成 x8+x8，如果拆分策略和卡的能力不匹配，第二张卡可能只跑在 x4 上，性能差一大截，还容易被误判成驱动问题。
驱动层要记的是每张卡当前用的驱动版本号、驱动日期、提供商、INF 名称、签名状态。这些信息在设备管理器的驱动详情里都能看到，但一张卡一张卡点太慢，用一条命令批量导出更省事：
Get-CimInstance Win32_VideoController | Select-Object Name, DriverVersion, DriverDate, PNPDeviceID, VideoProcessor, CurrentHorizontalResolution, CurrentVerticalResolution, Status输出里 PNPDeviceID 那一列最关键，它是设备的唯一身份标识，格式大致是“PCI\VEN_xxxx&DEV_xxxx&SUBSYS_xxxxxxxx&REV_xx...”这样子。后面做交叉验证、比对清理前后差异，全靠这个字段对齐。建议把输出重定向到文件存起来，命名为“清理前_日期.txt”。
配置层记录的是显示拓扑和每应用的显卡偏好。显示拓扑包括每台显示器接在哪张卡的哪个输出口、分辨率、刷新率、缩放比例、主显示器是哪台。每应用的显卡偏好可以在系统设置的图形选项里看到，也可以从注册表里导出。这部分在清理后会被重置，不记下来就没法还原。
3.2 驱动包与还原点的双保险
回滚手段我一般准备两套，因为它们的失效场景不同。
第一套是系统还原点。创建之前先确认系统保护在这个盘上是开启的，很多人装完系统第一件事就是关掉系统保护省空间，等到需要回滚时才发现没得回。创建时给个明确的名字，比如“多卡检查_清理前”，别用系统自动生成的默认名，过两天你根本分不清哪個是哪個。还原点的局限是它依赖卷影副本，如果磁盘空间紧张，旧的还原点会被自动清理掉，所以检查期间别做大文件操作。
第二套是驱动包手工备份。把当前驱动安装包从系统里提取出来存到外部介质。提取可以用命令行工具直接从驱动存储区导出：
# 列出所有第三方驱动包 pnputil /enum-drivers # 找到显示类的那几个，记下发布的名称（形如 oem12.inf） # 然后导出到指定目录 pnputil /export-driver oem12.inf D:\driver_backup导出的目录里会有 INF 文件、SYS 文件、CAT 签名文件，整套齐全，回装时直接用设备管理器的“从磁盘安装”指向 INF 就能装回去。这个办法比去官网重新下载靠谱，官网上的旧版本经常下架，尤其是工作站显卡的长周期版本驱动。
注意：导出驱动包要在清理之前做，而且要在正常模式下做，安全模式下部分驱动存储区的访问权限会受限。
3.3 显示输出与供电策略的书面记录
多卡平台的显示输出是个容易被忽略的变量。同一台机器，显示器接在 A 卡的接口上和接在 B 卡的接口上，系统启动时的主显示设备可能不同，进系统后的默认拓扑也不同。做兼容性检查时如果不固定接线方式，前后两次测试的结果没法对比。
我的做法是画一张简单的接线表，记下每个输出口接了什么、走哪张卡。检查期间保持不变，只有在专门测试输出口相关问题时才动。
供电这块记三项：电源额定功率、每张卡的辅助供电接口接法、笔记本的话记录适配器功率和电池状态。多卡满载时功耗会顶到电源上限，如果电源余量不足，表现可能是渲染中途掉驱动、系统无预警重启、某张卡从设备列表里消失——这些症状极易被误判成驱动兼容性问题。我遇到过一次“双卡跑压力测试必崩”的案例，折腾了两天驱动，最后发现是电源带不动，换了电源一切正常。
笔记本还要额外记录一下当前用的是电池还是适配器，以及系统的性能模式设置。部分机型在电池模式下会自动禁用独显，这时候你测出来的“独显不工作”根本不是驱动问题。
4. 完整操作链路：从卸载到逐卡交叉验证
前面都是准备工作，这一章是具体动作。整套流程我跑过几十次，步骤顺序是有讲究的，调换顺序会导致结果不可比。
4.1 第一轮清理的顺序与选项勾选
进安全模式之前，先把该做的准备做完：拔网线或禁用无线网卡、确认还原点已创建、确认驱动包已导出、关闭所有可能自动更新驱动的服务。这些做完再重启进安全模式。
DDU 启动后，界面上几个关键选项需要按场景勾选，我把常用组合整理成表：
| 选项 | 混合平台 | 双独显平台 | 说明 |
|---|---|---|---|
| 选择设备类型 | 仅独显 | 逐张清 | 混合平台千万别碰核显 |
| 清理后动作 | 重启 | 重启 | 必须重启，不能选“不重启” |
| 阻止系统自动装驱动 | 勾选 | 勾选 | 防止清理完被推回旧驱动 |
| 移除显示器驱动 | 视情况 | 视情况 | 排查色彩/EDID问题时才勾 |
| 移除显卡音频组件 | 勾选 | 勾选 | 音频组件残留会干扰 HDMI 输出 |
| 创建还原点 | 可选 | 可选 | 前面已经手动建过就不用重复 |
清理顺序上，混合平台先清独显，清完重启，进系统确认内屏还能亮（靠核显），再决定要不要动核显。双独显平台按厂商分批，一轮一家，每轮之间必须重启。
有个细节值得单独说：清理过程中进度条走到某一步会停住几十秒，这是正常的，它在删驱动存储区里的大文件。这时候千万别强行结束进程，中断的清理比不清理更糟，因为注册表项删了但文件还在，系统会进入一种半残状态，下次装驱动时报错信息会非常误导人。
清理完成后 DDU 会提示重启，重启前它会自动把系统的驱动自动更新策略改成“不自动下载驱动”。这个策略在检查结束后要记得改回来，不然以后你插个新设备系统都不会自动找驱动了。
4.2 裸机启动后的验证清单
重启后进入的是裸机状态，这时候系统用的是基础显示驱动。这一步的验证目标很明确：确认硬件本身没问题。
第一项，看所有卡是否被系统枚举到。打开设备管理器，显示适配器下应该出现所有物理卡，名称是“Microsoft 基本显示适配器”这类通用名称，数量要和清理前一致。少了一张，说明清理过程动了不该动的东西，或者那张卡本身有问题，换个插槽再试。
第二项，看设备状态。每个条目都不应该有黄色感叹号或者错误代码。如果有，右键看属性里的错误信息，错误代码能定位大方向：代码 43 通常是驱动加载失败，代码 10 是设备无法启动，代码 12 是资源冲突（多卡平台常见于地址空间分配不足，需要去固件里开 Above 4G 解码）。
第三项，看显示输出。把显示器逐个接到每个卡的每个输出口上，确认都能点亮、分辨率正常。笔记本的话确认内屏和外接都正常。这一步能快速筛掉接口故障和线材问题。
第四项，看系统日志。事件查看器里的系统日志，筛选来源为显示相关组件和内核即插即用相关的条目，看有没有反复出现的错误。裸机状态下如果还有大量报错，说明问题在更深层，可能是固件或者硬件。
这四项全过，才进入下一步装驱动。有一项没过，先解决它，别急着往下走。
4.3 逐卡回装与交叉验证矩阵
驱动回装的原则是一次只引入一个变量。先把独显 A 的驱动装上，重启，验证；再装独显 B 的驱动，重启，验证；最后验证两套驱动共存时的行为。
单卡验证阶段，每张卡都要过一遍这几个测试项：桌面正常输出、多显示器识别、视频硬解正常（播放高码率视频看 CPU 占用）、3D 负载正常（跑个压力测试看帧率和稳定性）、睡眠唤醒后不黑屏、设备管理器无报错。这六项过完，这张卡就算单独可用。
共存验证阶段才是真正的兼容性检查，测试项要覆盖跨卡行为：
| 测试项 | 操作方法 | 正常表现 | 异常含义 |
|---|---|---|---|
| 拓扑切换 | 在系统设置里切换主显示器、切换复制/扩展模式 | 切换流畅，无闪烁黑屏 | 两卡驱动对拓扑管理有冲突 |
| 睡眠唤醒 | 待机 5 分钟后唤醒 | 所有显示器正常点亮 | 唤醒时序问题，常见于混合平台 |
| 负载切换 | 从一个卡上的应用拖到另一个卡的显示器上运行 | 渲染正常，无掉帧崩溃 | 跨卡渲染上下文共享失败 |
| 热插拔 | 外接显卡拔掉再插上 | 系统重新识别，驱动自动加载 | 枚举残留或热插拔策略问题 |
| 混合输出 | 同一应用跨两卡的多显示器窗口 | 画面正常，无撕裂 | 合成器在两卡间的协调问题 |
每一项都要记录结果，哪怕是“正常”也要记。异常的要记下具体现象、出现时机、能否复现。这些记录后面排查时是唯一的依据。
交叉验证里有个特别容易漏的测试：把主显示器从 A 卡换到 B 卡，然后重启。有些兼容性问题只在“启动时主显示设备是哪张卡”这个条件下才暴露，运行中切换反而不出问题。这个测试做一次，能筛出一批隐藏的固件层问题。
4.4 把结果整理成可复用的记录表
整套流程跑完，最后要产出一份记录。这份记录的价值在于：下次同样的机器再出问题，你不用从零开始猜。
记录表我一般包含这几列：卡标识（用设备实例 ID 的后几位区分）、PCIe 位置、驱动版本、单卡测试结果、共存测试结果、异常描述、处理动作。用表格工具或者纯文本都行，关键是格式固定，前后能对比。
有了这份记录，下次遇到“更新驱动后某张卡不输出了”，你翻出来一看，上次这个组合的共存测试本来就有隐患，直接定位。没有记录的话，又得从头清一遍。
5. 实测中最容易翻车的五个场景
前面讲的是标准流程，实际干活时真正耗时间的是各种意外。这一章把踩过的坑摊开说，每个都给出排查链路，而不只是结论。
5.1 核显被清后内屏点不亮
这是混合平台最高频的事故。现象很典型：清理完重启，笔记本内屏全黑，但外接显示器能正常显示。很多人第一反应是硬件坏了，其实只是核显驱动被清掉了。
排查链路是这样的。第一步，确认外接能显示，说明系统本身在运行，不是彻底死机。第二步，在外接显示器上打开设备管理器，看显示适配器下有几个设备，如果只剩下独显的通用名称或者干脆只剩一个未知设备，基本可以确认核显驱动没了。第三步，去注册表看显示适配器类下的子键，核对核显对应的那个子键是不是被清掉了。
修复方法有两种。如果之前导出过驱动包，直接用设备管理器指向备份的 INF 安装，重启即可。没有备份的话，去笔记本厂商的支持页面下载对应型号的核显驱动，注意要下载厂商定制版而不是公版，笔记本的核显驱动经常有厂商定制内容，公版装上可能出现亮度调节失效、外接输出异常等衍生问题。
预防上，DDU 清理时一定要看清楚选择的是哪个厂商。部分版本的选择界面会把同一台机器上的所有显示设备都列出来，勾错一个就中招。我现在的习惯是清理前先把核显的设备实例 ID 抄在便签上贴在屏幕边，清理时逐一核对。
5.2 同厂商双卡只清掉一张
这个坑的隐蔽之处在于表面看起来成功了：设备管理器里两张卡都变成了通用显示适配器，驱动版本也对得上。但装新驱动之后，总有一张卡表现异常，要么版本对不上，要么频繁报错。
完整的排查过程是这样的。第一步，装完新驱动后记录两张卡的实际驱动版本和 INF 名称，如果不同，说明其中一张没有匹配到新驱动。第二步，进注册表看显示适配器类分支，正常情况下装完驱动后应该只有两个有效子键，如果多出来一个带旧 INF 路径的，那就是残留。第三步，用系统的驱动包查询命令列出所有驱动包，看有没有两个版本的显示驱动包同时存在，如果有，旧的那个就是罪魁祸首。
处理方式是手动删掉残留。删之前先确认那个驱动包没有设备在用：设备管理器里右键对应设备，看驱动详情里的 INF 名称，和工作列出的一一对应，确认没被引用的才能删。删除用命令行的驱动包删除指令，加强制参数，删完重启。
这个坑的根因在于同厂商同型号的双卡共享同一份 INF，系统在匹配时可能把两张卡都关联到同一份驱动包，但清理时只解除了其中一张的关联，另一张的关联还挂在旧包上。要彻底避免，清理后手动核对注册表这一步不能省。
5.3 系统自动回推旧驱动覆盖新装
清理完装好新驱动，用两天一切正常，第三天开机发现驱动版本变回了旧的。这是系统的驱动自动更新在背后干活。
排查时先看更新历史，确认是不是通过更新通道推下来的。再看驱动包的安装时间，如果新装的驱动包还在驱动存储区里，只是设备关联被改了，那就确认是回推。
处理分三层。第一层是临时措施，装完驱动后立刻把系统的驱动自动获取关掉，具体在系统属性的硬件设置里，把设备安装设置改成“否，让我选择要执行的操作”。第二层是清理回推下来的旧驱动包，用前面的方法删掉。第三层是根治，把那张卡的硬件 ID 加到“不自动安装驱动”的排除列表里，这样系统就不会再给它推驱动了。
这个问题的坑在于它有延迟，不是清理完立刻出现，而是等你以为万事大吉的时候给你一下。所以做兼容性检查时，验证阶段至少要跨一次系统更新周期，或者主动触发一次更新检查看会不会被覆盖。
5.4 固件层设置导致的第二张卡降速
表现是双卡都装好驱动、都正常识别，但跑分或者实际负载时第二张卡性能明显偏低，只有正常值的一半甚至四分之一。
这类问题最容易走弯路，因为从操作系统层面看一切正常，驱动没问题、设备没报错、温度功耗也正常。我当时排查了两天才想到去看链路宽度。
排查方法是用系统信息工具导出 PCIe 设备报告，看每张卡协商出来的链路宽度和速率。正常应该和插槽规格一致，如果明显偏低，就是固件层的问题。
常见的三个原因：一是固件里的通道拆分策略，某些主板在插满卡时会把通道拆成 x8+x8，如果卡本身要求 x16 才能满速，性能自然打折；二是 Above 4G 解码没开，大显存卡在地址空间不足时会降级运行；三是 Resizable BAR 相关设置，多卡环境下这个特性的表现差异很大，有的组合开了反而更慢。
处理方式就是进固件设置逐项调整，每调一项测一次。这个活没捷径，只能试。建议调之前把原始设置拍照记录，改坏了能退回去。
5.5 硬件加速GPU计划与多卡共存
系统里有个跟显存管理相关的特性开关，单卡机器上开了通常没坏处，多卡机器上就未必了。我在几台双卡机器上遇到过开启后出现的画面撕裂、切换黑屏、某些应用启动崩溃。
这类问题的排查要从“关掉它试试”开始，因为它的影响面很广但症状不指向具体原因。关掉之后重启，把之前的测试项重跑一遍，如果症状消失，基本就锁定了。
要注意的是这个开关的状态在系统更新后可能被重置，所以检查记录里要记下它的状态。长期方案是保持关闭，除非你有明确的应用需要它。
6. 把流程脚本化：命令行清理与状态采集
手工点鼠标做一两次还行，做十次就受不了了，而且每次的判据可能不一致。把可脚本化的部分抽出来，能显著提高效率和结果的可比性。
6.1 pnputil 与 DISM 的分工
两个工具都能管驱动包，但职责不同，混用会出问题。
驱动包枚举和删除用 pnputil 更合适，它直接面向驱动存储区，输出格式清晰，支持按 INF 名称精确操作。典型用法是先枚举出所有第三方驱动，人工筛出显示类的几个，再逐个删除。删除时要注意参数选择：不带卸载参数只删驱动包本身，带卸载参数会同时尝试卸载使用它的设备。多卡环境下我倾向于先只删包，再手动处理设备关联，这样过程可控。
DISM 更偏向系统映像层面的驱动管理，它的优势是能给出驱动包的详细信息，包括原始来源和签名状态。用它的查询功能做核对很方便，删除功能则相对粗暴，可能连带影响其他设备。
实际流程里我是这么分工的：用 DISM 查全量列表做交叉核对，用 pnputil 做实际删除。删除前把要删的 INF 名记到文本文件里，删完再查一遍确认这些名字都没了，形成闭环。
6.2 一份可复用的状态采集脚本
下面这段脚本我每次检查都用，它把关键信息一次性收到一个文件里，前后对比很方便：
$stamp = Get-Date -Format 'yyyyMMdd_HHmm' $out = "D:\check\state_$stamp.txt" "=== 显示适配器 ===" | Out-File $out Get-CimInstance Win32_VideoController | Select-Object Name, DriverVersion, DriverDate, PNPDeviceID, Status | Format-List | Out-File $out -Append "=== 驱动包（显示类）===" | Out-File $out -Append pnputil /enum-drivers | Out-File $out -Append "=== 显示适配器类注册表子键 ===" | Out-File $out -Append Get-ChildItem 'HKLM:\SYSTEM\CurrentControlSet\Control\Class\{4d36e968-e325-11ce-bfc1-08002be10318}' | Where-Object { $_.PSChildName -match '^\d{4}$' } | ForEach-Object { $p = Get-ItemProperty $_.PSPath "$($_.PSChildName) | $($p.DriverDesc) | $($p.InfPath) | $($p.MatchingDeviceId)" } | Out-File $out -Append "=== 隐藏设备（显示类）===" | Out-File $out -Append Get-PnpDevice -Class Display -Status Error, Unknown, Degraded | Select-Object FriendlyName, InstanceId, Status | Format-List | Out-File $out -Append脚本跑完会生成一个带时间戳的文件，清理前跑一次，清理后跑一次，装完驱动再跑一次，三份文件一对比，哪一步改了什么一目了然。
注册表那一段是关键，因为设备管理器的显示是经过美化的，实际状态要看注册表。子键编号从 0000 开始，正常情况下有效子键的数量应该和物理卡数量加一（多出来那个是基础显示驱动）。数量对不上，就有残留或者漏装。
6.3 清理前后的差异比对
有了三份状态文件，比对就能得出客观结论。我一般关注四组差异。
第一组是驱动版本差异。清理后所有卡应该都变成基础显示驱动的版本，装完新驱动后应该统一变成新版本。如果装完还有卡停留在旧版本，说明匹配失败。
第二组是驱动包数量差异。清理后显示类的驱动包应该清空或者只剩系统自带的，装完新驱动后应该只剩一份新的。数量偏多说明清理不彻底。
第三组是注册表子键差异。子键的编号和内容都要看，编号错乱说明有历史残留没清掉。
第四组是隐藏设备差异。清理前可能有若干条隐藏的显示设备，清理后应该减少。如果没减少，说明幽灵设备没处理。
这四组差异全部符合预期，才算清理环节真正完成，可以进入兼容性验证阶段。任何一组不符合，先解决再往下走。
7. 回装顺序与长期维护的几个做法
驱动回装的顺序对多卡平台的稳定性有实际影响，不是随便装完就行。
我的经验是先装核显再装独显，或者先装主输出卡再装副卡。原因是系统在装第一套驱动时会建立显示拓扑的基础框架，后面装的驱动是往这个框架里填内容。先装的那套会占据“主显示适配器”的位置，后装的作为补充。反过来装的话，某些版本组合下会出现主显示设备识别错误，表现为开机时画面出现在意料之外的显示器上。
双独显平台同理，先装你打算作为主输出的那张。
装完每套驱动后立刻重启，别连着装两套再一起重启。连着装的话，两套驱动的安装程序可能同时修改系统状态，冲突概率高。
长期维护上有几个习惯值得养成。一是每次系统大版本更新后重跑一次状态采集，看驱动有没有被替换。二是保留一份导出好的驱动包在外部介质上，尤其是那些已经下架的老版本。三是记录表持续更新，每换一次驱动组合就加一行。
我个人在实际操作中的体会是，多卡机器的绝大多数“兼容性问题”最后都能归结到三个源头：驱动残留、固件设置、供电或通道限制。Display Driver Uninstaller 能解决第一个，但前提是你真的把它当成一次受控清理来做，而不是当成一个碰运气的按钮。清理前花在记录和备份上的时间，和后面省下来的排查时间完全不成比例。还有一个容易忽略的小技巧：每次做重大变动之前，给机器拍一张系统盘的完整镜像，用系统自带的镜像备份功能就行，这东西比重装系统快得多，比还原点可靠得多，我现在的标准动作是变动前镜像、变动中记录、变动后验证，三步走完心里才踏实。
