Windows HLK 驱动认证（二）：开始测试

本篇承接上一篇 Windows HLK 驱动认证（一）：环境准备。默认你已经:

• Controller（WS2025 虚拟机）装好 HLK Controller + Studio；
• 测试机纯净系统、关安全启动、开测试模式、装好 HLK Client 和待测驱动；
• 三者同处一个子网、互通。

下面所有操作都在 Controller 的 HLK Studio 里进行（除特别说明外）。

在动手之前，先看清楚 Studio 里这些名词彼此是什么关系——后面每一步其实都是在填这张图里的某一层：

左右两半是分开的：机器池管"用哪台机器测"，项目管"测什么内容"，两者在 Selection 页汇合——你在某个池里挑一台机器，从它上面枚举出的设备中勾选出 Target。

一、新建机器池（Machine Pool）

机器池是测试机的逻辑分组。测试机装好 Client 后会自动落入 Default Pool，但不能直接在 Default Pool 里跑测试——必须先移动到一个自建的池并设为 Ready。

1. 打开 HLK Studio，进入 Configuration（配置） 页。
2. 右键根节点 $(Root) → Create Machine Pool，改成有意义的名字后回车。
3. 点 Default Pool，在右侧应能看到之前配置好的测试机。等它的状态变为 notready 后，把它拖动到刚新建的池中。
4. 在新池中右键该测试机 → Change Machine Status → Ready。状态列变为 Ready。

要点

• 一台机器同一时间只能属于一个池。
• 状态为 NotReady 时无法调度测试；且在 Default Pool 里无法设为 Ready，必须先移到自建池。
• 测试机刚装完 Client 时可能要等几分钟才出现在 Default Pool；如果一直不出现，回头检查 TCP 1771、SMB 共享访问和工作组账户配置（见第一篇）。
• 测试跑起来后机器会在 Running 等状态之间切换，中途手工把它改回 Ready 会打断正在跑的任务。

二、创建项目（Project）

一个 Project 定义“你要测什么”,通常对应一个要提交认证的设备/驱动。

1. 进入 Project 页 → Create project，替换默认名为有意义的项目名后回车。
2. 双击选中刚新建的 project 将其加载。

三、选择测试目标（Selection）

1. 进入 Selection 页。
2. 左上角 machine pool 下拉列表中选中刚新建的池。
3. 左侧视图选择 device manager（这是最细粒度的视图，能看到系统里的各个组件驱动）。
4. 在中间列出的 driver 列表中，勾选需要测试的 driver（目标 / target）。

一个设备可能包含多个 target。要拿认证，需选中该设备产品类型下的全部相关特性。若在 device manager 里找不到你的软件驱动，可用搜索框，或改用 software device 视图。

四、加载 Playlist 并运行测试（Tests）

Playlist 是官方规定的“该测哪些项”的测试集合。加载后，界面只保留适用于当前目标的测试项。

1. 进入 Tests 页。
2. 点 Load Playlist，选择需要测试的 OS 版本和架构的官方 playlist（一般选 x64 / arm64）。
3. 加载完成后，总测试列表会缩减为适用项。
4. 全选所有测试项，点 Run Selected 开始运行。

Playlist 本身是一个 XML 文件。HLK 安装后本机自带一份，但微软会持续更新兼容性 playlist，正式提交前应到微软 HLK 页面下载与你套件版本对应的最新 playlist，再用 Load Playlist 指向它。

重要

• Playlist 版本必须与 HLK 套件版本一致（例如 1607 的 kit 就要用 1607 的 playlist），且不要修改官方 playlist，否则结果无法用于提交。
• 首次测试:如果测试机是第一次跑测试，它会重启两次，并进入 OOBE（开箱设置）页——此时需要手动点击跳过。
• 手动测试项（Manual）会中断流程等待人工操作，建议与自动测试分开跑。测试列表里带重启标记的测试项会让机器反复重启，属正常现象，不要在这期间动那台机器。
• 做好时间预期：一个设备的完整 playlist 通常要跑几十小时到几天。建议先小批量跑几个测试确认环境通了，再整批放开跑，免得跑一整夜发现是环境问题。

五、Static Tools Logo Test（含 .sys 的内核驱动必做）

如果被测 driver 中包含 .sys 文件（内核模式驱动），就必须完成 Static Tools Logo Test。这项测试用 CodeQL 对驱动源码做静态分析，是内核驱动认证的强制项（自 WS2025 起 CodeQL 为必需工具）。

它并不直接分析源码，而是读取一份 DVL（Driver Verification Log，驱动验证日志）文件来确认你已跑过 CodeQL。注意这条链路的前半段完全发生在开发机上，跟 HLK 环境无关：

生成并放置 DVL 的步骤:

1. 在驱动源码上运行 CodeQL（视认证目标可能还需 SDV / Code Analysis）。需使用微软指定的官方查询套件，认证只强制要求 Must-Fix 那一组规则；具体用法见官方Run CodeQL Analysis for Windows Driver Certification。

2. 把 CodeQL 产出的 .sarif 文件放在对应 .vcxproj 的同一目录下（文件名不限，只要以 .sarif 结尾）。

3. 运行 DVL 生成工具，得到 .DVL.XML 文件。在 Visual Studio 里是菜单 Driver → Launch Driver Verification Log Creation Wizard（需装 WDK）；也可用命令行的 dvl.exe。

4. 把该 DVL 文件复制到测试机的 %systemdrive%\DVL 目录（即 C:\DVL\）。例如:

   C:\DVL\LnvMSRIO.DVL.XML
   

   复制前务必先清空 C:\DVL 目录，删掉里面旧的验证日志，再放入新的，否则会读到过期结果。

5. 回到 HLK Studio 运行 Static Tools Logo Test。

注意

• 该要求覆盖除图形驱动外的所有内核模式驱动；对 Windows Server 2025 认证，CodeQL 已是 Static Tools Logo Test 的必需工具。
• 运行此测试时,被测驱动必须是测试签名的,否则测试可能不出现（不 populate）或不告警。若你的包里不含 .sys,则该测试不出现属正常。
• 该测试只要求 DVL 证明 CodeQL 已运行,并不要求所有规则都 pass（但官方要求至少通过全部 “Must-Fix” 规则）。
• DVL 必须与被测的这一版驱动对应：源码改了、重新编译了，就要重跑 CodeQL、重新生成 DVL 再替换，否则测试会因为版本对不上而失败。
• 此测试需在 Server with Desktop 上跑;在 Server Core 上会报 RoMetadata.dll could not be found——解决办法是在带桌面的 Server 上跑,再用 merge 合并到 Core 的包里。

六、查看结果（Results）

1. 进入 Results 页。
2. 若有 fail,展开该失败项即可查看详细信息和日志(右键目标机名 → Diagnostic logs 可看诊断日志)。
3. 若测试项全部 pass,即可进入打包环节。

若因系统崩溃导致失败,失败项会带一个崩溃图标,右键可查看 Bugcheck 信息。

Fail 了先别急着改代码：Filters（Errata）

HLK 里有相当一部分失败不是你的驱动的问题，而是测试项本身的已知缺陷。微软为这类问题发布 Filters（也叫 Errata）——一组随 HLKFilterUpdates.cab 分发的规则，能把符合条件的 Fail 自动改判为 Pass，且这种"过滤后通过"的结果是可以用于提交的。

用法：

1. 到微软 HLK 页面下载最新的 HLKFilterUpdates.cab，在 Controller 上安装。
2. 关闭所有 HLK Studio 实例，运行 UpdateFilters.exe 完成更新。
3. 新装的 filters 会自动应用到之后产生的新结果；对更新之前就已经跑完的旧结果，需要打开对应项目，到 Results 页点 Apply Filters 手动重新应用一次。

遇到失败项的处理顺序建议是：更新并应用 filters → 看日志判断是不是环境问题（重跑一次往往就过了）→ 确认是真问题再回去改驱动。同一个测试允许重跑，提交时以最终结果为准。

关于失败排查，官方的 Troubleshooting Windows HLK Test Failures 值得收藏。

七、生成提交包（Package）

1. 进入 Package 页，点 Add Driver Folder，选中你的 driver 文件夹。

2. 弹出 Driver Properties 对话框，全选适用的 **OS（Products）和语言（Locales）**信息，确定。

   

3. 点 Create Package，根据需要选择签名方式:

   • Do not sign——生成未签名包（例如给支持团队调试、或稍后与其他包合并）。
   • Use the certificate store——用本机证书库里的代码签名证书签名（最常见）。
   • Use a certificate file——用证书文件（.cer）签名。

   正式提交微软的包必须签名，且需使用 EV 代码签名证书。

4. 打包末尾可能会要求补充源码 / Readme 等附加文件，按提示提供即可。

5. 生成 .hlkx 文件——它是“测试结果 + driver”的打包文件。

6. 将 .hlkx 提交微软(Hardware Dev Center 硬件开发者中心)进行签名/认证。

八、跨 OS 版本提交：合并包（Merge Package）

如果同一个驱动要认证多个 OS 版本 / 架构,做法是对每个版本分别测试、各生成一个 .hlkx,最后合并成一个提交包:

1. 在新测试完成后的 Package 页,点 Merge Package。
2. 点 Add,选择既往测试生成的 .hlkx 包（支持一次选多个）。
3. 确定后点 Create Package,即可把多个包合并为一个提交包。

别把两种"合并"搞混了

• 跨 OS 版本 / 架构合并：把针对不同 Windows 版本、不同架构分别测出的包并进同一个提交包——这正是上面这套做法，是允许的，也是标准做法。测试甚至可以分散在不同项目、不同机器池、不同 Controller 上完成。
• 深度合并（deep merge）：把同一个 target family 的测试拆到几个项目/环境里跑，再合并成一份完整结果。只有这种合并才有那串严格限制——目标必须同 OS、同架构、同类型（System 或 Device），软件过滤器类型不支持深度合并，且各目标下的特性集合、测试集合（设备类型还包括驱动集合与硬件 ID 集合）都必须完全一致。

两个实用提醒

• 打算把测试拆到多个项目里跑之前，先给原始项目生成一个包（哪怕里面一条结果都没有）。这个包保存了"该测哪些项"的完整清单，后面合并进来可以保证没有测试项被漏掉。
• HLK 包也能与老的 HCK 包合并，但顺序有要求：必须先打开 HLK 包，再把 HCK 包合并进去。

小结

到这里,一次完整的 HLK 测试就走完了:

建机器池并设 Ready → 建项目 → Selection 选目标 → 加载 playlist 跑测试 →（含 .sys 则做 Static Tools Logo Test）→ Results 全 pass（或经 filters 判定通过）→ 打包签名生成 .hlkx → 提交微软 →（跨版本则 merge）。

第一次跑难免磕碰,遇到失败先更新并应用 filters,再看 Results 里的日志和 Bugcheck 信息,大多能定位到具体原因。祝测试顺利。

驱动通过认证之后，如果只是要为不同 OEM 改一改 INF 等非 PE 文件，不必重跑这一整套流程——用 DUA 就能在原认证结果上直接换驱动重新提交，见 Driver DUA 操作指南。