Adaptér OpenVPN TAP se nepodařilo nainstalovat: která fáze selhala?

Instalátor hlásí, že adaptér TAP nebylo možné vytvořit, a tato věta pokrývá nejméně tři různé závady. Balíček možná nebyl nikdy připraven, mohl být připraven, aniž by vzniklo zařízení, nebo zařízení může existovat se stavem problému, který instalátor nahlásil jako jednu obecnou chybu. Který z těchto případů máte, rozhoduje o tom, kdo to opraví a jaké důkazy potřebujete.

Nejprve shromážděte číslo sestavení a časové razítko instalace. Obě věci promění složku protokolů v hledání, které skutečně můžete spustit.

Tři fáze, tři různé protokoly

První fází je samotný instalátor, který rozbalí soubory, vede si vlastní protokol a hlásí souhrnný kód, například 1603, který říká, že transakce selhala, ale neříká kde. Druhou je úložiště ovladačů, kde se podepsaný balíček připravuje pro pozdější použití, což je jiný úspěch než jeho svázání s hardwarem. Třetí je vytvoření zařízení, kde Windows sestaví instanci zařízení, použije INF a výsledek zapíše do protokolu setupapi. Tichá mezera mezi kterýmikoli dvěma z těchto fází vede ke stejné větě pro uživatele.

Souhrnný kód patří transakci, zatímco selhávající akce je někde dříve ve stejném protokolu. Hledejte zpětně od kódu, místo abyste se snažili kód vysvětlit.

Přečtěte si setupapi.dev.log kolem pokusu

Každá instalace zařízení zapíše oddíl do C:\Windows\INF\setupapi.dev.log a průvodce protokolem SetupAPI vysvětluje, jak jsou tyto oddíly a jejich konečný stav uspořádány. Najděte oddíl, jehož časové razítko obklopuje váš pokus, a přečtěte si ho celý, ne jen první řádek chyby, kterého si všimnete. Upozornění na nesouvisející zařízení se objevují v celém dlouhém protokolu a nic o této závadě nevysvětlují. Konečný stav odpovídajícího oddílu je fakt, který stojí za to citovat ve zprávě.

Spojte tento oddíl s názvem adaptéru, identifikátorem zařízení a balíčkem INF uvedeným v protokolu instalátoru. Tři identifikátory shodující se v jednom časovém razítku jsou to, co činí přiřazení bezpečným.

Zkontrolujte balíček a zařízení odděleně

Připravený balíček dokazuje jen to, že podepsaný INF dorazil do úložiště ovladačů. V této generaci Windows pnputil /enum-drivers vypisuje balíčky třetích stran podle poskytovatele, třídy, verze a publikovaného názvu, což vám umožní najít balíček adaptéru OpenVPN místo hádání z čísla oem. Nic v tomto seznamu neříká, že zařízení existuje, bylo spuštěno nebo je svázáno s balíčkem, který jste našli. To jsou oddělené otázky s oddělenými odpověďmi.

Strana zařízení má vlastní pohled. Inventář adaptérů určený jen pro čtení ukazuje, co si Windows aktuálně myslí o rozhraní, a skryté položky pokrývají zařízení, která existují, ale jsou neaktivní. Porovnání obou seznamů vám řekne, která fáze selhala: balíček chybí, zařízení chybí, nebo zařízení existuje se stavem problému.

Ověřte adaptér, než se dotknete podpisů

Čtěte stav ze stroje, ne ze souhrnu instalátoru. Níže uvedené příkazy vypisují připravené balíčky ovladačů, inventář adaptérů včetně skrytých položek a síťová zařízení, která nehlásí OK. Spusťte je po restartu, aby se čekající operace se zařízeními uklidnily.

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

Přítomný balíček bez odpovídajícího zařízení ukazuje na vytvoření zařízení a oddíl setupapi pro toto časové razítko vysvětluje proč. Přítomné zařízení se stavem problému ukazuje na ovladač nebo jeho podpis, což je jiná konverzace než chybějící zařízení. Adaptér, který existuje a hlásí odpojení, je funkční zařízení bez aktivního tunelu, nikoli neúspěšná instalace. Přečtěte si všechny tři výstupy společně, než vyberete fázi k opravě.

Vypnutí vynucení podpisů, reset síťového zásobníku nebo smazání všech adaptérů způsobí, že důkazy zmizí. Žádná z těchto tří neopraví fázi, kterou jste ještě neidentifikovali, a každá odstraní to, co by vám řeklo, která fáze to byla.