Problembehandlung bei LAN-Tests
Führen Sie die folgenden Schritte aus, um Probleme zu beheben, die bei Device.Network-Tests auftreten:
Überprüfen Sie die Windows HLK-Versionshinweise auf aktuelle Testprobleme.
Suchen Sie verwendbare Informationen zu einem Testfehler im Windows HLK Studio-Testprotokoll. Wenn Sie brauchbare Informationen finden, beheben Sie das Problem und führen Sie den Test erneut aus.
Wenn die beiden Computer-LAN-Testaufträge fehlschlagen, ist es wahrscheinlich, dass die Tests die Nachricht und/oder die Unterstützung von Geräten auf einem der beiden Computer nicht erkennen können.
Um diesen Problemtyp schnell zu diagnostizieren, führen Sie den Auftrag „NDISTest 6.5 - [2 Computer] - CheckConnectivity“ aus. Das Ausführen dieses Auftrags dauert nur wenige Minuten, teilt Ihnen jedoch mit, ob die Computer kommunizieren können und bereit sind, die restlichen Computeraufträge auszuführen.
Wenn ein Verbindungsproblem auftritt, schlägt der Auftrag in der Aufgabe „NDISTest Client ausführen“ fehl. Die Protokolldateien des Auftrags werden Fehler aufführen, wenn die Test- und Support-NICs nicht bidirektional kommunizieren können. Überprüfen Sie die Ergebnisse in den Protokolldateien des Auftrags, prüfen Sie die Verbindungen der Computer, und versuchen Sie, den Auftrag erneut auszuführen.
Sie sollten außerdem überprüfen, ob Sie den richtigen Computer als Supportcomputer auswählen. Bei Multiport-NICs und mehreren Computersetups ist es sehr einfach, den falschen NIC oder falschen Computer auszuwählen. Wir empfehlen, die beiden Computer, die LAN-Tests ausführen, in ihrem eigenen Computerpool zu halten, um das versehentliche Auswählen des falschen Computers zu vermeiden.
NDISTest 6.5 - [2 Computer] - CheckConnectivity-Auftrag
Der Auftrag „NDISTest 6.5 - [2 Computer] - CheckConnectivity“ stellt sicher, dass die Test- und Supportgeräte ordnungsgemäß kommunizieren können, indem er ein einfaches Senden und Empfangen durchführt.
Wenn die Aufgabe „Skript ausführen, um Geräte zu erkennen und Parameter aufzufüllen“ als fehlgeschlagen gekennzeichnet ist, dann ist die automatische Erkennung des Geräts fehlgeschlagen. Doppelklicken Sie auf „detect.wtl“, um das Protokoll der automatischen Erkennung zu öffnen. Sie können damit ermitteln, welches Gerät nicht erkannt wurde.
Die automatische Erkennung der Geräte funktioniert nur, wenn Computer in der empfohlenen Topologie eingerichtet sind. Der Testcomputer muss die Ziel-NIC und die Nachrichten-NIC enthalten. Der Supportcomputer muss eine Support-NIC und eine Nachrichten-NIC enthalten. Alle zusätzlichen verbundenen Ethernet-Geräte machen die automatische Erkennung unmöglich und erfordern, dass die Geräte umbenannt werden, um ihre Rollen zu bezeichnen.
Die Unterstützungs-NIC muss mit der Test-NIC mit einer direkten Verbindung (ohne Switch oder Hub) verbunden sein, um Störungen zu vermeiden. Die Nachrichten-NICs sind dieselbe NIC, die für die Konnektivität mit dem Controllercomputer und dem Rest des Labors oder Unternehmensnetzwerks verwendet wird.
Die CheckConnectivity-Skriptlogik
Die Skriptlogik der automatischen Erkennung lautet wie folgt:
Suchen Sie den Nachrichten-NIC.
Suchen Sie nach Geräten mit dem Namen „MessageDevice“.
Falls sie keine Geräte finden, suchen Sie nach der Ethernet-NIC mit einer über DHCP zugewiesenen IP-Adresse.
Falls sie weiterhin keine Geräte finden, suchen Sie nach der Ethernet-NIC mit einer statisch zugewiesenen IP-Adresse.
Wenn nichts gefunden wird, lassen Sie die Suche fehlschlagen und beenden Sie diese.
Wenn Sie auf dem Supportcomputer ausführen, suchen Sie die Support-NIC.
Suchen Sie nach Geräten mit dem Namen „SupportDevice0“.
Wenn nichts gefunden wurde, suchen Sie nach einer physischen, aktivierten Ethernet-NIC, welche nicht die Nachrichten-NIC ist.
Wenn nichts gefunden wird, lassen Sie die Suche fehlschlagen und beenden Sie diese.
Sie können die vollständigen Details zur Skriptlogik der automatischen Erkennung kennenlernen, indem Sie das folgende Skript begutachten: \\[CONTROLLER]\Tests\[ARCH]\NDIS\Scripts\detect.wsf
Hierbei gilt:
[CONTROLLER]. Der Name des Controllercomputers.
[ARCH]. Entweder x86 (für x86-basierte Prozessoren) oder amd64 (für x64-basierte Prozessoren).
Lesen der NDISTest-Protokolle
Sie können NDISTest-Protokolle lesen, indem Sie „ndistest.wtl“ doppelklicken oder mit der rechten Maustaste auf das Aufgabenergebnis klicken und zu „Weitere Dateien“ für das Auftragsergebnis wechseln, das Sie anzeigen möchten. Dadurch wird die Protokollanzeige des DTM-Managers geöffnet.
NDISTest erzeugt außerdem HTML-Protokolle, die oft viel einfacher zu lesen sind. Wenn Sie das HTML-Protokoll eines Ergebnisses anzeigen möchten, klicken Sie mit der rechten Maustaste auf das Aufgabenergebnis und wechseln Sie zu „Weitere Dateien“. Es werden mehrere Dateien aufgelistet. Öffnen Sie die Datei „checkconnectivity.htm“ im Ordner „Client“.
Öffnen Sie zusätzlich „ndistest.htm“ im Ordner „Client“, um Fehler aus den Aufgaben „preconfig“ und „postconfig“ anzeigen zu lassen, die vor und nach jedem „NDISTest 6.5“-Test ausgeführt werden.