一般的な Device Fundamentals 信頼性テストのエラーの確認

  • [アーティクル]

このトピックでは、Windows Hardware Lab Kit (Windows HLK) Device 信頼性テストを実行するときに発生する可能性がある一般的なテスト エラーについて説明します。

テストは HLK Studio で失敗としてマークされいるが、te.wtl ログには成功結果だけが表示される

テストは HLK Studio で失敗としてマークされているのに、te.wtl ログに成功結果だけが表示される場合は、次の手順を実行して失敗の原因となるエラーを取得できます。

  1. 赤い [テストの実行] アイコンを右クリック します
  2. [エラー] を選択します

発生したエラーの説明を含むダイアログ ボックスが表示されます。

テスト中に予期しない再起動が発生したため、テストに失敗した

エラー テキストに予期しない再起動が発生したと示されている場合は、デバイスによってオペレーティング システムが予期せず再起動された (BSOD) 可能性があります。 このエラーを診断するには、デバッガーをアタッチするか、フル メモリ ダンプを自動的に生成するテスト マシンを構成し、バグ チェックを調査します。 テスト エラーのカーネル デバッグを開始するには、「カーネル デバッグを使用してデバイスの基礎信頼性テスト エラーをデバッグする」を参照してください。

セットアップ中にデバイスの状態の確認タスクが失敗する

デバイスの状態の確認タスクは、テストを開始する前にメディアまたは接続を使用してデバイスが正しく設定されていない場合に失敗することが多くあります。 テスト用にデバイスを適切に構成する方法については「Device.Fundamentals 信頼性テストの前提条件」を参照してください。

デバイスの状態の確認タスクは、すべての Device Fundamentals 信頼性テスト ジョブのセットアップ フェーズに含まれています。 ツールを実行して、テスト中のデバイス (DUT) が動作状態にあるか確認します。 失敗した場合は、デバイスの問題を示すログが作成されます。

たとえば、デバイスの Bluetooth デバイスの場合、次のエラーが発生する場合があります。

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

このエラー メッセージは、テストの前に、オーディオ コントロール パネルを使用して Bluetooth デバイスに接続する必要がある場合があります。

次の例では、テスト デバイスは問題コード A - 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

Device Path Exerciser fails with "Test thread exceeded timeout limit. Terminating thread error" error

テストで Device Path Exerciser テスト中に Test thread exceeded timeout limit. Terminating thread error error を記録すると、このテストは実行した最後の操作も記録します。 ドライバー開発者は、最後に記録された操作によってテストがハングする原因を特定する必要があります。 次に例を示します。

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

Surprise Remove test fails with "Failed to receive IRP_MN_REMOVE_DEVICE after receiving IRP_MN_SURPRISE_REMOVAL" error message

DF - PNP Surprise Remove Device Test は、PnP マネージャーが surprise remove IRP を送信した後に remove IRP をテスト デバイス スタックに送信しない場合、次のエラー メッセージで失敗する可能性があります。

"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 要求を送信しません。 つまり、PnP マネージャーは PDO が参照カウント 0 に達するまで、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 (Break on Access) ブレークポイントを設定します。

      たとえば、次のコマンドは、デバイス オブジェクト (0x849e9648) に ba (Break on Access) ブレークポイントを設定します。 ブレークポイントは、サイズが 4 バイト (ReferenceCount のサイズ) の ReferenceCount (+4 オフセット) への書き込みアクセスに設定されます。

      0: kd> ba w 4 849e9648+4

    • テストを開始する前に PDO の参照カウントが 0 に等しい場合、おそらくテストの実行が、テストでデバイスの突然の削除が実行された時点で PDO の参照カウントが 0 より大きくなる原因となっています。 これは通常、ハンドル リークを示します。 PNP Surprise Remove Device テストをコマンド プロンプト ウィンドウまたは Visual Studio から実行してエラーを再現し、問題のトラブルシューティングに必要な情報を把握します。

    Note

    DoConcurrentIO パラメーターを TRUE に設定すると、テストによって数百のファイル ハンドルが PDO に対して開かれます。 このエラーを再現するときに、このパラメーターを FALSE に設定することをお勧めします。

  6. Break on Access (ba ) ブレークポイントが発生した場合は !thread および k (Display Stack Backtrace) カーネル デバッガー コマンドを使用してエラーをデバッグできます。 参照カウントはテストの実行中に何度も変更される可能性があるため、オプションとして ba (Break on Access) デバッガー コマンドの commandString パラメーターを使用すると、参照カウントの変更ごとに必要な情報を取得し、引き続きテストを続行できます。

    たとえば、次の Break on 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 プラグインのログ エラー

Device Fundamentals 信頼性テストでは、 デバイスで I/O をテストするために、指定された WDTF Simple 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 関数を使用してゲートウェイ アドレスに 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 をテストすると永続的にハングし、最終的にタイムアウトが原因でテストが失敗する

Device Fundamentals 信頼性テストは、シナリオ ベースのテストであり、I/O テストと PNP &電源テスト シナリオを組み合わせたものになります。 通常、テストでは、シナリオの前後の 2 分間に I/O がテストされます。 たとえば、DF - Sleep with IO Before and 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 を数回 (スリープ状態ごとに 1 回) テストします。 ログ ファイルでこれを確認する方法については、「ログ ファイルを確認する」を参照してください。

I/O のテスト時の一般的なエラーの 1 つは、特定のデバイスで I/O をテストすると永続的にハングする可能性があるというエラーです。 これにより、テスト タイムアウト期間 (通常は数時間) 後にテストが最終的に失敗します。 タイムアウトによって発生を特定する方法については、「Windows HLK テストのエラーのトラブルシューティング」を参照してください。

Note

Windows HLK は、タイムアウト期間後に ハングしたプロセスを終了します。 永続的なハングによってテストが最終的に失敗するのを待つのではなく、ハングしたプロセスがまだシステムで実行されている間にそのハングについて調査することをお勧めします。 テストハングのトラブルシューティング方法については、「Windows HLK を使用した Device Fundamentals 信頼性テストのトラブルシューティング」トピックの「テスト ハング」セクションを参照してください。

I/O がテストされているデバイスの数に応じて、ハングしたデバイスは次のように識別できます。

  1. テストで I/O をテストしているデバイスの数が 1 の場合、10 分以上コマンド ウィンドウに進行状況が表示されません。 コマンド ウィンドウの最後のログ エントリには、WDTF_SIMPLE_IO または WDTF_SIMPLEIO_STRESS タグが表示され、ハングしたデバイスが識別されます。 ログ ファイルでの読み方については、「ログ ファイルを確認する」を参照してください。

  2. テストが IO をテストしているデバイス数が 1 よりも大きい場合、コマンド ウィンドウに 10 分以上 PerformIO(<Device Name>) Count … メッセージが一定して繰り返し表示されます。 テストでは、2 分間の I/O テストの後、一度につき 1 つのデバイスで I/O のテストを停止します。 特定のデバイスで停止操作が成功した場合は、"Stop" メッセージの後にデバイスの "Close" メッセージがログに表示されます。 "Stop" メッセージが表示されているが、対応する "Close" メッセージがデバイスに対して表示されない場合は、このデバイスに対する I/O のテストがハングしているという意味です。

例:

次の場合、"Stop" メッセージが表示されるものの、対応する "Close" メッセージが存在しないので、モバイル ブロードバンド デバイスが問題のデバイスです。 一方、I2C HID デバイスには "Stop" メッセージと "Close" メッセージの両方があり、これはテストで問題なくデバイスの I/O を停止できたことを意味します。 このテストでは、Microsoft Basic Render Driver デバイスと Microsoft ACPI-Compliant System デバイスでの 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 のテストがハングしている理由を特定します。 テスト プロセスのスレッドの 1 つが、モバイル ブロードバンド デバイスで I/O をテストするために使用されていることを確認します。 その他のトラブルシューティングの情報については、カーネル デバッグを使用した、デバイス基礎の信頼性テストのエラーのデバッグを参照してください。

テストがスリープ状態から再開されない

Device Fundamentals 信頼性テストは、電源管理テスト中にスリープ状態からテスト システムをウェイクアップするのにシステム ウェイク タイマーに依存しています。 障害のあるウェイク タイマーを使用すると、テストの実行中にテスト システムが自動的にスリープ解除されるのを防止する可能性があります。 テスト システムが自動的にスリープからウェイクアップしない場合は、BIOS ベンダーに問い合わせ、ウェイク タイマーの問題に対処するために BIOS 修正プログラムをリリースするか、ウェイク タイマーが期待した通り動作する別のシステムでテストを実行する必要があります。

また、ドライバーのバグにより、電源のオン時または電源停止中にシステムが永続的にハングする可能性があります。 この場合は、カーネル デバッガーに接続されているテスト システムを使用してテストを再び実行し、カーネル デバッガーからシステムハングをデバッグする必要があります。

カーネル デバッガーを設定する方法については「カーネル モードのデバッグの手動設定」に関するページを参照してください。 Windows HLK テスト中にシステム ハングをトラブルシューティングする方法に関する一般的なガイダンスについては、「Windows HLKテスト エラーのトラブルシューティング」を参照してください。

WirelessPlugin: ConnectToTestProfile() - Failed to connect to test profile. Reason string: "The specific network is not available." error message

テスト スケジュール時に Wpa2PskAesSsid パラメーターと Wpa2PskPassword パラメーターの正しい値がテストに指定されていない場合、Device Fundamentals テストは失敗し、このエラー メッセージが表示されます。 テストでは、テスト中のデバイスの 1 つが WiFi アダプターである場合、テスト ワイヤレス ネットワークの接続情報 (SSID とパスワード) を指定する必要があります。 これらのテスト パラメーターの詳細については、失敗したテストのドキュメント ページのパラメーターのセクションを参照してください。

WDTFSensorsPlugin: Open() - GPS Sensor did not go to ready state

Device Fundamentals 信頼性テストでは、(テストが GPS センサー デバイスで I/O をテストするために) 強力な GPS 信号がある環境で、GPS センサーを搭載したシステムをテストする必要があります。 このエラーは、テスト システム上の GPS センサーが GPS 修正プログラムを取得できないことを示します。 テスト システムが強力な GPS 信号を取得できる場所でテストを実行する方法を検討してください。

テスト ログ メッセージ: 再起動後に見つかったデバイスの数 (1) は、再起動前 (2) と同じではありません。不足しているデバイスを見つけるにはログを確認してください

このメッセージは、再起動後にデバイスの 1 つが戻ってこなかったことを示します。 このエラーを調査するには、次の手順を実行して、Reinstal、Restart、および Reboot の各テストの詳細な Setupapi ログを生成して分析します。

  1. 詳細な Setupapi ログを生成するには、レジストリ キー KEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Setup!LogLevel を 0x2000ffff に設定します。
  2. 問題を再現し、%windir%\inf\setupapi* で Setupapi ログを確認します
  3. デバイスのインストールに関する問題の根本原因については、「Setupapi.log ファイルを使用したトラブルシューティング」を参照してください。{2}

デバイスが見つからないか、起動しなかったことを示すエラーがログに含まれている場合は、デバッガーから !pnptriage を実行して出力を確認します。 テスト エラーのデバッグに関する詳細は、「カーネル デバッグを使用した Device Fundamentals 信頼性テストのエラーのデバッグ」を参照してください。

Windows HLK を使用した Device Fundamentals 信頼性テストのトラブルシューティング