Installationsprogrammet säger att TAP-adaptern inte kunde skapas, och den meningen täcker minst tre olika fel. Paketet kan aldrig ha förberetts, det kan vara förberett utan att någon enhet skapades, eller så kan enheten finnas med en problemstatus som installationsprogrammet rapporterade som ett enda generiskt fel. Vilket av dessa fall du har avgör vem som åtgärdar det och vilka bevis du behöver.

Samla in build-numret och tidsstämpeln för installationen före allt annat. Båda förvandlar en mapp med loggar till en sökning du faktiskt kan köra.

Tre steg, tre olika loggar

Det första steget är installationsprogrammet självt, som packar upp filer, för sin egen logg och rapporterar en sammanfattningskod som 1603 vilken säger att transaktionen misslyckades utan att säga var. Det andra är drivrutinslagret, där ett signerat paket förbereds för senare användning, vilket är en annan bedrift än att binda det till hårdvara. Det tredje är skapandet av enheten, där Windows bygger en enhetsinstans, tillämpar INF-filen och registrerar resultatet i setupapi-loggen. En tyst lucka mellan två av dessa steg ger samma mening för användaren.

Sammanfattningskoden tillhör transaktionen, medan den misslyckade åtgärden finns någonstans tidigare i samma logg. Sök bakåt från koden i stället för att försöka förklara koden.

Läs setupapi.dev.log kring försöket

Varje enhetsinstallation skriver ett avsnitt till C:\Windows\INF\setupapi.dev.log, och guiden för SetupAPI-loggen förklarar hur dessa avsnitt och deras slutstatus är ordnade. Hitta avsnittet vars tidsstämpel omsluter ditt försök och läs hela avsnittet i stället för den första felrad du lägger märke till. Varningar om orelaterade enheter förekommer överallt i en lång logg och förklarar ingenting om detta fel. Slutstatusen för det matchande avsnittet är det faktum som är värt att citera i en rapport.

Koppla avsnittet till adapterns namn, enhetsidentifieraren och det INF-paket som nämns i installationsloggen. Tre identifierare som stämmer på en enda tidsstämpel är det som gör tillskrivningen säker.

Kontrollera paketet och enheten var för sig

Ett förberett paket bevisar bara att en signerad INF nådde drivrutinslagret. I den här Windows-generationen listar pnputil /enum-drivers tredjepartspaket efter leverantör, klass, version och publicerat namn, vilket låter dig hitta OpenVPN-adapterns paket i stället för att gissa utifrån ett oem-nummer. Ingenting i den listan säger att en enhet finns, har startat eller är bunden till paketet du hittade. Det är separata frågor med separata svar.

Enhetssidan har sin egen bild. En skrivskyddad adapterinventering visar vad Windows för närvarande tror om gränssnittet, och dolda poster omfattar enheter som finns men är inaktiva. Att jämföra de två listorna berättar vilket steg som misslyckades: paketet saknas, enheten saknas eller enheten finns med en problemstatus.

Verifiera adaptern innan du rör signaturerna

Läs statusen från datorn i stället för från installationsprogrammets sammanfattning. Kommandona nedan listar förberedda drivrutinspaket, adapterinventeringen inklusive dolda poster och de nätverksenheter som inte rapporterar OK. Kör dem efter en omstart så att väntande enhetsåtgärder har hunnit lugna sig.

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

Ett paket som finns utan motsvarande enhet pekar på skapandet av enheten, och setupapi-avsnittet för den tidsstämpeln förklarar varför. En enhet som finns med en problemstatus pekar på drivrutinen eller dess signatur, vilket är ett annat samtal än en saknad enhet. En adapter som finns och rapporterar frånkopplad är en fungerande enhet utan aktiv tunnel, inte en misslyckad installation. Läs de tre utdatana tillsammans innan du väljer ett steg att reparera.

Att stänga av signaturtvingande, återställa nätverksstacken eller ta bort alla adaptrar får bevisen att försvinna. Ingen av de tre åtgärdar ett steg du ännu inte har identifierat, och var och en tar bort det som skulle ha talat om vilket steg det var.

Relaterade artiklar