投稿_正文_WorkBuddy实战案例

WorkBuddy 实战｜Windows 反复蓝屏排查：从事件日志到驱动包指纹的完整取证流程

行业与岗位：个人投资 / 自由职业者，自行维护一台 Windows 11 工作机（场景归类：通用办公 · IT 自运维） 话题标签：#WorkBuddy #AI办公

背景：一台会自己"卡死重启"的工作机

我的主力工作机（AMD Ryzen 7 7800X3D + Radeon RX 7900 XTX，Windows 11 23H2）从 8 月底开始反复出现"画面卡死、几秒后自动重启"。三周里累计出现 26 次显示驱动超时（TDR），3 次蓝屏（0x9F ×2、0xB4 VIDEO_TDR_FAILURE ×1）。

因为磁盘上跑着交易数据资料，我没有直接重装系统，而是想先把根因查清楚。但这类问题的难点在于：Windows 不会主动告诉你驱动到底有没有真的换掉——它只会给你一个看起来没变的版本号和一堆报错。

这次我用 WorkBuddy 完成了从"取证"到"核验"的全过程。下面把配置、Prompt 和每一步命令都写清楚，同类问题可以直接照做。

一、输入材料

交给 WorkBuddy 的材料分三类：

1）现场交办说明（一句话）

这个措辞是关键，后面第五部分会讲为什么。

2）本机系统取证源（授权读取本地文件后，WorkBuddy 自行打开）

3）厂商侧材料：AMD 官方 Adrenalin 安装包（887MB）及其 Install Manager 自检日志。

二、WorkBuddy 配置

• 工作模式：全程 Agent（Craft）模式。取证需要连续执行命令、读取多个日志文件，Ask 模式做不了。
• 权限：授权读取工作目录与系统目录。取证阶段只读即可完成；涉及修改的动作（禁用设备、改注册表、删转储）由我逐项确认后才执行。
• Skill：把这次排查流程沉淀成了一个自定义 Skill（windows-bsod-tdr-diagnosis），下次同类问题直接调用，不必重新描述背景。
• 关键 Prompt（原样可用）：

第 4 条和第 5 条是最值钱的两条——前者逼 AI 自证，后者把"结论"变成"可执行的清单"，而不是停在"建议重装驱动"这种废话上。

三、操作步骤

步骤 1：先确认有没有蓝屏，别听转述

事件 41 = 非正常关机，1001 = BugCheck（蓝屏）。第一次运行就拿到了完整蓝屏历史：9/15 0x9F、9/16 0x9F、9/17 0xB4。

步骤 2：把 TDR 事件按天分组，判断是"偶发"还是"规律"

统计出 26 条 Display 事件（4101 驱动停止响应 / 4109 已阻止某程序访问图形硬件）。

这一步的价值在于给问题定性：规律一出来，方向就从"运气不好"变成"某个组件在稳定地出问题"。本例的规律是——连续 3 次 TDR 之后，必有一次蓝屏。

步骤 3：检查硬件层有没有报错（排除法）

WHEA 日志为空 = 没有 CPU / 内存 / PCIe 层面的硬件报错。这一条把范围从"硬件可能坏了"收窄到"驱动或软件层"，省掉大量无谓的硬件测试。

步骤 4：从转储里揪出具体驱动模块（不装 WinDbg 也能做）

用纯 PowerShell 提取转储中的可打印字符串，能拿到驱动包与 VBIOS 版本号，不需要安装调试器。

步骤 5（核心）：三步验证"驱动到底换没换"

这是本次最有价值的部分。

先说一个坑：Windows 给出的 DriverDate 是驱动包的打包日期，不是安装日期。 我就是被这个数字骗过一轮，先入为主地判断"驱动太旧，换个新版就好"。真实的安装日期要看驱动库目录的创建时间。

三步自证法：

① 看 Windows 驱动安装日志的导入结果

关键行：Outcome - Already Imported。含义是包内容与已安装的逐字节相同，Windows 直接复用，没有真正导入任何新文件。

② 看驱动库文件夹的创建时间

如果显示驱动包的 CreationTime 是三周前，说明今天没有新建任何显示驱动包。

③ 看包内 INF 的指纹

INF 第二行是厂商内部的发布指纹（形如 2608172034-26.10.41.01-260811a-203304C-AMD-Software-Adrenalin-Edition），与已安装版本比对，一致即同源。

附一个映射关系：厂商内部版号 26.10.41.01-260811a... ↔ 官网营销版号 26.8.1 ↔ Windows 驱动版本 32.0.31041.1004。三者指的是同一个包——别把它们当成三个不同的版本。

三条证据合起来，结论是：今天跑的是"同版本干净重装"，不是升级。 这个结论直接改变了后续决策——不能再指望"换个新版本就好了"。

步骤 6：判断"长期问题"到底有多长

结果：Windows 装于 8/29 15:19，驱动 15:39 装上，首次 TDR 是 16:11——装完驱动仅 32 分钟。

这一步把原先"这是个持续三个月的老毛病"的判断彻底推翻：它其实只有 3 周，而且全部发生在"这套全新系统 + 这一版驱动"的组合上。

结论的价值在于：它同时排除了"系统老化、多年积攒的垃圾配置"这类解释，让"驱动本身"和"硬件供电"成为仅剩的两条主线。

四、产出物

WorkBuddy 交付了三份可直接使用的东西：

1. 《显卡驱动干净重装操作清单》——准备阶段（关闭 Windows 自动驱动更新、断网、校验官方包数字签名）、分步点击路径、失败后的备选方案、以及"装崩黑屏"时的硬件级应急恢复路径
2. 《驱动问题核查结论与下一步方案》——证据链、时间线修正、三条候选路线（观察 / 换驱动版本 / 硬件三查）
3. 一个可复用 Skill——把整套取证流程固化，下次同类问题一键调用

"产出可验收"的标准我定成两条：

• 清单里每个动作我都能实际执行，且标注了风险等级
• 每个可逆操作都附带回退命令。例如禁用虚拟显示适配器的同时给出恢复命令：

五、这次实践里最值得分享的三点

1. 让 AI 先自证，再下结论。 Prompt 里加上"给我能自证的证据，不要看版本号下结论"，逼出了三条相互独立的证据。AI 第一轮确实判断错了（把打包日期当安装日期），是它自己在后续取证里推翻的——这个自我纠错的过程，比结论本身更有价值，也是判断一个 AI 工作台靠不靠谱的关键。

2. "查日志，不猜"这五个字，值得写进每一次排障的 Prompt 里。 排障类任务最怕的是拿到一份"可能是内存、可能是驱动、可能是电源"的清单，等于没查。明确要求引用具体日志行、具体事件 ID，输出质量会完全不同。

3. 把结论变成清单，而不是建议。 "建议重装驱动"和"点这里、勾这个、装崩了把显示器线插到主板视频口"之间，差的是一整份操作清单。前者是回答，后者才是交付。

六、适用场景

这套流程（事件日志取证 → 转储模块提取 → 驱动安装核验 → 时间线还原）不限于显卡驱动，同样适用于：

• 某个软件反复崩溃、但重装无效
• 系统更新后出现异常，想确认更新是否真的生效
• 判断某个"老毛病"到底是长期问题还是最近才引入（对应步骤 6）
• 任何需要回答"这个东西到底有没有被真正替换掉"的场景

核心方法可以概括成一句话：不要相信版本号，去验证字节。