Freigeben über

Überprüfen allgemeiner Fehler bei Testvoraussetzungen für die Zuverlässigkeit von Gerätegrundlagen

  • Artikel

In diesem Thema werden allgemeine Testfehler beschrieben, die auftreten können, wenn Sie grundlegende Windows Hardware Lab Kit (Windows HLK)-Gerätezuverlässigkeitstests ausführen.

Der Test ist in HLK Studio als fehlgeschlagen gekennzeichnet, aber im te.wtl-Protokoll werden nur Pass-Ergebnisse angezeigt.

Wenn der Test in HLK Studio als fehlgeschlagen gekennzeichnet ist, aber im te.wtl-Protokoll nur Pass-Ergebnisse angezeigt werden, können Sie den Fehler abrufen, der den Fehler verursacht hat, indem Sie die folgenden Schritte ausführen:

  1. Klicken Sie mit der rechten Maustaste auf das rote Symbol Test ausführen.
  2. Wählen Sie Fehler aus.

Es wird ein Dialogfeld mit einer Beschreibung des aufgetretenen Fehlers angezeigt.

Fehler beim Test, weil ein unerwarteter Neustart während des Tests aufgetreten ist

Wenn der Fehlertext angibt, dass ein unerwarteter Neustart aufgetreten ist, bedeutet dies wahrscheinlich, dass das Gerät das Betriebssystem unerwartet neu gestartet hat (BSOD). Um diesen Fehler zu diagnostizieren, fügen Sie einen Debugger an, oder konfigurieren Sie den Testcomputer für das Generieren automatischer Speicherabbilder, und untersuchen Sie die Fehlerprüfung. Informationen zum Beginnen mit dem Kerneldebugging von Testfehlern finden Sie unter Verwenden des Kerneldebugs zum Debuggen von Fehlern bei Zuverlässigkeitstests der Gerätegrundwerte.

Fehler bei der Gerätestatusüberprüfung während des Setups

Gerätestatusprüfungsaufgaben schlagen häufig fehl, da das Gerät nicht ordnungsgemäß mit Medien oder einer Verbindung eingerichtet ist, bevor der Test gestartet wird. Informationen zum ordnungsgemäßen Konfigurieren eines Geräts zum Testen finden Sie unter Voraussetzungen für Device.Fundamentals-Zuverlässigkeitstests.

Die Gerätestatusprüfungsaufgabe ist in der Setupphase aller grundlegenden Gerätezuverlässigkeitstestaufträge enthalten. Dabei wird ein Tool ausgeführt, um sicherzustellen, dass das getestete Gerät (DUT) funktionsfähig ist. Wenn es fehlschlägt, wird ein Protokoll erstellt, das das Problem mit dem Gerät angibt.

Beispielsweise erhalten Sie für Bluetooth-Geräte möglicherweise den folgenden Fehler:

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

Diese Fehlermeldung kann darauf hinweisen, dass Sie vor dem Testen eine Verbindung mit dem Bluetooth-Gerät herstellen müssen, indem Sie die Audiosteuerung verwenden.

Im folgenden Beispiel meldet das Testgerät den Problemcode A - CM_PROB_FAILED_START Status. Es sollte Problemcode 0 (kein Problem) gemeldet werden.

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

Gerätepfadprüfung schlägt mit dem Fehler "Testthread hat Timeoutlimit überschritten. Fehler beim Beenden des Threads" fehl.

Wenn der Test den Fehler Testthread hat Timeoutlimit überschritten. Fehler beim Beenden des Threads während eines Gerätepfadprüfungstests protokolliert, wird dabei auch der letzte Vorgang protokolliert, der ausgeführt wurde. Treiberentwickler müssen bestimmen, warum der letzte protokollierte Vorgang dazu führt, dass der Test unterbrochen wird. Beispiel:

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

Der spontane Test mit Entfernen schlägt mit der Fehlermeldung "Fehler beim Empfangen von IRP_MN_REMOVE_DEVICE nach dem Empfangen von IRP_MN_SURPRISE_REMOVAL" fehl.

Der DF - PNP-Spontantest mit entferntem Gerät schlägt möglicherweise mit der folgenden Fehlermeldung fehl, wenn der PnP-Manager das IRP Entfernen nicht an den Testgerätstapel sendet, nachdem das IRP Spontanes Entfernen gesendet wurde:

"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."

Der PnP-Manager sendet die Anforderung IRP_MN_REMOVE_DEVICE erst, wenn alle ausstehenden Dateihandles für das Gerät geschlossen werden. Das heißt, der PnP-Manager sendet die Anforderung IRP_MN_REMOVE_DEVICE erst, wenn die PDO-Referenzanzahl Null erreicht. Informationen zum ordnungsgemäßen Umgang mit der Anforderung IRP_MN_SURPRISE_REMOVAL Anforderung finden Sie unter Umgang mit einer IRP_MN_SURPRISE_REMOVAL-Anforderung.

Um diesen Testfehler zu debuggen, sollten Sie bestimmen, wie sich die Referenzanzahl des physischen Geräteobjekts (PDO) ändert. Identifizieren Sie den Prozess, der die Referenzanzahl ändert, und überprüfen Sie, wie die Aufrufliste aussieht, wenn sich die Referenzanzahl geändert hat. Die folgenden Schritte können zum Debuggen dieses Fehlers verwendet werden:

  1. Wenn Sie dies noch nicht getan haben, verbinden Sie einen Kernel-Debugger mit dem Testcomputer. Siehe Konfigurieren eines Computers für Treiberbereitstellung, Tests und Debuggen.

  2. Legen Sie einen Haltepunkt vom Typ ba (Break on Access) an der Stelle fest, an der die Referenzanzahl des PDO für das Testgerät gespeichert ist. Weitere Informationen zu Zugangshaltepunkten finden Sie unter Prozessorhaltepunkte (ba-Haltepunkte). Im folgenden Beispiel erhält der Kernel-Debugger-Befehl !devnode Informationen zum Devnode für den USBvideo-Treiber. Die Adresse des PDO für diesen Devnode ist 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. Verwenden Sie den Befehl !devobj im PDO, um Informationen zur Referenzanzahl (RefCount) des PDO anzuzeigen.

    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. Überprüfen Sie das PDO-Geräteobjekt mithilfe des Kernel-Debuggerbefehls dt (Display Type). Der Wert unter ReferenceCount zeigt die Anzahl geöffneter Handles für das Gerät an, die dem Geräteobjekt zugeordnet sind.

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

  5. Wenn die Referenzanzahl größer als 0 ist, bevor Sie den Test starten:

    • Legen Sie einen Haltepunkt fest, an dem das PDO erstellt wird.

    • Legen Sie nach der Erstellung des PDO den Haltepunkt für den Zugriff (ba) an der Stelle fest, an der die Referenzanzahl des PDO gespeichert ist.

      Der folgende Befehl legt beispielsweise einen Haltepunkt vom Typ ba (Break on Access) auf dem Geräteobjekt (0x849e9648) fest. Der Haltepunkt wird auf schreibgeschützten Zugriff auf ReferenceCount (+4 Offset) mit einer Größe von 4 Bytes festgelegt (die Größe von ReferenceCount).

      0: kd> ba w 4 849e9648+4

    • Wenn die Referenzanzahl des PDO gleich 0 ist, bevor der Test gestartet wird, führt das Ausführen des Tests wahrscheinlich dazu, dass die Referenzanzahl des PDO größer als Null ist, wenn der Test das Gerät spontan entfernt. Dies deutet in der Regel auf ein Handle-Leck hin. Führen Sie den PNP-Gerätetest mit spontanem Entfernen in einem Eingabeaufforderungsfenster oder in Visual Studio aus, um den Fehler zu reproduzieren und die Informationen zu erfassen, die zum Beheben des Problems erforderlich sind.

    Hinweis

    Wenn Sie den Parameter DoConcurrentIO auf TRUE festlegen, öffnet der Test mehrere hundert Dateihandles für das PDO. Es wird empfohlen, diesen Parameter auf FALSE festzulegen, wenn Sie diesen Fehler reproduzieren.

  6. Wenn der Haltepunkt für den Zugriff (ba) auftritt, können Sie den Kernel-Debuggerbefehl !thread und k (Display Stack Backtrace) verwenden, um den Fehler zu debuggen. Da sich die Referenzanzahl während der Testausführung mehrmals ändern kann, können Sie den Parameter CommandString des Debuggerbefehls ba (Break on Access) verwenden, um die Informationen abzurufen, die Sie für jede Änderung der Referenzanzahl benötigen. Zudem können Sie die Tests fortsetzen.

    Beispielsweise besteht in der folgenden Unterbrechung des Zugriffsbefehls der CommandString einerseits aus einem !thread-Befehl, der den Prozess identifiziert, der die Referenzanzahl ändert, und andererseits aus den .reload ; k 100-Befehlen, die die Aufrufliste identifizieren, dem !devobj-Befehl zum Ausgeben der Referenzanzahl für jede Änderung sowie dem g-Befehl, um nach dem Haltepunkt fortzufahren.

    0: kd> ba w 4 849e9648+4 "!thread; .thread /p /r; .reload; k 100; !devobj 849e9648; g"

Beispiel:

Im folgenden Beispiel führt der CreateFile-Funktionsaufruf aus einem Thread, der in cscript.exe ausgeführt wird, zu einer Inkrementierung der Referenzanzahl. Die Erfassung aller Instanzen, in denen die Referenzanzahl geändert wird, während der Test ausgeführt wird und das Analysieren dieser Aufruflisten können dabei helfen, die Handle-Lecks zu identifizieren.

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-Plug-Ins-Protokollfehler

Bei den Tests der grundlegenden Gerätezuverlässigkeit kommen bereitgestellte WDTF Simple I/O-Plugins zum Einsatz, um die E/A auf Geräten zu testen. SimpleIO-Plugins sind WDTF-Erweiterungen, die die generische gerätespezifische EA-Funktionalität testen. Wenn ein WDTF-Plugin für den Typ des Geräts vorhanden ist, das getestet wird, verwendet der Test die IWDTFSimpleIOStressAction2-Schnittstelle zum Testen der E/A auf dem Gerät.

Fehler, die von WDTF SimpleIO-Plugins protokolliert werden, verwenden das WDTF_SIMPLE_IO-Tag in der Datei "TestTextLog.log" (siehe WDTF-Objektnamentags). Die Fehlermeldung identifiziert immer das getestete Gerät und den spezifischen Grund für den Fehler.

Beispiel:

In diesem Beispiel hat das Wireless SimpleIO-Plugin einen Fehler protokolliert, der während des Tests eines 802.11n USB Wireless LAN Card-Geräts aufgetreten ist. Insbesondere hat das SimpleIO-Plugin die Gatewayadresse mithilfe einer IcmpSendEcho-Funktion angepingt, die den Fehler 11010 zurückgegeben hat. Dieser Fehler äußert sich als Fehler aufgrund fehlender Ressourcen.

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.

Das Testen der E/A auf einem bestimmten Gerät hängt dauerhaft und führt schließlich dazu, dass der Test aufgrund eines Timeouts fehlschlägt.

Bei den Zuverlässigkeitstests der Gerätegrundwerte handelt es sich um szenariobasierte Tests, die E/A-Tests mit PNP-Leistungstestszenarien & kombinieren. Bei den Tests wird die E/A in der Regel zwei Minuten lang vor und nach einem Szenario getestet. Bei dem Test DF – Ruhezustand mit EA vorher und nachher geschieht beispielsweise Folgendes:

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

Der Test testet mehrmals bei der bei der Ausführung die E/A auf Geräten (einmal für jeden Ruhezustand). Informationen dazu, wie Sie dies in den Protokolldateien nachvollziehen können, finden Sie unter Überprüfen von Protokolldateien.

Einer der häufigen Fehler beim Testen der E/A besteht darin, dass das Testen der E/A auf einem bestimmten Gerät dauerhaft hängen kann. Dies führt dazu, dass der Test nach einem Timeoutzeitraum (in der Regel Stunden) fehlschlägt. Weitere Informationen zum Identifizieren von Fehlern, die durch Timeout verursacht werden, finden Sie unter Problembehandlung bei Windows HLK-Testfehlern.

Hinweis

Windows HLK beendet den hängenden Prozess nach dem Timeoutzeitraum. Anstatt darauf zu warten, dass der Test aufgrund eines dauerhaften Hängens fehlschlägt, empfehlen wir, das Hängen zu untersuchen, während der aufgehängte Prozess weiterhin auf dem System ausgeführt wird. Lesen Sie den Abschnitt Test hängt des Themas Problembehandlung für Zuverlässigkeitstests für Gerätegrundwerte mithilfe des Windows HLK, um Informationen zur Problembehandlung von aufgehängten Tests zu finden.

Je nachdem, für wie viele Geräte die E/A getestet wird, kann das aufgehängte Gerät wie folgt identifiziert werden:

  1. Wenn die Anzahl Geräte, auf denen die E/A getestet wird, eins ist, wird für mehr als zehn Minuten kein Fortschritt im Befehlsfenster angezeigt. Der letzte Protokolleintrag im Befehlsfenster verfügt über das Tag WDTF_SIMPLE_IO oder WDTF_SIMPLEIO_STRESS, und er identifiziert das aufgehängte Gerät. Weitere Informationen zum Lesen der Testprotokolldateien finden Sie unter Überprüfen von Protokolldateien.

  2. Wenn die Anzahl Geräte, auf denen die E/A getestet wird, größer als eins ist, werden konstant Meldungen vom Typ PerformIO(<Device Name>) Count ... für mehr als zehn Minuten im Befehlsfenster angezeigt. Der Test versucht, die E/A-Tests auf jeweils einem Gerät nach zwei Minuten zu beenden. Wenn der Stoppvorgang für ein bestimmtes Gerät erfolgreich ist, sollte in den Protokollen für das Gerät die Meldung "Beenden" gefolgt von der Meldung "Schließen" angezeigt werden. Wenn die Meldung "Beenden" angezeigt wird, aber die entsprechende Meldung "Schließen" für ein Gerät nicht angezeigt wird, bedeutet dies, dass das Testen der E/A auf dieses Gerät aufgehängt wird.

Beispiel:

Im folgenden Fall ist das mobile Breitbandgerät das Problemgerät, da zwar die Meldung "Beenden" vorliegt, es aber keine entsprechende Meldung "Schließen" gibt. Andererseits verfügt das I2C HID-Gerät sowohl über eine Meldung vom Typ "Beenden" als auch vom Typ "Schließen", was bedeutet, dass der Test die E/A auf dem Gerät ohne Probleme beenden konnte. Der Test hätte den E/A-Test auf den Microsoft Basic Render Driver- und Microsoft ACPI-konformen Systemgeräten nie beenden können. Daher werden für dies Geräte permanent "PerformIO"-Nachrichten angezeigt.

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
…
…

Der nächste Schritt besteht darin, die Stapelüberwachung der Threads im Testprozess zu überprüfen, um zu ermitteln, warum das Testen der E/A auf dem mobilen Breitbandgerät aufgehängt ist. Sie werden feststellen, dass einer der Threads im Testprozess verwendet wird, um die E/A speziell auf dem mobilen Breitbandgerät zu testen. Weitere Informationen zur Problembehandlung finden Sie unter Verwenden des Kerneldebuggings zum Debuggen von Fehlern bei den Zuverlässigkeitstests der Gerätegrundwerte.

Tests werden nicht aus dem Ruhezustand fortgesetzt

Die Zuverlässigkeitstests der Gerätegrundwerte basieren auf Systemaktivierungstimern, die das das Testsystem während der Power Management-Tests aus dem Ruhezustand zu reaktivieren. Fehlerhafte Aktivierungstimer können verhindern, dass das Testsystem während der Testläufe automatisch reaktiviert wird. Wenn das Testsystem nicht automatisch aus dem Ruhezustand reaktiviert wird, müssen Sie sich möglicherweise an Ihren BIOS-Anbieter wenden, um eine BIOS-Korrektur zu veröffentlichen, die die Probleme mit dem Aktivierungstimer behebt. Alternativ können Sie die Tests auf einem anderen System ausführen, auf dem die Aktivierungstimer erwartungsgemäß funktionieren.

Das System kann auch aufgrund von Treiberfehlern dauerhaft während des Ein- oder Ausschaltvorgangs hängen. In diesem Fall sollten Sie den Test erneut ausführen, indem Sie das mit einem Kerneldebugger verbundene Testsystem verwenden und das System vom Kerneldebugger debuggen.

Informationen zum Einrichten eines Kerneldebuggers finden Sie unter Manuelles Einrichten des Debuggings im Kernel-Modus. Eine allgemeinen Anleitung zur Problembehandlung bei Systemabbrüchen während der Windows HLK-Testausführungen finden Sie unter Problembehandlung bei Windows HLK-Testfehlern.

WirelessPlugin: ConnectToTestProfile() – Fehler beim Herstellen einer Verbindung mit dem Testprofil. Ursachenzeichenfolge: "Das spezielle Netzwerk ist nicht verfügbar." Fehlermeldung

Die Tests der Gerätegrundwerte schlagen mit dieser Fehlermeldung fehl, wenn die richtigen Werte für Wpa2PskAesSid- und Wpa2PskPassword-Parameter zum geplanten Testzeitpunkt nicht für den Test bereitgestellt wurden. Für die Tests müssen Sie Verbindungsinformationen (SSID und Kennwort) eines Testnetzwerks bereitstellen, wenn es sich bei einem der getesteten Geräte um einen WLAN-Adapter handelt. Weitere Informationen zu diesen Testparametern finden Sie im Abschnitt "Parameter" der Dokumentationsseite des fehlerhaften Tests.

WDTFSensorsPlugin: Open() – GPS-Sensor ist nicht in bereiten Zustand gewechselt

Die Zuverlässigkeitstests für Gerätegrundwerte erfordern Systeme mit einem GPS-Sensor, der in einer Umgebung getestet werden soll, in der ein starkes GPS-Signal vorhanden ist (damit die Tests E/A auf dem GPS-Sensorgerät testen können). Dieser Fehler gibt an, dass der GPS-Sensor auf dem Testsystem keinen GPS-Fix erhalten kann. Denken Sie darüber nach, die Tests an einem Ort auszuführen, an dem das Testsystem ein starkes GPS-Signal erhalten kann.

Testprotokollmeldung: Die Anzahl Geräte, die nach dem Neustart (1) gefunden wurden, ist nicht identisch mit dem Wert vor dem Neustart (2); Überprüfen Sie die Protokolle, um die fehlenden Geräte zu finden.

Diese Meldung gibt an, dass eines der Geräte nach dem Neustart nicht mehr vorhanden ist. Um diesen Fehler zu untersuchen, generieren und analysieren Sie die ausführlichen Setupapi-Protokolle für Neuinstallations-, Neustart- und Neustarttests, indem Sie die folgenden Schritte ausführen:

  1. Um ausführliche Setupapi-Protokolle zu generieren, legen Sie den Registrierungsschlüssel KEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Setup!LogLevel auf 0x2000ffff fest
  2. Wiederholen Sie das Problem, und überprüfen Sie dann die Setupapi-Protokolle unter "%windir%\inf\setupapi*"
  3. Informationen zur Ursache von Geräteinstallationsproblemen finden Sie unter Problembehandlung mithilfe der Setupapi.log-Datei

Wenn das Protokoll einen Fehler enthält, der besagt, dass das Gerät fehlt oder nicht gestartet wurde, führen Sie !pnptriage vom Debugger aus, und überprüfen Sie die Ausgabe. Weitere Informationen zum Debuggen von Testfehlern finden Sie unter Verwenden des Kerneldebuggings zum Debuggen von Fehlern bei Zuverlässigkeitstests für Gerätegrundwerte.

Problembehandlung bei Testvoraussetzungen für die Zuverlässigkeit von Gerätegrundlagen mithilfe von Windows HLK