Varning för WAN Miniport: reparera adaptern eller bygg om profilen

Att frysa innan någon inloggning ens erbjuds, att vägra radera profilen, att visa en adapter som ingen känner igen namnet på: det är tre ansikten av samma fel. Programgränssnittet som VPN:en binder till har gått sönder, medan kontot och gatewayen är orörda. Tre reparationer är försvarbara, och vilken som gäller följer av en enda läskontroll. Allt efter den kontrollen är aritmetik; allt före den är gissning.

Vad profilen egentligen binder till

Varje inbyggd Windows-tunneltyp hanteras av sin egen virtuella adapter, och dessa adaptrar är miniport-drivrutiner och inte fysiska kort. En profil väljer en tunneltyp, typen väljer en adapter, och därför kan en enda osund drivrutin förstöra varje profil som delar den, medan fildelning och surfande fortsätter. Beroendet är osynligt i profilegenskaperna.

Dessa gränssnitt är dolda som standard, både i Enhetshanteraren och i adapterlistan. Så förblir en trasig osynlig medan maskinens ägare insisterar på att ingenting har ändrats.

En varningsmarkering är ett användbart bevis och en ren ikon är det inte. En adapter kan rapportera sig som frisk och ändå bära en bruten bindning, så den användbara frågan är vad gränssnittet är kopplat till, inte hur ikonen ser ut. Läs statusen först och bindningarna sedan, eftersom ikonen svarar på den minst intressanta frågan. Att hoppa över den ordningen är det som gör en tio minuters kontroll till en hel eftermiddag av drivrutinsarbete.

Bestäm utifrån adapterns status, inte felkoden

Ett felnummer rapporterar vilket steg som misslyckades och säger ingenting om vilken komponent som är skyldig. Adressfördelning, certifikatval och tunnelprotokollet har sina egna nummer, vanligen 720, 789 och 806, och ingen av de tre är bevis om en miniport. Använd numret för att välja nästa kontroll, inte för att välja en reparation.

De observationer som skiljer sig åt är få. Den här tabellen kopplar var och en till ett nästa steg som bara är läsning:

Ordningen spelar roll eftersom en ominstallation av drivrutinen är långsam och störande. Att göra den för att åtgärda ett adressfördelningsproblem kostar en timme och lär nästa person ingenting. Tabellen avgör också skadans radie: ett protokoll trasigt i alla profiler pekar på drivrutinen, medan en trasig leverantörsklient bredvid fungerande inbyggda profiler pekar på leverantörens stack.

Två läsningar som avgör de flesta ärenden

Båda läsningarna är enbart läsning och ingen av dem rör en drivrutin. Den första listar de dolda miniport-gränssnitten med deras status, den andra listar vad en namngiven adapter är bunden till:

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

Byt ut protokollet som din profil använder, eftersom en bindningslista för IKEv2 inte säger något om en SSTP profil. En inaktiverad ARP- eller IPv4-bindning, eller en tredjeparts filterdrivrutin fäst vid adaptern, kan stoppa tunneln innan den börjar. Att säkerhetsprogramvara dyker upp i den listan är inte bevis för att den är orsaken, så fastställ effekten innan du inaktiverar något.

En frisk adapter visar de bindningar du förväntar dig och inget filter du inte kan förklara. När listan är ren har beviset flyttat till själva drivrutinen och nästa avsnitt är det som gäller.

Spara adapterns namn och drivrutinens version innan du tar bort den

När adaptern verkligen är oanvändbar är standardreparationen att göra den borttagbar, avinstallera den och låta Windows bygga en färsk instans nästa gång en profil använder det protokollet. I Enhetshanteraren uppdaterar du drivrutinen, väljer från en lista, rensar filtret för kompatibel hårdvara och väljer en generisk Microsoft-adapter som erbjuder ett avinstallationsalternativ.

Innan dess, notera vad du raderar: adapterns namn, drivrutinens version, leverantör och datum. En reparation du inte kan beskriva efteråt kan inte upprepas, och det vanliga priset för en obeskriven reparation är samma maskin reparerad tre gånger. Leverantörsverktyg gör samma arbete med bredare räckvidd och är rimliga i en hanterad flotta när de kommer från leverantören och inte från en spegel. Ett verktyg som byter ut drivrutinsbinärer ändrar mer än att installera om en enda adapter, så notera även dess version i ärendet.

Ett leverantörsärende kräver en annan reparation för samma symptom. En klient som registrerar sin adapter under ett visningsnamn med en installationsreferens kan misslyckas med att aktivera efter en uppgradering, och korrigeringen redigerar det namnet i en tjänstnyckel som leverantören äger. Värdet tar ett vanligt adapternamn, och klienten startas om efteråt:

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

Den nyckeln tillhör en enda klient. Det är inte en allmän Windows-reparation och den bör aldrig tillämpas på en maskin som inte kör den klienten.

Bekräfta med ett andra protokoll innan du stänger ärendet

En lyckad återanslutning prövar ett protokoll genom en adapter, så den bevisar mindre än det verkar. Försök igen med den ursprungliga profilen och sedan med en andra byggd på en annan tunneltyp, och kräv att båda ansluter. Om bara den första fungerar är det återstående felet bevis om en drivrutin eller en princip snarare än om gränssnittet du just byggde om.

Om det ursprungliga klagomålet var en profil som inte kunde raderas, testa det också igen, för en profil som fortfarande vägrar raderas efter att adaptern är frisk är ett annat fel och ytterligare adapterarbete är bortkastat. Håll kontot och gatewayen utanför anteckningen om inte något pekar på dem. En tunnel som dör före autentiseringen beskriver oftast maskinen, och en ärlig anteckning namnger adaptern, protokollet och den kontroll som bekräftade det.