Adattatore TAP di OpenVPN non installato: quale fase si è rotta?

Il programma di installazione dice che l’adattatore TAP non è stato creato, e quella frase copre almeno tre guasti diversi. Il pacchetto potrebbe non essere mai stato predisposto, potrebbe essere predisposto senza che sia stato creato un dispositivo, oppure il dispositivo potrebbe esistere con uno stato problematico che il programma ha riportato come un unico errore generico. Quale di questi casi hai davanti decide chi deve ripararlo e quali prove ti servono.

Raccogli il numero di build e la data e ora dell’installazione prima di tutto il resto. Entrambi trasformano una cartella di registri in una ricerca che puoi davvero eseguire.

Tre fasi, tre registri diversi

La prima fase è il programma di installazione stesso, che scompatta i file, tiene un proprio registro e riporta un codice di riepilogo come 1603 che dice che la transazione è fallita senza dire dove. La seconda è l’archivio dei driver, dove un pacchetto firmato viene predisposto per un uso successivo, che è un risultato diverso dal legarlo all’hardware. La terza è la creazione del dispositivo, dove Windows costruisce un’istanza del dispositivo, applica il file INF e registra l’esito nel registro setupapi. Un silenzio tra due qualsiasi di queste fasi produce la stessa frase per l’utente.

Il codice di riepilogo appartiene alla transazione, mentre l’azione fallita si trova più indietro nello stesso registro. Cerca all’indietro dal codice invece di provare a spiegare il codice.

Leggi setupapi.dev.log intorno al tentativo

Ogni installazione di un dispositivo scrive una sezione in C:\Windows\INF\setupapi.dev.log, e la guida al registro SetupAPI spiega come sono organizzate quelle sezioni e il loro stato finale. Trova la sezione la cui data e ora racchiude il tuo tentativo, poi leggila tutta invece della prima riga di errore che noti. Gli avvisi su dispositivi non correlati compaiono ovunque in un registro lungo e non spiegano nulla di questo guasto. Lo stato finale della sezione corrispondente è il dato che vale la pena citare in un rapporto.

Correla quella sezione con il nome dell’adattatore, l’identificatore del dispositivo e il pacchetto INF indicato nel registro del programma di installazione. Tre identificatori che concordano su un’unica data e ora sono ciò che rende sicura l’attribuzione.

Controlla separatamente il pacchetto e il dispositivo

Un pacchetto predisposto prova solo che un INF firmato è arrivato all’archivio dei driver. Su questa generazione di Windows, pnputil /enum-drivers elenca i pacchetti di terze parti per fornitore, classe, versione e nome pubblicato, il che ti permette di trovare il pacchetto dell’adattatore OpenVPN invece di indovinare da un numero oem. Nulla in quell’elenco dice che un dispositivo esista, sia stato avviato o sia legato al pacchetto che hai trovato. Sono domande separate con risposte separate.

Il lato dispositivo ha la sua visuale. Un inventario degli adattatori in sola lettura mostra ciò che Windows crede attualmente dell’interfaccia, e le voci nascoste coprono i dispositivi presenti ma inattivi. Confrontare i due elenchi ti dice quale fase è fallita: pacchetto assente, dispositivo assente o dispositivo presente con uno stato problematico.

Verifica l’adattatore prima di toccare le firme

Leggi lo stato dalla macchina invece che dal riepilogo del programma di installazione. I comandi seguenti elencano i pacchetti driver predisposti, l’inventario degli adattatori comprese le voci nascoste e i dispositivi di rete che non riportano OK. Eseguili dopo un riavvio, così le operazioni sui dispositivi in sospeso si sono concluse.

pnputil /enum-drivers
Get-NetAdapter -IncludeHidden | Select-Object Name, InterfaceDescription, Status
Get-PnpDevice -Class Net | Where-Object Status -ne 'OK'

Un pacchetto presente senza un dispositivo corrispondente indica la creazione del dispositivo, e la sezione setupapi di quella data e ora spiega perché. Un dispositivo presente con uno stato problematico indica il driver o la sua firma, che è una conversazione diversa da un dispositivo mancante. Un adattatore che esiste e riporta disconnesso è un dispositivo funzionante senza tunnel attivo, non un’installazione fallita. Leggi insieme i tre output prima di scegliere una fase da riparare.

Disattivare l’applicazione delle firme, reimpostare lo stack di rete o eliminare ogni adattatore fa sparire le prove. Nessuna di queste tre cose ripara una fase che non hai ancora identificato, e ciascuna rimuove ciò che ti avrebbe detto quale fase fosse.