Installationsprogrammet siger, at TAP-adapteren ikke kunne oprettes, og den sætning dækker mindst tre forskellige fejl. Pakken er måske aldrig blevet klargjort, den kan være klargjort uden at der blev oprettet en enhed, eller enheden kan findes med en problemstatus, som installationsprogrammet rapporterede som én generisk fejl. Hvilken af dem du har, afgør, hvem der retter det, og hvilke beviser du har brug for.

Indsaml buildnummeret og installationstidsstemplet før alt andet. Begge gør en mappe med logs til en søgning, du faktisk kan køre.

Tre trin, tre forskellige logs

Det første trin er selve installationsprogrammet, som pakker filer ud, fører sin egen log og rapporterer en samlekode som 1603, der siger, at transaktionen fejlede uden at sige hvor. Det andet er driverlageret, hvor en signeret pakke klargøres til senere brug, hvilket er en anden bedrift end at binde den til hardware. Det tredje er oprettelse af enheden, hvor Windows bygger en enhedsinstans, anvender INF og registrerer resultatet i setupapi-loggen. Et stille hul mellem to vilkårlige af disse trin giver den samme sætning til brugeren.

Samlekoden hører til transaktionen, mens den fejlende handling ligger tidligere i samme log. Søg baglæns fra koden i stedet for at prøve at forklare koden.

Læs setupapi.dev.log omkring forsøget

Hver enhedsinstallation skriver et afsnit i C:\Windows\INF\setupapi.dev.log, og SetupAPI-logvejledningen forklarer, hvordan disse afsnit og deres endelige status er organiseret. Find det afsnit, hvis tidsstempel rammer dit forsøg, og læs det hele i stedet for den første fejllinje, du bemærker. Advarsler om urelaterede enheder optræder gennem en lang log og forklarer intet om denne fejl. Den endelige status for det matchende afsnit er det faktum, der er værd at citere i en rapport.

Korrelér det afsnit med adapternavnet, enhedsidentifikatoren og INF-pakken, der er nævnt i installationsloggen. Tre identifikatorer, der stemmer overens på ét tidsstempel, er det, der gør tilskrivningen sikker.

Kontrollér pakken og enheden hver for sig

En klargjort pakke beviser kun, at en signeret INF nåede driverlageret. I denne Windows-generation viser pnputil /enum-drivers tredjepartspakker efter udbyder, klasse, version og offentliggjort navn, hvilket lader dig finde OpenVPN-adapterpakken i stedet for at gætte ud fra et oem-nummer. Intet på den liste siger, at en enhed findes, er startet eller er bundet til den pakke, du fandt. Det er separate spørgsmål med separate svar.

Enhedssiden har sit eget syn. Et skrivebeskyttet adapterinventar viser, hvad Windows i øjeblikket tror om grænsefladen, og skjulte poster dækker enheder, der er til stede, men inaktive. Ved at sammenligne de to lister kan du se, hvilket trin der fejlede: pakke mangler, enhed mangler, eller enhed til stede med en problemstatus.

Bekræft adapteren, før du rører signaturer

Læs tilstanden fra maskinen i stedet for fra installationsprogrammets resumé. Kommandoerne nedenfor viser klargjorte driverpakker, adapterinventaret inklusive skjulte poster og de netværksenheder, der ikke rapporterer OK. Kør dem efter en genstart, så ventende enhedsoperationer er faldet til ro.

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

En pakke til stede uden en matchende enhed peger på oprettelse af enheden, og setupapi-afsnittet for det tidsstempel forklarer hvorfor. En enhed til stede med en problemstatus peger på driveren eller dens signatur, hvilket er en anden samtale end en manglende enhed. En adapter, der findes og rapporterer at være afbrudt, er en fungerende enhed uden en aktiv tunnel snarere end en mislykket installation. Læs de tre output sammen, før du vælger et trin at reparere.

Deaktivering af signaturhåndhævelse, nulstilling af netværksstakken eller sletning af alle adaptere får beviserne til at forsvinde. Ingen af de tre reparerer et trin, du endnu ikke har identificeret, og hver af dem fjerner det, der ville have fortalt dig, hvilket trin det var.

Relaterede artikler