查看常见的设备基本组件可靠性测试失败问题

项目
06/20/2023

本主题介绍在运行 Windows Hardware Lab Kit (Windows HLK) 设备基本组件可靠性测试时可能会遇到的常见测试失败。

测试在 HLK Studio 中标记为失败，但 te.wtl 日志只显示通过结果

如果测试在 HLK Studio 中标记为失败，但 te.wtl 日志只显示通过结果，则可以通过执行以下步骤来获取导致失败的错误：

右键单击红色的“运行测试”图标
选择“错误”

一个对话框会出现，其中包含所发生错误的说明。

测试失败，因为测试期间发生意外重新启动

如果错误文本指出发生了意外重新启动，则这可能意味着设备导致操作系统意外重新启动 (BSOD)。若要对此失败进行诊断，请附加调试程序或配置测试计算机以自动生成完整内存转储，并调查 bug 检查。若要开始对测试失败进行内核调试，请参阅使用内核调试来调试设备基本组件可靠性测试失败。

设备状态检查任务在设置过程中失败

设备状态检查任务失败的原因通常是设备在测试开始之前未使用媒体或连接正确设置。有关如何正确配置设备进行测试的信息，请参阅 Device.Fundamentals 可靠性测试先决条件。

设备状态检查任务包含在每个设备基本组件可靠性测试作业的设置阶段中。它会运行一个工具来验证受测设备 (DUT) 是否处于正常工作条件。如果失败，则会创建一个日志，指示设备的问题。

例如，对于蓝牙设备，可能会收到以下错误：

PerformIO(Example ) Failed : Streaming error capturing audio HRESULT=0x8445001F Count 1

此错误消息可能指示在测试之前，必须使用音频控制面板连接到蓝牙设备。

在下面的示例中，测试设备报告问题代码 A - CM_PROB_FAILED_START 状态。它应报告问题代码 0（没有问题）。

WDTF_TARGETS          : INFO  : - Query("IsPhantom=False AND (DeviceID='USB\VID_0BDB&PID_1917&CDC_0D&MI_06\6&2A131B9E&1&0006')")
WDTF_TARGETS          : INFO  : Target: F5321 gw Mobile Broadband Network Adapter USB\VID_0BDB&PID_1917&CDC_0D&MI_06\6&2A131B9E&1&0006 
WDTF_TEST             : ERROR : Found a device that has a non-zero problem code or is phantom. Logging device info.
WDTF_TEST             : INFO  : DeviceID:     USB\VID_0BDB&PID_1917&CDC_0D&MI_06\6&2A131B9E&1&0006
WDTF_TEST             : INFO  : DisplayName:  F5321 gw Mobile Broadband Network Adapter
WDTF_TEST             : INFO  : Status:       Status Flags=0x1802400 (DN_HAS_PROBLEM DN_DISABLEABLE DN_NT_ENUMERATOR DN_NT_DRIVER) Problem Code=a (CM_PROB_FAILED_START)
WDTF_TEST             : INFO  : IsPhantom:    False

设备路径练习程序失败，出现“测试线程超出超时限制。正在终止线程错误”错误

当测试在设备路径练习程序测试期间记录“测试线程超出超时限制。正在终止线程错误”时，测试还会记录它执行的上次操作。驱动程序开发人员必须确定上次记录的操作导致测试挂起的原因。例如：

WDTF_FUZZTEST : Test thread exceeded timeout limit. Terminating thread
WDTF_FUZZTEST : Last logged operation: ZwDeviceIoControlFile, CtrlCode=0x2b0020, InBuf=0xfffffc00, 0 OutBuf=0xfffffc00, 0

意外删除测试失败，出现“收到 IRP_MN_SURPRISE_REMOVAL 后未能收到 IRP_MN_REMOVE_DEVICE”错误消息

如果 PnP 管理器在发送意外删除 IRP 后未将删除 IRP 发送到测试设备堆栈，则 DF - PNP 意外删除设备测试可能会失败，并出现以下错误消息：

"Failed to receive IRP_MN_REMOVE_DEVICE after receiving IRP_MN_SURPRISE_REMOVAL. Ensure that there are no open handles or references to the test device (in user mode or in kernel mode) preventing IRP_MN_REMOVE_DEVICE from being sent. You may need to terminate any processes or services that may have open user mode handles to this device."

在关闭设备的所有未完成文件句柄之前，PnP 管理器不会发送 IRP_MN_REMOVE_DEVICE 请求。也就是说，在 PDO 的引用计数达到零之前，PnP 管理器不会发送 IRP_MN_REMOVE_DEVICE 请求。请参阅处理 IRP_MN_SURPRISE_REMOVAL 请求，以了解有关如何正确处理 IRP_MN_SURPRISE_REMOVAL 请求的信息。

若要帮助调试此测试失败，应确定物理设备对象 (PDO) 的引用计数如何更改。确定在更改引用计数的进程，并检查引用计数更改时调用堆栈的内容。以下步骤可用于调试此失败：

如果尚未这样做，请将内核调试程序连接到测试计算机。请参阅为驱动程序部署、测试和调试配置计算机。
在存储测试设备的 PDO 引用计数的位置处设置 ba（访问时中断）断点。有关访问断点的详细信息，请参阅处理器断点（ba 断点）。在下面的示例中，内核调试程序 !devnode 命令会获取有关 USBvideo 驱动程序的 devnode 的信息。此 devnode 的 PDO 地址为 0x849e9648。
```
0: kd> !devnode 0 1 usbvideo
Dumping IopRootDeviceNode (= 0x848fadd8)
DevNode 0x849e9448 for PDO 0x849e9648
  InstancePath is "USB\VID_045E&PID_076D&MI_00\7&1243e0b7&0&0000"
  ServiceName is "usbvideo"
  State = DeviceNodeStarted (0x308)
  Previous State = DeviceNodeEnumerateCompletion (0x30d)
```

对 PDO 使用 !devobj 命令以显示有关 PDO 的引用计数 (RefCount) 的信息。

0: kd> !devobj 0x849e9648
Device object (849e9648) is for:
 0000004e \Driver\usbccgp DriverObject 8727e120
Current Irp 00000000 RefCount 0 Type 00000022 Flags 00003040
Dacl 82910320 DevExt 849e9700 DevObjExt 849e99e0 DevNode 849e9448 
ExtensionFlags (0x00000800)  DOE_DEFAULT_SD_PRESENT
Characteristics (0x00000180)  FILE_AUTOGENERATED_DEVICE_NAME, FILE_DEVICE_SECURE_OPEN
AttachedDevice (Upper) 88310588 \Driver\usbvideo
Device queue is not busy

使用 dt（显示类型）内核调试程序命令检查 PDO 设备对象。 ReferenceCount 显示与设备对象关联的设备的打开句柄数。

0: kd> dt nt!_DEVICE_OBJECT 849e9648  
…
   +0x002 Size             : 0x398
   +0x004 ReferenceCount   : 0n0
   +0x008 DriverObject     : 0x8727e120 _DRIVER_OBJECT
..
…

如果在开始测试之前引用计数大于 0：
- 为创建 PDO 的位置处设置断点。
- 创建 PDO 后，在存储 PDO 引用计数的位置处设置访问时中断 (ba) 断点。
  
  例如，以下命令对设备对象 (0x849e9648) 设置 ba（访问时中断）断点。在对 ReferenceCount（+4 偏移量）进行写入访问时设置断点，大小为 4 字节（ReferenceCount 的大小）。
```
0: kd> ba w 4 849e9648+4 
```
- 如果在开始测试之前 PDO 的引用计数等于 0，则运行测试可能会导致在测试执行设备的意外删除时 PDO 引用计数大于零。这通常指示句柄泄漏。从命令提示符窗口或 Visual Studio 运行 PNP 意外删除设备测试，以重现失败并捕获对问题进行故障排除所需的信息。
注意

如果将 DoConcurrentIO 参数设置为 TRUE，则测试会打开 PDO 的数百个文件句柄。建议在重现此失败时将此参数设置为 FALSE。
当访问时中断 (ba) 断点出现时，可以使用 !thread 和 k（显示堆栈回溯）内核调试程序命令来调试失败。由于引用计数在运行测试的过程中可能会多次更改，因此作为一个选项，可以使用 ba（访问时中断）调试程序命令的 commandString 参数获取每次更改引用计数时所需的信息，并且仍然继续测试。

例如，在以下访问时中断命令中，commandString 由一个 !thread 命令（用于标识导致引用计数更改的进程）、.reload ; k 100 命令（用于标识调用堆栈）、!devobj 命令（用于在每次更改时打印引用计数）和 g 命令（用于在断点之后继续执行）组成。
```
0: kd> ba w 4 849e9648+4 "!thread; .thread /p /r; .reload; k 100; !devobj 849e9648; g"
```

示例：

在下面的示例中，从在 cscript.exe 中运行的线程进行的 CreateFile 函数调用会导致引用计数递增。在运行测试期间捕获更改引用计数的所有实例并分析这些调用堆栈可帮助识别句柄泄漏。

THREAD 87eb3d40  Cid 1094.1490  Teb: 7f5a8000 Win32Thread: 82da2210 RUNNING on processor 3
Not impersonating
DeviceMap                 a71b3228
Owning Process            88199cc0       Image:         cscript.exe
Attached Process          N/A            Image:         N/A
Wait Start TickCount      1232688        Ticks: 0
Context Switch Count      18             IdealProcessor: 2             
UserTime                  00:00:00.000
KernelTime                00:00:00.000
Win32 Start Address ntdll!TppWorkerThread (0x7710704d)
Stack Init a6ebfde0 Current a6ebfa6c Base a6ec0000 Limit a6ebd000 Call 0
Priority 9 BasePriority 8 UnusualBoost 0 ForegroundBoost 0 IoPriority 2 PagePriority 5
ChildEBP RetAddr  Args to Child              
a6ebfa50 814a73fe f81771f8 814a72e5 8281000e nt!IopCheckDeviceAndDriver+0x61 (FPO: [Non-Fpo]) (CONV: stdcall) [d:\w8rtm\minkernel\ntos\io\iomgr\parse.c @ 182]
a6ebfb70 8149fb76 849e9648 848f9200 87164008 nt!IopParseDevice+0x11d (FPO: [Non-Fpo]) (CONV: stdcall) [d:\w8rtm\minkernel\ntos\io\iomgr\parse.c @ 1634]
…
…
0236f874 7710689d ffffffff 77195ae2 00000000 ntdll!__RtlUserThreadStart+0x4a (FPO: [SEH]) (CONV: stdcall) [d:\w8rtm\minkernel\ntdll\rtlstrt.c @ 1021]
0236f884 00000000 7710704d 0031c540 00000000 ntdll!_RtlUserThreadStart+0x1c (FPO: [Non-Fpo]) (CONV: stdcall) [d:\w8rtm\minkernel\ntdll\rtlstrt.c @ 939]

Implicit thread is now 87eb3d40
Connected to Windows 8 9200 x86 compatible target at (Wed Sep 19 21:04:27.601 2012 (UTC - 7:00)), ptr64 FALSE
Loading Kernel Symbols
...............................................................
................................................................
...............
Loading User Symbols
................................................................
...........................
Loading unloaded module list
.....................
ChildEBP RetAddr  
a6ebfa50 814a73fe nt!IopCheckDeviceAndDriver+0x61 [d:\w8rtm\minkernel\ntos\io\iomgr\parse.c @ 182]
a6ebfb70 8149fb76 nt!IopParseDevice+0x11d [d:\w8rtm\minkernel\ntos\io\iomgr\parse.c @ 1634]
…
…
0236f2d4 6970274e KERNELBASE!CreateFileW+0x61 [d:\w8rtm\minkernel\kernelbase\fileopcr.c @ 1194]
0236f31c 6b6ce0e1 deviceaccess!CDeviceBroker::OpenDeviceFromInterfacePath+0x178 [d:\w8rtm\base\devices\broker\dll\broker.cpp @ 177]
0236f34c 6b6cc5c0 MFCORE!CDevProxy::CreateKsFilter+0x46 [d:\w8rtm\avcore\mf\core\transforms\devproxy\devproxy.cpp @ 2263]
…
…
0236f874 7710689d ntdll!__RtlUserThreadStart+0x4a [d:\w8rtm\minkernel\ntdll\rtlstrt.c @ 1021]
0236f884 00000000 ntdll!_RtlUserThreadStart+0x1c [d:\w8rtm\minkernel\ntdll\rtlstrt.c @ 939]

Device object (849e9648) is for:
 0000004e \Driver\usbccgp DriverObject 8727e120
Current Irp 00000000 RefCount 1 Type 00000022 Flags 00003040
Dacl 82910320 DevExt 849e9700 DevObjExt 849e99e0 DevNode 849e9448 
ExtensionFlags (0x00000800)  DOE_DEFAULT_SD_PRESENT
Characteristics (0x00000180)  FILE_AUTOGENERATED_DEVICE_NAME, FILE_DEVICE_SECURE_OPEN
AttachedDevice (Upper) 88310588 \Driver\usbvideo
Device queue is not busy.

SimpleIO 插件日志失败

设备基本组件可靠性测试使用提供的 WDTF 简单 I/O 插件对设备测试 I/O。 SimpleIO 插件是 WDTF 扩展，用于测试特定于通用设备的 I/O 功能。如果对于进行测试的设备类型，存在 WDTF 插件，则测试会使用 IWDTFSimpleIOStressAction2 接口对设备测试 I/O。

WDTF SimpleIO 插件记录的错误会在 TestTextLog.log 文件中使用 WDTF_SIMPLE_IO 标记（请参阅 WDTF 对象名称标记）。错误消息会始终标识受测设备以及失败的具体原因。

示例：

在此示例中，无线 SimpleIO 插件记录了在 802.11n USB 无线 LAN 卡设备测试期间发生 I/O 故障的失败。具体而言，SimpleIO 插件使用 IcmpSendEcho 函数对网关地址执行 ping 操作，这返回了错误 11010。此错误可转换为“错误是由于资源不足造成”。

WDTF_SIMPLE_IO            : ERROR :  - PerformIO(802.11n USB Wireless LAN Card USB\VID_XXXX&PID_XXXX\X&XXXXXXX&X&X ) Failed : WirelessPlugin: TestPingGateway() - IcmpSendEcho() call failed several times. The error reported is for the last failure instance Win32=11010 - Error due to lack of resources.

特定设备上 I/O 测试永久挂起，并最终导致测试因超时而失败

设备基本组件可靠性测试是基于方案的测试，将 I/O 测试与 PNP 和电源测试方案相结合。这些测试通常会在某个方案之前和之后对 I/O 测试两分钟。例如，DF - 使用前后 IO 进行休眠测试会执行以下操作：

For each sleep state supported on the system (CS, S1, S2, S3, S4)

Test I/O on devices with I/O plugins in parallel (one thread per device) for 2 minutes

Enter sleep state & exit after 2 minutes

Next

测试在运行时最终会对设备多次测试 I/O（对每个睡眠状态一次）。有关如何在日志文件中查看此内容的信息，请参阅查看日志文件。

测试 I/O 时的常见失败之一是特定设备上的 I/O 测试可能会永久挂起。这会导致测试在测试超时期限（通常为数小时）过后最终失败。有关如何识别超时导致的失败的信息，请参阅 Windows HLK 测试失败疑难解答。

注意

Windows HLK 会在超时期限过后终止挂起的进程。建议在挂起的进程仍在系统上运行期间调查挂起，而不是等待测试由于永久挂起而最终失败。有关如何排查测试挂起问题的信息，请参阅使用 Windows HLK 排查设备基本组件可靠性测试问题的“测试挂起”部分。

根据要测试 I/O 的设备数，可以按如下所示标识挂起的设备：

如果测试对其进行 I/O 测试的设备数为 1，则你超过 10 分钟在命令窗口中未看到任何进展。命令窗口中的最后一个日志条目会具有 WDTF_SIMPLE_IO 或 WDTF_SIMPLEIO_STRESS 标记，它会标识挂起的设备。有关如何读取测试日志文件的详细信息，请参阅查看日志文件。
如果测试对其进行 I/O 测试的设备数大于 1，则你超过 10 分钟在命令窗口中看到“PerformIO(<设备名称>) 计数 …”消息持续重复。测试在对设备测试 I/O 两分钟后，会尝试逐个设备停止测试 I/O。如果对特定设备的停止操作成功，则你应在日志中看到该设备的“停止”消息后跟着“关闭”消息。如果看到设备的“停止”消息，但未看到对应的“关闭”消息，则表示对此设备的 I/O 测试已挂起。

示例：

在下例中，移动宽带设备是问题设备，因为存在“停止”消息，但没有对应的“关闭”消息。另一方面，I2C HID 设备同时具有“停止”消息和“关闭”消息，这意味着测试能够对该设备停止 I/O，未出现任何问题。测试始终无法对 Microsoft 基本呈现驱动程序和 Microsoft ACPI 兼容的系统设备停止测试 I/O；因此，对于这些设备会持续看到“PerformIO”消息。

WDTF_SIMPLEIO_STRESS      : INFO  :  - Stop(I2C HID Device ACPI\STMQ7017\2&DABA3FF&3 )
WDTF_SIMPLE_IO            : INFO  :  - Close(I2C HID Device ACPI\STMQ7017\2&DABA3FF&3 )
WDTF_SIMPLEIO_STRESS      : INFO  :  - Stop(XYZ Mobile Broadband Device USB\VEN_XXX&PID_XXX\X&XXXXXX&X&X)
WDTF_SIMPLE_IO            : INFO  :  - PerformIO(Microsoft Basic Render Driver ROOT\BASICRENDER\0000 ) Count 119
WDTF_SIMPLE_IO            : INFO  :  - PerformIO(Microsoft ACPI-Compliant System ACPI_HAL\PNP0C08\0 ) Count 119
WDTF_SIMPLE_IO            : INFO  :  - PerformIO(Microsoft Basic Render Driver ROOT\BASICRENDER\0000 ) Count 119
WDTF_SIMPLE_IO            : INFO  :  - PerformIO(Microsoft ACPI-Compliant System ACPI_HAL\PNP0C08\0 ) Count 119
…
…
WDTF_SIMPLE_IO            : INFO  :  - PerformIO(Microsoft Basic Render Driver ROOT\BASICRENDER\0000 ) Count 119
WDTF_SIMPLE_IO            : INFO  :  - PerformIO(Microsoft ACPI-Compliant System ACPI_HAL\PNP0C08\0 ) Count 119
WDTF_SIMPLE_IO            : INFO  :  - PerformIO(Microsoft Basic Render Driver ROOT\BASICRENDER\0000 ) Count 119
WDTF_SIMPLE_IO            : INFO  :  - PerformIO(Microsoft ACPI-Compliant System ACPI_HAL\PNP0C08\0 ) Count 119
…
…

下一步是检查测试进程中线程的堆栈跟踪，以确定移动宽带设备的 I/O 测试为何挂起。你会发现，测试进程中有一个线程用于专门对移动宽带设备测试 I/O。有关其他故障排除信息，请参阅使用内核调试来调试设备基本组件可靠性测试失败。

测试未从睡眠状态恢复

设备基本组件可靠性测试依靠系统唤醒计时器在电源管理测试期间从睡眠状态唤醒测试系统。发生故障的唤醒计时器可能会阻止测试系统在测试运行期间自动唤醒。如果测试系统未自动从睡眠状态唤醒，可能需要联系 BIOS 供应商以让他们发布 BIOS 修复来解决唤醒计时器问题，或是对唤醒计时器按预期方式工作的不同系统运行测试。

系统也可能在通电或断电期间因驱动程序 bug 而永久挂起。在这种情况下，应使用连接到内核调试程序的测试系统重新运行测试，并从内核调试程序调试系统挂起。

有关如何设置内核调试程序的信息，请参阅手动设置内核模式调试。有关如何在 Windows HLK 测试运行期间排查系统挂起问题的常规指导，请参阅 Windows HLK 测试失败疑难解答。

WirelessPlugin: ConnectToTestProfile() - 未能连接到测试配置文件。原因字符串：“特定的网络不可用”错误消息

如果未在测试计划时间向测试提供 Wpa2PskAesSsid 和 Wpa2PskPassword 参数的正确值，则设备基本组件测试会失败并出现此错误消息。如果受测设备之一是 WiFi 适配器，则测试会要求提供测试无线网络的连接信息（SSID 和密码）。有关这些测试参数的详细信息，请参阅失败测试文档页的参数部分。

WDTFSensorsPlugin: Open() - GPS 传感器未进入就绪状态

设备基本组件可靠性测试要求在具有强 GPS 信号的环境中测试具有 GPS 传感器的系统（以便测试能够对 GPS 传感器设备测试 I/O）。此错误指示测试系统上的 GPS 传感器无法获取 GPS 定位。请考虑在测试系统可以获取强 GPS 信号的位置运行测试。

测试日志消息：重新启动之后找到的设备数 (1) 与重新启动之前 (2) 不同；请查看日志以查找缺少的设备

此消息指示重新启动之后，某个设备未返回。若要调查此失败，请通过执行以下步骤，来生成并分析有关重新安装、重启和重新启动测试的详细 Setupapi 日志：

若要生成详细 setupapi 日志，请将注册表项 KEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Setup!LogLevel 设置为 0x2000ffff
重现问题，然后查看 %windir%\inf\setupapi* 处的 Setupapi 日志
若要找出设备安装问题的根本原因，请参阅使用 Setupapi.log 文件进行故障排除

如果日志包含指出设备缺失或未启动的错误，请从调试程序运行 !pnptriage 并查看输出。有关调试测试失败的详细信息，请参阅使用内核调试来调试设备基本组件可靠性测试失败。

通过