OpenVPN TAP-Adapter ließ sich nicht installieren: Welche Phase ist gescheitert?
Eine Fehlermeldung zum Adapter deckt drei Phasen ab: Installationsprogramm, bereitgestelltes Paket, erstelltes Gerät. Lesen Sie den passenden Logabschnitt, bevor Sie etwas löschen.
Das Installationsprogramm meldet, dass der TAP-Adapter nicht erstellt werden konnte, und dieser Satz deckt mindestens drei verschiedene Fehler ab. Das Paket wurde möglicherweise nie bereitgestellt, es wurde bereitgestellt, ohne dass ein Gerät erstellt wurde, oder das Gerät existiert mit einem Problemstatus, den das Installationsprogramm als einen allgemeinen Fehler gemeldet hat. Welchen dieser Fälle Sie haben, entscheidet, wer ihn behebt und welche Nachweise Sie benötigen.
Erfassen Sie zuerst die Buildnummer und den Installationszeitstempel. Beides verwandelt einen Ordner voller Protokolle in eine Suche, die Sie tatsächlich ausführen können.
Drei Phasen, drei verschiedene Protokolle
Die erste Phase ist das Installationsprogramm selbst, das Dateien entpackt, ein eigenes Protokoll führt und einen Sammelcode wie 1603 meldet, der besagt, dass die Transaktion fehlgeschlagen ist, ohne zu sagen, wo. Die zweite ist der Treiberspeicher, in dem ein signiertes Paket zur späteren Verwendung bereitgestellt wird, was eine andere Leistung ist als die Bindung an Hardware. Die dritte ist die Geräteerstellung, bei der Windows eine Geräteinstanz aufbaut, die INF anwendet und das Ergebnis im setupapi-Protokoll festhält. Eine stille Lücke zwischen zwei beliebigen dieser Phasen erzeugt denselben Satz für den Benutzer.
Der Sammelcode gehört zur Transaktion, während die fehlschlagende Aktion weiter oben im selben Protokoll liegt. Suchen Sie rückwärts vom Code aus, statt zu versuchen, den Code zu erklären.
Lesen Sie setupapi.dev.log rund um den Versuch
Jede Geräteinstallation schreibt einen Abschnitt in C:\Windows\INF\setupapi.dev.log, und die SetupAPI-Protokollanleitung erklärt, wie diese Abschnitte und ihr endgültiger Status aufgebaut sind. Finden Sie den Abschnitt, dessen Zeitstempel Ihren Versuch umschließt, und lesen Sie ihn vollständig statt der ersten Fehlerzeile, die Ihnen auffällt. Warnungen zu unabhängigen Geräten erscheinen über ein langes Protokoll verteilt und erklären nichts zu diesem Fehler. Der endgültige Status des passenden Abschnitts ist die Tatsache, die in einem Bericht zitiert werden sollte.
Verknüpfen Sie diesen Abschnitt mit dem Adapternamen, der Geräte-ID und dem im Installationsprotokoll genannten INF-Paket. Drei Kennungen, die bei einem Zeitstempel übereinstimmen, machen die Zuordnung sicher.
Prüfen Sie Paket und Gerät getrennt
Ein bereitgestelltes Paket beweist nur, dass eine signierte INF den Treiberspeicher erreicht hat. In dieser Windows-Generation listet pnputil /enum-drivers Drittanbieterpakete nach Anbieter, Klasse, Version und veröffentlichtem Namen auf, sodass Sie das OpenVPN-Adapterpaket finden können, statt anhand einer oem-Nummer zu raten. Nichts in dieser Liste sagt, dass ein Gerät existiert, gestartet ist oder an das gefundene Paket gebunden ist. Das sind getrennte Fragen mit getrennten Antworten.
Die Geräteseite hat ihre eigene Sicht. Eine schreibgeschützte Adapterinventur zeigt, was Windows derzeit über die Schnittstelle glaubt, und ausgeblendete Einträge decken Geräte ab, die vorhanden, aber inaktiv sind. Der Vergleich der beiden Listen sagt Ihnen, welche Phase fehlgeschlagen ist: Paket fehlt, Gerät fehlt oder Gerät vorhanden mit einem Problemstatus.
Prüfen Sie den Adapter, bevor Sie Signaturen anfassen
Lesen Sie den Zustand vom Rechner statt aus der Zusammenfassung des Installationsprogramms. Die folgenden Befehle listen bereitgestellte Treiberpakete, die Adapterinventur einschließlich ausgeblendeter Einträge und die Netzwerkgeräte auf, die nicht OK melden. Führen Sie sie nach einem Neustart aus, damit ausstehende Geräteoperationen abgeschlossen sind.
pnputil /enum-drivers
Get-NetAdapter -IncludeHidden | Select-Object Name, InterfaceDescription, Status
Get-PnpDevice -Class Net | Where-Object Status -ne 'OK'
Ein vorhandenes Paket ohne passendes Gerät deutet auf die Geräteerstellung hin, und der setupapi-Abschnitt zu diesem Zeitstempel erklärt warum. Ein vorhandenes Gerät mit einem Problemstatus deutet auf den Treiber oder seine Signatur hin, was ein anderes Gespräch ist als ein fehlendes Gerät. Ein Adapter, der existiert und als getrennt meldet, ist ein funktionierendes Gerät ohne aktiven Tunnel und keine fehlgeschlagene Installation. Lesen Sie die drei Ausgaben zusammen, bevor Sie eine Phase zur Reparatur auswählen.
Das Deaktivieren der Signaturerzwingung, das Zurücksetzen des Netzwerkstapels oder das Löschen aller Adapter lässt die Nachweise verschwinden. Nichts davon repariert eine Phase, die Sie noch nicht identifiziert haben, und jede Maßnahme entfernt, was Ihnen gesagt hätte, welche Phase es war.