Advarsel om WAN Miniport: reparér adapteren eller genopbyg profilen

At fryse, før der overhovedet tilbydes en adgangskode, at nægte at slette profilen, at vise en adapter, hvis navn ingen genkender: det er tre ansigter af samme fejl. Det softwareinterface, som VPN’en binder til, er blevet dårligt, mens kontoen og gatewayen er urørte. Tre reparationer er forsvarlige, og hvilken der gælder, følger af én læse-kun undersøgelse. Alt efter den undersøgelse er regnearbejde; alt før den er gætværk.

Hvad profilen egentlig binder til

Hver indbygget Windows-tunneltype betjenes af sin egen virtuelle adapter, og disse adaptere er miniport-drivere og ikke fysiske kort. En profil vælger en tunneltype, typen vælger en adapter, og én usund driver kan derfor ødelægge hver profil, der deler den, mens fildeling og browsing fortsætter. Afhængigheden er usynlig i profilegenskaberne.

Disse grænseflader er skjult som standard, både i Enhedshåndtering og på listen over adaptere. Det er sådan en ødelagt en forbliver usynlig, mens ejeren af maskinen insisterer på, at intet er ændret.

Et advarselsmærke er nyttigt bevis, og et rent ikon er det ikke. En adapter kan rapportere sig som sund og stadig bære en brudt binding, så det nyttige spørgsmål er, hvad grænsefladen er knyttet til, snarere end hvordan ikonet ser ud. Læs status først og bindingerne derefter, fordi ikonet besvarer det mindst interessante spørgsmål. At springe den rækkefølge over er det, der gør en tikminutters kontrol til en hel eftermiddag med driverarbejde.

Beslut ud fra adapterens tilstand, ikke fejlkoden

Et fejlnummer rapporterer, hvilket trin der fejlede, og siger intet om, hvilken komponent der er skyld i det. Tildeling af adresser, valg af certifikat og tunnelprotokollen har deres egne numre, konventionelt 720, 789 og 806, og ingen af de tre er bevis om en miniport. Brug nummeret til at vælge den næste kontrol, ikke til at vælge en reparation.

De observationer, der skelner, er få. Denne tabel knytter hver af dem til et læse-kun næste skridt:

Rækkefølgen er vigtig, fordi en driver-geninstallation er langsom og forstyrrende. At lave en for at rette et tildelingsproblem koster en time og lærer den næste person intet. Tabellen afgør også skadesradius: én protokol brudt på alle profiler peger på driveren, mens én brudt leverandørklient ved siden af fungerende indbyggede profiler peger på leverandørens stak.

To læsninger, der afgør de fleste sager

Begge læsninger er læse-kun, og ingen af dem rører en driver. Den første viser de skjulte miniport-grænseflader med deres status, og den anden viser, hvad en navngivet adapter er bundet til:

Get-NetAdapter -IncludeHidden | Where-Object InterfaceDescription -like 'WAN Miniport*' | Select-Object Name, InterfaceDescription, Status
Get-NetAdapterBinding -Name 'WAN Miniport (IKEv2)' -IncludeHidden -AllBindings

Erstat den protokol, din profil bruger, for en bindingsliste for IKEv2 siger intet om en SSTP profil. En deaktiveret ARP- eller IPv4-binding eller en tredjeparts filterdriver, der er knyttet til adapteren, kan stoppe tunnelen, før den begynder. At sikkerhedssoftware optræder på den liste er ikke bevis for, at den er årsagen, så fastslå effekten, før du deaktiverer noget.

En sund adapter viser de bindinger, du forventer, og ingen filter, du ikke kan forklare. Når listen er ren, er beviset flyttet til driveren selv, og det næste afsnit er det, der gælder.

Gem adapterens navn og driverversion, før du fjerner den

Når adapteren virkelig er ubrugelig, er den standardreparation at gøre den fjernbar, afinstallere den og lade Windows bygge en frisk instans, næste gang en profil bruger den protokol. I Enhedshåndtering opdaterer du driveren, vælger fra en liste, rydder filteret for kompatibel hardware og vælger en generisk Microsoft-adapter, der tilbyder en afinstallationsmulighed.

Før det skal du notere, hvad du sletter: adapternavn, driverversion, udbyder og dato. En reparation, du ikke kan beskrive bagefter, kan ikke gentages, og den sædvanlige pris for en ubeskrevet reparation er den samme maskine repareret tre gange. Leverandørværktøjer gør samme arbejde med bredere rækkevidde og er rimelige på en administreret flåde, når de kommer fra leverandøren og ikke fra et spejl. Et værktøj, der udskifter driverbinære filer, ændrer mere end at geninstallere en enkelt adapter, så noter også dets version i sagen.

Ét leverandørtilfælde kræver en anden reparation for samme symptom. En klient, der registrerer sin adapter under et visningsnavn med en installationsreference, kan undlade at aktivere efter en opgradering, og rettelsen redigerer det navn i en tjenestenøgle, som leverandøren ejer. Værdien tager et almindeligt adapternavn, og klienten genstartes bagefter:

HKLM\SYSTEM\CurrentControlSet\Services\CVirtA
DisplayName = Cisco Systems VPN Adapter for 64-bit Windows

Den nøgle tilhører én klient. Det er ikke en generel Windows-reparation, og den bør aldrig anvendes på en maskine, der ikke kører den klient.

Bekræft med en anden protokol, før du lukker sagen

En vellykket genopkobling afprøver én protokol gennem én adapter, så den beviser mindre, end det ser ud til. Prøv den oprindelige profil igen og derefter en anden bygget på en anden tunneltype, og kræv, at begge forbinder. Hvis kun den første virker, er den resterende fejl bevis om en driver eller en politik snarere end om den grænseflade, du netop har genopbygget.

Hvis den oprindelige klage var en profil, der ikke kunne slettes, skal du også teste det igen, for en profil, der stadig nægter at blive slettet, efter adapteren er sund, er en anden fejl, og yderligere adapterarbejde er spildt. Hold kontoen og gatewayen ude af notatet, medmindre noget peger på dem. En tunnel, der dør før godkendelse, beskriver normalt maskinen, og et ærligt notat nævner adapteren, protokollen og den kontrol, der bekræftede det.