共用方式為


檢閱常見裝置基礎可靠性測試失敗

本主題描述執行 Windows 硬體實驗室套件 (Windows HLK) 裝置基礎可靠性測試時可能會遇到的常見測試失敗。

測試在 HLK Studio 中標示為失敗,但 te.wtl 記錄只會顯示通過的結果

如果在 HLK Studio 中將測試標示為失敗,但 te.wtl 記錄只會顯示通過結果,您可以執行下列步驟來取得導致失敗的錯誤:

  1. 以滑鼠右鍵按兩下紅色 回合測試 圖示
  2. 選取 錯誤

隨即會出現一個對話框,其中包含所發生錯誤的描述。

測試失敗,因為測試期間發生非預期的重新啟動

如果錯誤文字指出發生非預期的重新啟動,這可能表示裝置導致操作系統意外重新啟動 (BSOD)。 若要診斷此失敗,請附加調試程式或設定測試計算機以自動產生完整記憶體轉儲,並調查錯誤檢查。 若要開始使用測試失敗的核心偵錯,請參閱 使用核心偵錯來偵錯裝置基礎可靠性測試失敗

裝置狀態檢查工作在安裝期間失敗

裝置狀態檢查工作通常會失敗,因為裝置在測試開始之前未正確設定媒體或連線。 如需有關如何正確設定裝置進行測試的資訊,請參閱 Device.Fundamentals 可靠性測試必要條件

裝置狀態檢查工作包含在每個裝置基礎可靠性測試作業的安裝階段。 它會執行工具來確認受測裝置處於工作狀態。 如果失敗,則會建立記錄,指出裝置的問題。

例如,針對 藍牙 裝置,您可能會收到下列錯誤:

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) 的參考計數如何變更。 識別正在變更參考計數的程式,並檢查呼叫堆疊在參考計數變更時的外觀。 下列步驟可用於偵錯此失敗:

  1. 如果您尚未這麼做,請將核心調試程式連線到測試計算機。 請參閱 設定計算機以進行驅動程式部署、測試和偵錯

  2. 在儲存測試裝置之 PDO 參考計數的位置設定 ba (Break on Access) 斷點。 如需存取斷點的詳細資訊,請參閱處理器斷點 (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)
    
  3. 使用 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
    
  4. 使用 dt (Display Type) 核心調試程式命令檢查 PDO 裝置物件。 ReferenceCount 會顯示與裝置對象相關聯的裝置開啟句柄數目。

    0: kd> dt nt!_DEVICE_OBJECT 849e9648  
    …
       +0x002 Size             : 0x398
       +0x004 ReferenceCount   : 0n0
       +0x008 DriverObject     : 0x8727e120 _DRIVER_OBJECT
    ..
    …
    
  5. 如果參考計數在開始測試之前大於 0:

    • 設定建立 PDO 的斷點。

    • 建立 PDO 之後,請在儲存 PDO 參考計數的位置設定存取中斷 (ba) 斷點。

      例如,下列命令會在裝置物件 (0x849e9648) 上設定 ba (Break on Access) 斷點。 斷點是在 ReferenceCount (+4 位移) 的寫入存取權上設定,大小為 4 個字節(ReferenceCount 的大小)。

      0: kd> ba w 4 849e9648+4 
      
    • 如果在開始測試之前,PDO 的參考計數等於 0,執行測試可能是導致測試的參考計數在測試執行裝置意外移除時,PDO 的參考計數大於零。 這通常表示句柄流失。 從命令提示字元視窗或 Visual Studio 執行 PNP 意外移除裝置測試,以重現失敗,並擷取疑難解答問題所需的資訊。

    注意

    如果您將 DoConcurrentIO 參數設定為 TRUE,測試會將數百個檔案句柄開啟至 PDO。 建議您在重現此失敗時,將此參數設定為 FALSE。

  6. 當存取中斷 (ba) 斷點發生時,您可以使用 !threadk (Display Stack Backtrace) 核心調試程式命令來偵錯失敗。 由於參考計數在執行測試的過程中可以變更多次,因此您可以選擇使用ba (Break on Access) 調試程式命令的 commandString 參數,取得每個參考計數變更所需的資訊,並繼續測試。

    例如,在下列 access 命令中斷中 ,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 外掛程式是測試一般裝置特定 I/O 功能的 WDTF 擴充功能。 如果所測試裝置的類型存在 WDTF 外掛程式,則測試會使用 IWDTFSimpleIOStressAction2 介面 在裝置上測試 I/O。

WDTF SimpleIO 外掛程式記錄的錯誤會使用 TestTextLog.log 檔案中的 WDTF_SIMPLE_IO 標籤(請參閱 WDTF 物件名稱標籤。 錯誤訊息一律會識別受測裝置,以及失敗的特定原因。

範例:

在此範例中,無線 SimpleIO 外掛程式記錄了 802.11n USB 無線 LAN 卡裝置測試期間發生 I/O 失敗的失敗。 具體而言,SimpleIO 外掛程式會使用 IcmpSendEcho 函式來偵測閘道位址,其傳回錯誤 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 Before 和 After 測試睡眠會執行下列動作:

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 正在測試的裝置數目而定,掛斷的裝置可以識別如下:

  1. 如果測試在上測試 I/O 的裝置數目是其中一個,您就不會在命令視窗中看到超過十分鐘的進度。 命令視窗中的最後一個記錄專案會有一個 WDTF_SIMPLE_IOWDTF_SIMPLEIO_STRESS 標記,而且它會識別掛斷的裝置。 如需如何讀取測試記錄檔的詳細資訊,請參閱檢閱記錄檔。

  2. 如果測試正在測試 I/O 的裝置數目大於一個,您會在命令視窗中看到持續重複 PerformIO(<裝置名稱>) 計數 ... 訊息超過 10 分鐘。 測試會在測試 I/O 兩分鐘后,嘗試在一部裝置上一次停止測試 I/O。 如果特定裝置的停止作業成功,您應該會在記錄中看到裝置的「停止」訊息,後面接著裝置的「關閉」訊息。 如果看到「停止」訊息,但裝置看不到對應的「關閉」訊息,則表示測試此裝置的 I/O 已停止回應。

範例:

在下列案例中,行動寬頻裝置是問題裝置,因為有「停止」訊息,但沒有對應的「關閉」訊息。 另一方面,I2C HID 裝置同時有「停止」訊息和「關閉」訊息,這表示測試能夠在沒有任何問題的情況下停止裝置上的 I/O。 測試從未有機會停止在 Microsoft Basic Render Driver 和 Microsoft ACPI 相容的系統裝置上測試 I/O;因此,這些裝置會持續看到「執行IO」訊息。

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 修正程式以解決喚醒定時器問題,或在喚醒定時器如預期運作的不同系統上執行測試。

由於驅動程式錯誤,系統也可以在電源上線或關閉電源期間永久停止回應。 在此情況下,您應該使用連線至核心調試程式的測試系統,對系統停止響應進行偵錯,以重新執行測試。

如需如何設定核心調試程式的詳細資訊,請參閱 手動 設定內核模式偵錯。 如需如何在 Windows HLK 測試執行期間針對系統停止響應進行疑難解答的一般指引,請參閱針對 Windows HLK 測試失敗進行疑難解答。

WirelessPlugin:連線 ToTestProfile() - 無法連線到測試配置檔。 原因字串:「特定網路無法使用。」 錯誤訊息

如果 Wpa2PskAesSsid 和 Wpa2PskPassword 參數的值未在測試排程時間提供給測試,裝置基本概念測試將會失敗,並出現此錯誤訊息。 如果受測的其中一個裝置是WiFi配接器,測試測試會要求您提供測試無線網路的連線資訊(SSID和密碼)。 如需這些測試參數的詳細資訊,請參閱失敗測試文件頁面的參數一節。

WDTFSensorsPlugin: Open() - GPS 感測器未進入就緒狀態

裝置基礎可靠性測試要求具有 GPS 感測器的系統必須在具有強 GPS 訊號的環境中進行測試(以便測試能夠在 GPS 感測器裝置上測試 I/O)。 此錯誤表示測試系統上的 GPS 感測器無法取得 GPS 修正。 請考慮在測試系統可以取得強式 GPS 訊號的位置執行測試。

測試記錄訊息:重新啟動後找到的裝置數目(1)與重新啟動前的裝置數目不同(2):請檢閱記錄以尋找遺失的裝置(s)

此訊息表示其中一個裝置在重新啟動後未返回。 若要調查此失敗,請執行下列步驟,產生和分析重新安裝、重新啟動和重新啟動測試的詳細 Setupapi 記錄:

  1. 若要產生詳細資訊的 setupapi 記錄,請將登錄機碼 設定為 KEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Setup!LogLevel0x2000ffff
  2. 重新提出問題,然後檢閱 %windir%\inf\setupapi* 上的 Setupapi 記錄
  3. 若要造成裝置安裝問題的根本原因,請參閱 使用 Setupapi.log 檔案進行疑難解答

如果記錄檔包含錯誤,指出裝置遺失或未啟動,請從調試程序執行 !pnptriage 並檢閱輸出。 如需偵錯測試失敗的詳細資訊,請參閱 使用核心偵錯來偵錯裝置基礎可靠性測試失敗

藉由使用 Windows HLK 對裝置基礎可靠性測試進行疑難排解