有人拿一台机器来找我，说《燕云十六声》进不去，点图标就黑屏。9 月开始这样，中间重装过游戏、清过缓存、折腾过网络，都没用。
我先要了自检工具的输出。不用装游戏就能跑，几十 KB，双击出一个 txt：
[2] CreateDXGIFactory1（游戏枚举显卡的第一步）
返回 0x80004002 对象=0000000000000000 => 失败：DXGI 拿不到任何显卡适配器
[3] D3D12CreateDevice(Feature Level 12_0)（DirectX12 游戏必须成功）
返回 0x80070057 设备=0000000000000000 => 失败：无法创建 DX12 设备
[4] D3D11CreateDevice(硬件模式)
返回 0x00000000 最高特性级别 = 0xB000 -> 11_0（这是软件渲染 WARP 的上限，说明没吃到独显）先说结论，省得你翻到底：显卡没坏，驱动文件也没坏。坏的是「把显卡发放给新程序」这一步，而这个环节不报错。
我一开始也怀疑是显存满了
看到黑屏，下意识就往显存上想——专用显存 8G，游戏加载完吃满不奇怪。
查出来 563 MB，占用者不是游戏，是 dwm，Windows 桌面窗口管理器，系统自带的。
563 MB 打不满 8G，而且占着卡的是系统进程，不是那个黑屏的游戏。
方向错了。显存不是原因，甚至不是症状，它只证明一件事：硬件适配器还活着，有东西正在真硬件上跑。
逐行看那份自检输出
开头第 2、3 行都在报失败，但真正决定方向的是第 4 行。
第 4 行的返回值是 0x00000000。这是成功。可它后面跟了一句「最高特性级别 = 0xB000」，而括号里明写着：软件渲染 WARP 的特性级别 = 0xB000。
意思是这个「成功」是假成功。程序没拿到独显，退回 CPU 软件渲染了，接口照样返回 0。这是输出里最像烟雾弹的一行——只看返回值会以为这一步没问题。
第 5 行更直接，它列了本进程实际加载了哪些驱动组件：
[5] 本进程实际加载到的显卡驱动组件
nvwgf2umx.dll D3D11/DXGI 硬件组件 : 已加载
nvd3dumx.dll D3D9 组件 : 未加载
D3D10Warp.dll 软件渲染 : 已加载硬件组件在，软件渲染也在。两个同时加载，说明硬件层没被彻底挡死，只是没被正式授予。
我一路查下去，后面的取证全在往同一个方向收：
- 内核图形栈
nvlddmkm/DXGKrnl/BasicDisplay三个驱动，全部 Running - 设备管理器里 GTX 1080，状态 OK，错误码 0
- 系统日志本次开机没有 TDR（GPU 超时重置），没有驱动报错
- 之前报告的虚拟显卡幽灵设备（Kernel-PnP 219），这次开机一条都没有
这张表的前四层全绿，塌的是第五层：
| 层次 | 实测结果 | 判读 |
|---|---|---|
| 硬件 | 专用显存被 dwm 占用 563 MB | 活着 |
| 驱动文件 | nvwgf2umx.dll 已加载，直接加载也成功 | 没坏 |
| 内核图形栈 | 三个驱动 Running，设备管理器 OK | 没崩 |
| 系统日志 | 无 TDR、无驱动错误 | 没报错 |
| 新程序要设备 | CreateDXGIFactory1 返回 0x80004002 | 拿不到 |
前四层全绿，第五层塌了。这个组合有名字：老进程好、新进程拒、零报错。
开机最早那批系统进程（dwm、explorer）能拿到显卡，之后启动的任何新程序一律拿不到。我特意查了这两个进程的模块列表，里面都能查到 nvwgf2umx.dll——硬件加速组件在它们身上工作得好好的。
为什么怀疑到安全软件头上
驱动半损坏的样子不是这样。驱动坏了要么大家一起失败，要么设备管理器直接报错、要么日志里留下 TDR 记录。这台机器一条都没有。
按进程区别放行和拦截，是安全软件的主动防御在干的事，不是驱动会干的事。开机名单里的放行，陌生的新进程拦下来——正好对上这个故障形状。
这台机器上确实有：9 个 360 内核驱动全部 Running，另有 360elam64 是 Boot 启动级；explorer 进程里查出 7 个 360 的 DLL。
这里有个坑必须点出来：托盘里点「退出 360」不算退出。它的内核驱动开机加载加自我保护，干净启动也绕不过。想排除嫌疑只能卸载，退出、关自启都没用。
卸载完得验一遍，别凭感觉。先看内核里还挂着哪些 360 的文件：
ls C:/Windows/System32/drivers | grep -i 360
find G:/360Safe/safemon -name "*.dll"两条都该是空。目录还在、文件还在，说明卸载没干净，或者被同公司的其他软件又拉起来了。
Windows 上还有两条更直接的：
Get-Process explorer | Select-Object -ExpandProperty Modules | Where-Object { $_.FileName -match '360Safe' }
fltmc filters第一条列出 explorer 加载的所有模块，输出里不该再有 360Safe 目录下的 DLL。第二条看文件系统过滤驱动还挂着几个。
我的判断
现在还不能说就是 360 定的罪。上一轮设的 hypervisor 关闭没重启，还没验证过。但排查顺序我排好了：先重启，再卸 360，然后复测一次自检工具。四项全绿才算过——CreateDXGIFactory1 成功、D3D12CreateDevice 成功、特性级别到 0xD000 以上、D3D9Ex 拿得到硬件。
如果卸载后仍然全败，才轮到驱动安装状态，用 DDU 在安全模式里清干净重装。
有一点我确实没深究：为什么这台机器偏偏是老进程能过、新进程全拦。安全软件按白名单放行是常见做法，但白名单具体怎么定的、按什么粒度，我没有把握。这台机器 9 月以来反复装卸过 MuMu、Video2X 之类，装卸过程本身有没有在图形内核里留下半损坏状态，我也说不准。所以我只把它排到第一位，没当成定论。
这套「老进程好、新进程拒、零报错」的排查思路，和我之前处理本地程序崩溃时怎么一层层拆是同一套打法：先确认哪一层是好的，再去找塌掉的那一层。区别在于，那次至少有退出码 139 指着，这次什么都没有——所以只能靠排除法，一层层证明它没坏。
这台机器还有个背景硬伤：系统是第三方精简镜像装的，UMDF 框架被删了、组件库没有备份，sfc 修不了。最后兜底只剩官方镜像全新安装。360 那 9 个内核驱动也跟这台机器的历史对得上——9 月以来反复装卸好几个软件，它从头到尾没退过场。
我现在停在重启这一步。明天复测完就知道这个判断对不对。