![01-AMD显卡蓝屏取证.png](https://developer.qcloudimg.com/http-save/yehe-12897994/f9a89955e13dce07ef172ccd67ab4bdc.png)![02-AMD显卡蓝屏取证.png](https://developer.qcloudimg.com/http-save/yehe-12897994/ff3003f4cc370a6a6baa68732cbc938d.png)![03-AMD显卡蓝屏取证.png](https://developer.qcloudimg.com/http-save/yehe-12897994/92a0792a1ec18efaf689477bcd43c123.png)
> 一台双显卡老笔记本（Lenovo IdeaPad 310S-15IKB，AMD R5 M330 + Intel HD 620）反复蓝屏，错误码 0x116 VIDEO_TDR_FAILURE 和 0x1A MEMORY_MANAGEMENT 各出现一次。
>
> 这篇复盘记录我是怎么用 WorkBuddy 把它一步步查到"根因候选只剩一个"的全过程，以及中间踩过的坑——包括两个让我一开始判断完全错误的误判。
>
> 全程只做只读取证，不做猜测性改动。

---

## 一、先说结论（如果你只想看结果）

最终定位到的关键事实是：

**AMD 官方发布的 Legacy 22.6.1 驱动包内部，同时包含两个 Display 驱动 INF，而 Windows 默认装上的那个，是面向特定 OEM 机型定制的旧版。**

| INF | 性质 | 目标 Windows 版本区间 | 硬件特性分支数 |
|---|---|---|---|
| `U0382934.inf` | OEM 机型定制版 | 止于 `NTamd64.10.0...16299` | 0 条 R503DS 分支 |
| `C0382934.inf` | AMD 官方通用版 | `NTamd64.10.0.1..14310` | **74 条 R503DS 分支** |

而我的机器上当时装的是 `U0382934.inf`，**`C0382934.inf` 从来没被装过**。


这里有一个反直觉的点，值得单独拎出来：

> **两个 INF 里的内核驱动二进制（`amdkmdag.sys`）是逐字节完全相同的。**
> SHA256：`09B6D2873495066F500CA72D0CEBE217579B0C6F2D1BA776841EC40FC22A318D`
> —— 我拿"驱动包内原件 / 系统已装文件 / 换机前导出的备份"三份做了哈希对比，**三者完全一致**。

所以问题**不是"装了第三方打包版"或"装了有毒版本"**，而是 **INF 元数据层面的差异**：硬件 ID 分支表、Windows 版本目标区间、特性开关、注册表项。

这直接推翻了我最初的两个判断，下面会说。

---

## 二、为什么不能用"感觉"下结论：我的两个误判

### 误判一：把 OEM 包当成"未认证匹配路径"

我最初看到 INF 里没有本机 `SUBSYS_398917AA` 的专属条目，就判定"这是 AMD 官方通用包跑在联想定制机型上，属于未认证路径，稳定性无保障"。

**错了。** 联想定制包本身也只提供通用条目 `DEV_6660&REV_83`，本机照样走通用匹配。**用"有没有本机 SUBSYS 专属条目"判断认证级别是无效方法。**

正确判断依据是 **INF 的来源形态**：
- `u+8位数字.inf`（联想 machine code 命名）→ OEM 定制包
- `ati2mtag` / `iigd_dch` / `cu_dch` 等 → 厂商官方通用包

### 误判二：把 DDU 当成"能修复残留污染"的最后手段

当时我以为系统里还残留着旧版 fence 驱动没清干净，DDU 清理就是治本尝试。

**也错了。** 我把安装包内的 `amdfendr.sys` 和系统里那份做了逐字节比对：

```
包内: 21.10.0.7 | 2022-02-22
已装: 21.10.0.7 | 2022-02-22
```

版本号与原始时间戳完全一致 —— 它是安装包的正版组件正常部署，**不是残留**。

**也就是说，DDU 能修的"脏东西"本来就不存在**，它能做的只是把一次覆盖安装换成一次彻底重装。而这恰恰是这个案例里唯一还没试过的变量，所以 DDU 依然值得做 —— 但我不能再用"清残留"来解释它的价值。

### 一个取证纪律

上面两个误判如果没被实测数据拦下来，会直接把后续方案带偏（我会去建议装一个早就装过的包）。

我在处理这类问题时的做法是：**任何"我记得上次是……"都必须去原始记录里取证，不能靠印象判断。**

我让 WorkBuddy 检索了本机 20+ 个历史会话存档（`~/.workbuddy/projects/*.jsonl`），交叉验证 `bcdedit` / `bcdboot` / `bootcfg` / BCD 注册表写入等所有可能入口。结果：全部会话中 `bcdedit` **只出现 `/enum` 只读命令，没有任何一条 `/set` 或 `/deletevalue` 写操作**。

用户记忆中"改了启动参数导致系统起不来"这件事，在记录里找不到对应的写操作。

---

## 三、真正的取证链（可复用的方法）

### 第 1 步：建立时间线，而不是看单个事件

`DriverStore\FileRepository` 下每个驱动包目录的**创建时间**，直接标出了每批驱动的来源：

```
11-10 20:45~20:47  →  780 个包   ← 装系统/恢复映像时的批量 PnP 部署
11-10 22:18         →  1 个      ← 系统自动
11-10 23:01~23:05   →  4 个      ← netwtw04 / rt640x64 / synsmbdrv / hdxrt4
11-11               →  55 个     ← Windows 内置
11-12               →  9 个      ← Intel 核显 GUI 安装包
11-14               →  3 个      ← DDU 重装
```

一行命令拿到全局：

```powershell
Get-ChildItem 'C:\Windows\System32\DriverStore\FileRepository' -Directory |
  Where-Object { $_.Name -match '\.inf_' } |
  Group-Object { $_.CreationTime.ToString('MM-dd HH:mm') } |
  Sort-Object Name | ForEach-Object { "$($_.Name) : $($_.Count) 个包" }
```

### 第 2 步：逐字节比对，区分"文件"和"元数据"

这是整个案例的转折点。**不要只看版本号字符串，要算哈希。**

```powershell
# 驱动包内原件 vs 系统已装文件
Get-FileHash '包内\...\amdkmdag.sys' -Algorithm SHA256
Get-FileHash 'C:\Windows\System32\DriverStore\FileRepository\...\amdkmdag.sys' -Algorithm SHA256
```

同一个哈希，说明它们是同一份文件的两次部署。

**这一步直接洗清了"装了非官方打包版"的嫌疑** —— 如果只看版本号 `27.20.20913.2000`，你根本分不清它来自 AMD 官方包还是 OEM 二次打包。

### 第 3 步：打开驱动包本身看里面到底有什么

这一步很多人会跳过，结果错过了唯一的关键线索。

```powershell
Get-ChildItem 'G:\...\LegacyASICs\Packages\Drivers\Display\WT6A_INF\' -Filter *.inf |
  Select-Object Name, Length
```

输出两个 INF：`C0382934.inf` 和 `U0382934.inf`。

然后逐个提取关键字段：

```powershell
# OS 目标区间
Select-String -Path $inf -Pattern '^\[Manufacturer\]' -Context 0,5
# 硬件分支
Select-String -Path $inf -Pattern 'ati2mtag_R503DS' | Measure-Object
```

**C 版有 74 条 R503DS 分支，U 版 0 条。** C 的 Windows 目标区间也更适配现代 Win11。

再确认当前系统装的是哪个：

```powershell
Get-CimInstance Win32_PnPSignedDriver |
  Where-Object { $_.DeviceID -match 'VEN_1002' } |
  Select-Object DriverVersion, InfName
# → oem3.inf
```


然后把 `C:\Windows\INF\oem3.inf` 和包里的两个 INF 做哈希三连：

```powershell
Get-FileHash 'C:\Windows\INF\oem3.inf' -Algorithm SHA256
Get-FileHash '包内\C0382934.inf' -Algorithm SHA256
Get-FileHash '包内\U0382934.inf' -Algorithm SHA256
```

**结果：oem3.inf == U0382934.inf。**

至此，结论闭合：**装的是 OEM 定制版，官方通用版从未被装过。**

### 第 4 步：验证两个 INF 是否共用同一套二进制

```powershell
Select-String -Path $inf -Pattern 'DS.Graphics'
# 两个 INF 都是 → 13, B381983（同一个二进制目录）
```

同一个目录 → 同一套文件 → **换 INF 不是换驱动版本，是换一份元数据**。

这一条决定了后续方案的合理边界：换 C 版 **不会** 引入新版本的新 bug，也 **不会** 修复版本过旧的问题，它只改变 INF 层面的匹配与开关。

---

## 四、坑清单（这部分可能比结论更有用）

### 坑 1：静默安装参数对 NSIS 安装器不生效

我用的是 NSIS 打包的安装器，`-o` 静默解压参数完全没反应：

```powershell
& 'xxx.exe' -o'D:\some\dir' -y     # 无效
```

正确写法是 NSIS 的 `/S` + `/D=`（注意 `/D=` 必须放最后、无引号）：

```powershell
Start-Process -FilePath 'xxx.exe' -ArgumentList '/S','/D=D:\some\dir' -Wait
```

即使这样，它也可能**无视 `/D=` 落到默认路径** —— 所以务必安装后回查实际落盘位置，别以为装失败了。

### 坑 2：清理类工具会抹掉你的取证链

我用过的某个"系统垃圾清理"工具清掉了 System 日志和 `setupapi.dev.log` 里 11-13 的段落，导致**当天的驱动安装记录全部丢失**，我一度无法确认那次到底装了什么。

**建议：从现在开始，不要用任何清理工具清 System / Setup 日志。** 需要清理就用 Dism++ 或系统存储感知，并且不要勾选"系统日志"这一项。

### 坑 3：别把"装的是同一个版本"和"这个工具有用"混为一谈

我用某第三方驱动工具（Ashampoo Driver Updater 2.6.2）做交叉验证，它扫描出 7 个待更新项。我把它的数据库版本号拆成五段做数值归一化对比：

| 设备 | 系统已装 | 工具库记录 | 结论 |
|---|---|---|---|
| AMD R5 M330 | 27.20.20913.2000 | 27.20.20913.2000 | ✓ 数值完全相同 |
| Intel HD 620 | 31.0.101.2145 | 31.0.101.2145 | ✓ 相同 |
| Intel ME | 2240.3.4.0 | 2240.3.4.0 | ✓ 相同 |
| Synaptics 触控板 | 19.5.35.54 | 19.5.35.54 | ✓ 相同 |
| Realtek 有线网卡 | 10.80.407.2026 | 10.80.407.2026 | ✓ 相同 |
| Realtek 读卡器 | 10.0.14393.29093 | 10.0.14393.29093 | ✓ 相同 |
| Intel 无线网卡 | 19.51.50.2 | 17.8.1.1066 | 格式差异 |

**6 项完全同版本，它仍然全部列为"待更新"。**

这解释了一个长期困扰我的现象：这类工具每次重新扫描，都会把同样的驱动再列一遍。它不是在做真升级，而是它的版本比对逻辑有缺陷。

**推论：这类工具适合用来"拿一份整机驱动清单"，不适合让它替你做版本决策。** 拿到清单后去厂商官网下原厂包，才是对的路径。

顺带一个正面发现：该工具的排除配置文件里明确排除了 `bios` / `firmware` / `motherboard`，**不会夹带固件升级**——这是我一开始最担心的风险点，实测不存在。

### 坑 4：不要在热替换上赌显示驱动

显示驱动的内核模块 + fence 驱动 + 用户态组件是一套版本，任何变更后**必须完整重启**并核验三层版本一致：

```
已加载内核模块版本 == 磁盘文件版本 == 安装包内版本
```

热替换（不停机）会造成驱动栈版本不一致，这是真实的故障源。

### 坑 5：Agent 的工具调用也要讲成本

这个案例我一共调了 30+ 次工具，其中有几次是因为路径写错、编码猜错而重试的。**每次重试都是真金白银的额度消耗。**

后来我在长期规则里加了一条硬约束：**一次定向查询拿到结论，禁止对同一目标反复换写法试探；能一条命令拿全的数据不拆成五六条。** 改完之后效率明显好转。

---

## 五、还没做完的部分（诚实说明）

这次定位到"装错了 INF 变体"之后，**我没有立刻换**。原因：

- 我的 WinRE（Windows 恢复环境）处于 Disabled 状态，**安全模式入口不可用**，一旦换完起不来，常规"高级启动 → 安全模式"这条路是断的；
- 系统还原点虽然可用，但只保 3 个；
- 观察期刚起跑，正在验证"这次 DDU 彻底重装是否已解决问题"。

所以正确顺序是：**先让观察期跑完确认现状，再决定是否换 C0382934.inf。** 有回退件（驱动全量备份 + 安装包原件 + 还原点）才动。

**这不是拖延，是风险顺序。** 驱动类改动，尤其是引导相关，出错的恢复路径比收益更重要。

---

## 六、如果你也想做这类排查，最小命令集

```powershell
# 1. 当前显卡驱动绑定的是哪个 INF
Get-CimInstance Win32_PnPSignedDriver |
  Where-Object { $_.DeviceID -match 'VEN_1002' } |
  Select-Object DriverVersion, InfName, DriverProviderName

# 2. 驱动包安装批次时间线
Get-ChildItem 'C:\Windows\System32\DriverStore\FileRepository' -Directory |
  Where-Object { $_.Name -match '\.inf_' } |
  Group-Object { $_.CreationTime.ToString('MM-dd HH:mm') } |
  Sort-Object Name

# 3. 系统已装驱动 vs 安装包原件（关键：算哈希，别只看版本号）
Get-FileHash "$env:SystemRoot\System32\DriverStore\FileRepository\<pkg>\amdkmdag.sys" -Algorithm SHA256
Get-FileHash '安装包内\...\amdkmdag.sys' -Algorithm SHA256

# 4. 打开驱动包看里面有几个 INF
Get-ChildItem '安装包\Packages\Drivers\Display\WT6A_INF\' -Filter *.inf

# 5. 蓝屏错误码
Get-WinEvent -FilterHashtable @{LogName='System'; Id=1001} -MaxEvents 3 |
  ForEach-Object { $_.Message.Substring(0,120) }

# 6. GPU 挂起转储（0x141/0x117 挂起不一定蓝屏）
Get-ChildItem 'C:\Windows\LiveKernelReports\WATCHDOG' |
  Where-Object LastWriteTime -gt (Get-Date 'YYYY-MM-DD HH:mm') |
  Select-Object Name, LastWriteTime
```

第 6 条特别值得强调：**GPU 挂起（LiveKernelEvent 141）不一定伴随蓝屏**，只查蓝屏记录会漏掉前兆。我的案例里，首次挂起比首次蓝屏早了 6 小时 —— 如果只看蓝屏，就会误判"问题出现得很突然"，从而错过真正的第一现场。


---

## 结语

这次排查里最让我有收获的不是找到答案，而是确认了**两个我原本很确信、但被数据推翻的判断**。

在驱动问题上，"版本号看起来对"和"哈希确实一致"之间隔着一整条推理链。少走一步，就可能给出一个方向完全错误的建议 —— 比如让我去装一个两周前刚装过的包。

如果你也在做类似的排查，欢迎在评论区贴你的 DriverStore 时间线，也许我们能一起把范围缩小。

---

*本文为真实排障过程复盘，所有命令与哈希值均为本机实测输出。*


一台双显卡老笔记本（Lenovo IdeaPad 310S-15IKB，AMD R5 M330 + Intel HD 620）反复蓝屏，错误码 0x116 VIDEO_TDR_FAILURE 和 0x1A MEMORY_MANAGEMENT 各出现一次。

#WorkBuddy# 用 WorkBuddy 精准定位 AMD 显卡蓝屏：从 0x116 到挖出「官方包内藏两个驱动」的完整取证链

双显卡老笔记本反复蓝屏（0x116 / 0x1A）。我用 WorkBuddy 全程只读取证：DriverStore 时间线、事件日志、INF 与内核驱动三方哈希比对，推翻两个先入为主的误判，最终发现 AMD 官方 22.6.1 包内藏有两个 Display INF，差异只在 INF 元数据。附完整命令与三张实测截图。

操作系统

硬件

开发工具

AMD官方Legacy 22.6.1驱动包内含OEM定制与通用双INF版本，Windows默认安装U0382934.inf定制版。核心驱动二进制哈希一致，问题源于INF元数据差异。通过DriverStore时间线、哈希比对及INF分析，排除第三方打包嫌疑。排查过程中两个误判被实测数据推翻，DDU无法清除不存在的残留。完整取证链可复用，含最小PowerShell命令集。

代码解释

数据库

WorkBuddy 

Windows

Agent

WorkBuddy企业版限时双倍 Credits 活动

workbuddy

4核4G3M云服务器 新用户低至38元/年！

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

AMD官方Legacy 22.6.1驱动包内含OEM定制与通用双INF版本，Windows默认安装U0382934.inf定制版。核心驱动二进制哈希一致，问题源于INF元数据差异。通过DriverStore时间线、哈希比对及INF分析，排除第三方打包嫌疑。排查过程中两个误判被实测数据推翻，DDU无法清除不存在的残留。完...

#WorkBuddy# 用 WorkBuddy 精准定位 AMD 显卡蓝屏：从 0x116 到挖出「官方包内藏两个驱动」的完整取证链-腾讯云开发者社区-腾讯云

#WorkBuddy# 用 WorkBuddy 精准定位 AMD 显卡蓝屏：从 0x116 到挖出「官方包内藏两个驱动」的完整取证链

#WorkBuddy# 用 WorkBuddy 精准定位 AMD 显卡蓝屏：从 0x116 到挖出「官方包内藏两个驱动」的完整取证链

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐