Freigeben über

Reproduzieren des Testfehlers durch Ausführen des Tests über die Befehlszeile

  • Artikel

Es ist manchmal hilfreich, Testfehler zu reproduzieren, indem die Tests über die Befehlszeile ausgeführt werden. In der folgenden Dokumentation wird davon ausgegangen, dass das Hardware Lab Kit (HLK) bereits auf dem Controllercomputer installiert ist.

Ausführen eines Gerätegrundlagentests über die Befehlszeile

So führen Sie einen Gerätegrundlagentest über die Befehlszeile aus

  1. Erstellen Sie auf dem getesteten System (System Under Test, SUT) einen Ordner C:\temp.

  2. Kopieren Sie alle Dateien aus dem Ordner „\\<hckcontroller>\taefbinaries\<arch>“ in das Verzeichnis C:\temp auf dem SUT.

    Dabei ist <hckcontroller der Name des Windows HLK-Controllers (Windows Hardware Lab Kit) und <arch> die SUT-Plattform.

  3. Um den TAEF-Dienst zu installieren und zu starten, geben Sie die folgenden Befehle an einer Eingabeaufforderung ein:

    1. Wechseln Sie zum oben erstellten Ordner „temp“:

      Auf X86 oder X64: cd C:\temp

      Auf Arm oder Arm64: cd C:\temp\MinTe

    2. wex.services.exe /install:Te.Service

    3. sc start Te.Service

  4. Kopieren Sie alle Dateien aus dem Verzeichnis „\\<hckcontroller>\tests\<arch>\DevFund\“ nach C:\temp.

  5. Wechseln Sie in das Verzeichnis C:\temp, und führen Sie den folgenden Befehl aus (beachten Sie, dass sich „Te.exe“ auf Arm- und Arm64-Systemen in C:\temp\MinTe befindet):

    c:\temp\Te.exe Devfund_<testname>.dll /name:"<test case name>" /p:"DQ=DeviceID='<Device Instance Path of device under test from Device Manager>'" /RebootStateFile:state.xml

    Dabei ist <test case name> der Name des Tests in der Binärdatei.

    Der Schalter „/name“ ist optional. Da einige Binärdateien mehrere Tests enthalten, gibt der Schalter „/name“ an, welche Tests ausgeführt werden sollen. Wenn er nicht angegeben wird, werden alle Tests in der Binärdatei nacheinander ausgeführt. Sie können mit dem folgenden Befehl eine Liste der Tests in einer Binärdatei abrufen:

    Te.exe Devfund_<testname>.dll /list

    Die Datei „Devfund_PnPDTest.dll“ enthält beispielsweise die meisten PnP-bezogenen Tests:

    c:\temp>Te.exe Devfund_PnPDTest.dll /list
Test Authoring and Execution Framework v10.21 for x64

    c:\temp\Devfund_PnPDTest.dll
        PNPDTest
            PNPDTest::PNPDisableAndEnableDevice
            PNPDTest::PNPRemoveAndRestartDevice
            PNPDTest::PNPCancelRemoveDevice
            PNPDTest::PNPCancelStopDevice
            PNPDTest::PNPTryStopAndRestartDevice
            PNPDTest::PNPTryStopDeviceRequestNewResourcesAndRestartDevice
            PNPDTest::PNPTryStopDeviceAndFailRestart
            PNPDTest::PNPSurpriseRemoveAndRestartDevice
            PNPDTest::PNPDIFRemoveAndRescanParentDevice
            PNPDTest::DisableEnhancedDeviceTestingSupport

    Der Befehl zum Ausführen eines einzelnen Tests aus dieser Binärdatei könnte wie folgt lauten:

    c:\temp\Te.exe Devfund_PnPDTest.dll.dll /name:PNPDTest::PNPSurpriseRemoveAndRestartDevice /p:"DQ=DeviceID='my\device\id'" /RebootStateFile:state.xml

    Der Name des Tests in der Binärdatei entspricht nicht genau dem Titel des Tests. Weitere Informationen zur Zuordnung von Testnamen in Binärdateien zu HLK-Testnamen finden Sie unter Device.DevFund-Tests.

Verwenden von /BreakOnError für Unterbrechungen mit einem Wechseln zum Debugger

Wenn die Aufgabe „Test ausführen“ in einem Gerätegrundlagentest zu einem Fehler führt und Sie den Systemstatus im Kerneldebugger gleichzeitig überprüfen möchten, während der Test einen Fehler protokolliert, können Sie den Test manuell an einer Eingabeaufforderung und zusammen mit dem Kerneldebugger ausführen. Übergeben Sie dabei den Befehlszeilenschalter /BreakOnError an Te.exe.

Wenn „Te.exe“ mit dem Schalter /BreakOnError ausgeführt wird, wechselt das System zum Kerneldebugger, wenn der Test damit beginnt, einen Fehler zu protokollieren. Weitere Informationen zum Einrichten eines Kerneldebuggers finden Sie unter Manuelles Einrichten des Debuggings im Kernelmodus.

Wenn Sie einen Gerätegrundlagentest mit dem Schalter /BreakOnError ausführen möchten, fügen Sie diesen wie unten dargestellt hinzu:

Run c:\temp\Te.exe Devfund_<testname>.dll /p:"DQ=DeviceID='<Device Instance Path of device under test from Device Manager>'" /RebootStateFile:state.xml /BreakOnError /name:"*<test case name>*"

Dabei ist <test case name> der Name des Tests.

Beispielszenario für das Debuggen

Sie können den folgenden Fehler untersuchen, indem Sie den Test erneut ausführen und dabei das System zum Debugger wechseln lassen, wenn der Test den Fehler bei der erneuten Ausführung protokolliert.

WDTF_FUZZTEST             : INFO  :    Running IOCTL Fuzzing Test on surface \DosDevices\usb#vid_045e&pid_f0ca&mi_00#7&12099dde&0&0000#{0b9f1048-b94b-dc9a-4ed7-fe4fed3a0deb}\{8de0ff21-6c06-4c27-bfe0-e62612c015ae}. Access Mode=NO SYNC. Open Type=TREE_CONNECT. Opened with access 1201bf 

WDTF_FUZZTEST             : ERROR :    Test thread exceeded timeout limit. Terminating thread

WDTF_FUZZTEST             : ERROR :    Last logged operation: ZwDeviceIoControlFile, CtrlCode=0x22e10b, InBuf=0xfffffc00, 0 OutBuf=0xfffffc00, 0

WDTF_FUZZTEST             : INFO  :    Successfully terminated test thread.

Sie können im Debugger einen Haltepunkt mithilfe des folgenden Befehls festlegen:

Te.exe Devfund_FuzzTest_WLK_Certification.dll /p:"DQ=DeviceID='USB\VID_045E&PID_F0CA&MI_00\7&12099DDE&0&0000'" /RebootStateFile:state.xml /BreakOnError /name:"*IOCTLTest*"

Gerätegrundlagentests werden mit „Te.ProcessHost.exe“ (sofern vorhanden) oder „Te.exe“ ausgeführt (wenn „Te.ProcessHost.exe“ nicht vorhanden ist). Indem Sie die Threads überprüfen, die in diesen Testprozessen ausgeführt werden, können Sie Probleme und/oder Testfehler eingrenzen.

Die Prozess-ID von Te.ProcessHost.exe können Sie mit dem folgenden Befehl abrufen:

!process 0 0 Te.ProcessHost.exe

Wechseln Sie den Prozesskontext im Debugger zum Testprozess:

.process /p /r <process id>

Informationen zum Sicherungsprozess:

!process <process id>

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