Fehler beim Exportieren eines HLK-Auftrags

Sie können einen fehlerhaften Auftrag jetzt exportieren, sodass er auf einem Computer außerhalb der vollständigen HLK-Umgebung (Hardware Lab Kit) ausgeführt werden kann. Treiberentwicklern ermöglicht dieses Feature die eigenständige Ausführung des Tests, um den Prozess zum Reproduzieren von Fehlern zu vereinfachen.

Eine exportierte Testumgebung simuliert eine dedizierte HLK-Umgebung genau. Dies garantiert jedoch keine identische Testausführung. Folgende Situationen können auftreten und müssen ggf. vom Benutzer behandelt werden:

• Neustarts werden nicht von der Testinfrastruktur verarbeitet. Der Benutzer muss das System in vielen Fällen manuell neu starten.
• Es kann Fälle geben, in denen der Test das System über die HLK-Clientinfrastruktur innerhalb einer Testaufgabe neu startet. Beispielsweise werden diese Neustarts während der eigenständigen Ausführung möglicherweise nicht in der Batchdatei als Eingabeaufforderungen oder Neustarts erfasst.
• Nicht eindeutig benannte Protokolldateien, die von unterschiedlichen Aufgaben an denselben Speicherort geschrieben werden, können dazu führen, dass einige dieser Dateien überschrieben werden.
• In die Batchdatei geschriebene Parameter können sich bei der Ausführung auf verschiedenen Systemen unterscheiden. Hardwareinstanz-IDs für dieselbe Hardware und denselben Treiber können sich beispielsweise unterscheiden, wenn sie in ein anderes System verschoben werden. In diesem Fall muss der Benutzer den entsprechenden Zielwert ermitteln (z. B. im Geräte-Manager) und die Batchdatei mit dem korrekten Wert aktualisieren.
• Tests, die zum Konfigurieren des Systems von einem zugeordneten Konfigurationsauftrag abhängig sind, werden möglicherweise nicht korrekt vorbereitet, da das HLK nur den Testauftrag selbst exportiert.

Nicht alle Ergebnisse können exportiert werden. In der folgenden Liste werden die Einschränkungen für die exportierbaren Tests und Testergebnisse beschrieben:

• Tests müssen ausgeführt und mit dem Status „bestanden“, „fehlerhaft“ oder „abgebrochen“ abgeschlossen sein.
• Der Testlauf muss erfolgreich Infrastrukturprotokolle vom Clientsystem zurückgeben. Diese Dateien sind erforderlich, um den Test zu exportieren.
• Es können nur Einzelcomputertests exportiert werden. Tests, die eine Ausführung mehrerer Computer erfordern, können nicht exportiert werden.
• Tests müssen mithilfe des HLK-Desktopclients ausgeführt werden. Testläufe auf Windows Core- oder Proxy Mobile Client-Systemen sind nicht exportierbar.
• Tests, die aufgrund bekannter Infrastrukturprobleme oder aus anderen Gründen als nicht exportierbar gekennzeichnet sind, können nicht exportiert werden.

1. Klicken Sie in HLK Studio auf der Registerkarte Ergebnisse mit der rechten Maustaste auf das fehlerhafte Ergebnis, und wählen Sie Testlauf exportieren aus.

2. Ein Dialogfeld „Speichern“ wird angezeigt. Speichern Sie den exportierten Auftrag auf einem Speicherstick oder an einem anderen externen Speicherort, damit Sie den exportierten Test auf einem anderen Computer ausführen können. Der gleiche Test kann nur einmal an denselben Speicherort exportiert werden. In einem Dialogfeld wird bestätigt, dass der Export abgeschlossen ist.

3. Die Testbinärdateien und eine Batchdatei, die zum Ausführen des Tests auf einem eigenständigen System erforderlich ist, werden in das angegebene Verzeichnis exportiert. Der exportierte Test wird in einem Unterverzeichnis mit dem Namen und der Architektur des fehlerhaften Auftrags gespeichert. Infrastrukturkomponenten, die zum Ausführen des Tests installiert werden müssen, werden in einem Unterverzeichnis namens Infrastruktur mit dem Namen der Zielarchitektur der Infrastruktur gespeichert.

Beispiel: Wenn Sie einen fehlerhaften x64-Auftrag mit dem Titel Set Render Target im Stammverzeichnis des Laufwerks E:\ speichern, werden der Auftragsordner und das Infrastrukturinstallationsprogramm mit der folgenden Ordnerstruktur exportiert:

E:.
├───Infrastructure(X64)
└───Set_Render_Target(X64)
    ├───CoreClr
    ├───MinTe
    │   └───CoreClr
    ├───NetFx2.0
    ├───NetFx4.5
    ├───verifysupportfiles
    │   ├───CoreClr
    │   ├───MinTe
    │   │   └───CoreClr
    │   ├───NetFx2.0
    │   └───NetFx4.5
    └───[windir]
        └───system32 

Das exportierte Testpaket enthält mehrere Dateien und Unterordner, einschließlich der folgenden:

• readme1st.txt: enthält Informationen zum Ausführen des exportierten Tests
• run.cmd: eine Batchdatei, die zum Ausführen des Tests verwendet wird
• Binärdateien und andere Dateien, die zum Ausführen des Tests erforderlich sind
• setup(Architektur).exe: die ausführbare Datei, die zum Installieren der Infrastruktur verwendet wird

4. Speichern Sie den exportierten Testordner auf dem neuen Computer für Tests. Der Pfad darf keine Leerzeichen enthalten, da dies bei einigen Tests zu Fehlern führt.

5. Führen Sie vor dem Ausführen des Tests die Datei „(Speicherordner)\Infrastruktur(Architektur)\setup(Architektur).exe“ aus, um die Infrastrukturkomponenten zu installieren. Das Infrastrukturinstallationsprogramm zeigt in einem Dialogfeld an, ob die Installation der Komponenten erfolgreich war.

6. In der Batchdatei im Ordner Speicherordner (Auftragsname)(Architektur) können Sie alle erforderlichen Änderungen an der Batchdatei vornehmen, die auf Ihrem Testcomputer ausgeführt werden soll. Sie können beispielweise die folgenden Änderungen vornehmen:

• Auskommentieren von Zeilen, die nicht zum Auftragsfehler beitragen.
• Ändern von Parameterwerten entsprechend dem Computer, auf dem der exportierte Test ausgeführt wird. Die Instanz-ID derselben Hardware unterscheidet sich beispielsweise häufig auf zwei separaten Systemen und muss daher vor dem Ausführen des exportierten Tests aktualisiert werden.
• Hinzufügen von Befehlen zum Herstellen einer Verbindung mit einem Debugger.

cmd /c TE.exe /inproc /enablewttlogging /appendwttlogging devfund_pcirootportsurpriseremovetest_wlk_certification.dll
/p:"MultiDeviceHardwareIdSdelQueryHardwareID=!MultiDeviceHardwareIdSdelQueryHardwareID!"
/p:"MultiDeviceInstanceIdSdelWDKDeviceID=!MultiDeviceInstanceIdSdelWDKDeviceID!" /p:"DQ=!DQ!"
/p:"TestCycles=!TestCycles!" /p:"IOPeriod=!IOPeriod!" /p:"WDTFREMOTESYSTEM=!WDTFREMOTESYSTEM!"
/p:"Wpa2PskAesSsid=!Wpa2PskAesSsid!"
/p:"DriverVerifierAdditionalDrivers=!DriverVerifierAdditionalDrivers!"
/p:"DriverVerifierExcludedFlags=!DriverVerifierExcludedFlags!"
/p:"DriverVerifierCustomizeConfiguration=!DriverVerifierCustomizeConfiguration!"
/rebootStateFile=rebootstatefile.xml

7. Nachdem Sie die Änderungen vorgenommen haben, starten Sie eine Eingabeaufforderung mit Administratorberechtigungen, wechseln Sie zum Testverzeichnis, und führen Sie „run.cmd“ aus. Jeder Aufgabe in der Batchdatei ist eine Aufgabennummer zugeordnet, die beim Ausführen der Batchdatei als Ausgangspunkt verwendet werden kann. Standardmäßig wird die Ausführung zwischen Aufgaben angehalten. Die folgenden Ausführungsmodi werden unterstützt:

• „Run“ ohne Parameter startet die Ausführung am Anfang der Batchdatei und hält sie zwischen den einzelnen Aufgaben an.
• „Run 5“ startet die Batchdatei und springt zu Aufgabe 5.
• „Run FAST“ startet die Batchdatei am Anfang im schnellen Modus (keine Pause zwischen Aufgaben).
• „Run 5 FAST“ startet die Batchdatei bei Aufgabe 5 im schnellen Modus (keine Pause zwischen Aufgaben).
• „RebootResume“ startet die Batchdatei beim letzten Neustart bei der letzten Ausführung des Skripts. Das FAST-Flag wird auch unterstützt.
• „RerunLast“ startet die Batchdatei bei dem Befehl, der bei der letzten Beendigung der Batchdatei ausgeführt wurde. Mit diesem Befehl können Sie eine Aufgabe mehrmals erneut ausführen, indem Sie das Skript während der Aufgabe durch Drücken von STRG+C beenden und „rerunlast.cmd“ ausführen, um den vorherigen Befehl erneut auszuführen. Das FAST-Flag wird auch unterstützt.

8. Sobald Sie das Problem, das den Fehler beim Test verursacht, identifiziert und behoben haben, können Sie den Fix bereitstellen und überprüfen, ob der Auftrag in der HLK-Umgebung erfolgreich ausgeführt wird.