27850, 442 og 651: én stabel, tre første sjekker

Installasjonsprogrammet stopper på 27850, en tilkobling avvises med 442, og en annen profil returnerer 651. Numrene ser ut som tre uavhengige feil, og den vanlige reaksjonen er å installere klienten på nytt tre ganger. Men de kommer fra ett delsystem: den virtuelle adapteren og filterstabelen rundt den. Feilnummeret sier hvilket lag som sviktet, og det avgjør den første sjekken. Ny installasjon før du har lest nummeret gjenskaper som regel samme feil.

Koble nummeret til laget

Hver feil oppstår på et annet punkt, så den første sjekken er forskjellig selv når det synlige symptomet er den samme avviste tilkoblingen. Tre familier dekker hvert tilfelle: installasjonsprogrammet, adapteren og porten under den. Tabellen nedenfor setter hvert nummer ved siden av sjekken det krever.

Hvis feilen vises før noen profil er valgt, hører den til installasjonsfamilien. Hvis den vises når klienten prøver å reise adapteren, hører den til adapterfamilien. Hvis adapteren er synlig og porten aldri åpnes, er det miniportfamilien. Noter nummeret før du endrer noe. De tre reparasjonene berører ulike deler av stabelen, og en endring for feil familie gjør neste forsøk vanskeligere å lese.

En full filterstabel, eller en sikkerhetspakke som blokkerer driveren

Installasjon av klienten registrerer en liten filterkomponent i adapterkjeden. Windows har et hardt tak for hvor mange slike komponenter som kan bindes, og standardverdien etterlater lite plass når antivirus, en virtualiseringsbro og en opptaksdriver er til stede. Da feiler installasjonen med 27850 selv om VPN-pakken er i orden. Installasjonsprogrammet kan ikke skille en overfylt stabel fra en ødelagt.

Les gjeldende verdi, øk den, og start på nytt før du prøver igjen. Et nytt filter kan ikke bindes før stabelen er bygget opp igjen:

reg query "HKLM\SYSTEM\CurrentControlSet\Control\Network" /v MaxNumFilters
reg add "HKLM\SYSTEM\CurrentControlSet\Control\Network" /v MaxNumFilters /t REG_DWORD /d 14 /f

Den andre årsaken er en sikkerhetspakke som blokkerer driverinstallasjon uten et synlig varsel. Selvforsvaret kan hindre filteret i å registrere seg, og installasjonsprogrammet melder da en generisk komponentfeil. Se i pakkens egen logg, og hvis selvforsvaret er blokkeringen, slå det av bare i installasjonsvinduet og sett det tilbake med en gang etterpå. Er verdien allerede økt og ingen pakke blokkerer, se etter foreldreløse filterdrivere fra et tidligere VPN-produkt. Et gammelt filter uten tilhørende tjeneste opptar fortsatt en plass og kan få den nye installasjonen til å feile.

Adapteren er der og blir liggende nede

Feil 442 betyr at den virtuelle adapteren er til stede og at klienten ikke får reist den. Den første sjekken er Enhetsbehandling med skjulte enheter vist: en deaktivert adapter, en adapter med advarselstegn og en manglende adapter ser like ut i klienten, men krever forskjellige reparasjoner. Internet Connection Sharing holder den ofte. Hvis tjenesten har tatt adapteren, stopp tjenesten og prøv igjen før du rører registeret. En gjenværende delingskonfigurasjon kan ta den igjen etter en omstart, så noter om rettelsen overlever omstart.

En ny installasjon kan etterlate et feil utformet visningsnavn som gjør adapteren uhåndterlig. Verdien skal være ren tekst, ikke et uløst installasjonstoken:

Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Services\CVirtA" -Name DisplayName
Set-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Services\CVirtA" -Name DisplayName -Value "Cisco Systems VPN Adapter for 64-bit Windows"

Bruk visningsnavnet klienten din forventer, og start deretter på nytt slik at adapteren telles opp igjen. Å sette verdien uten omstart lar som regel den gamle tilstanden stå, og neste tilkobling gir 442 igjen.

Porten under åpnes aldri

Feil 651 rapporteres når tilkoblingsbehandleren ikke får åpnet WAN-miniporten. Adapteren kan se sunn ut i klienten mens porten under den aldri når en startet tilstand. List miniportene og statusen deres før du installerer noe på nytt:

Get-PnpDevice -Class Net | Where-Object { $_.FriendlyName -like "*WAN Miniport*" } | Select-Object Status, FriendlyName

En miniport med feilstatus er det direkte sporet. Ny installasjon fra Enhetsbehandling åpner porten på nytt, og derfor virker denne reparasjonen når en klientnyinstallasjon ikke gjør det. Tredjepartsdrivere bundet til den fysiske adapteren er den andre vanlige årsaken. En VirtualBox-bronettverksdriver, en gjenværende TAP-driver fra OpenVPN eller et opptaksfilter kan ta porten først. Å fjerne avmerkingen av komponenten under en installasjon er ikke nok når driveren allerede er bundet; den må fjernes fra egenskapene til adapteren eller avinstalleres fra driverlageret.

Å slå av IPv6 på VPN-tilkoblingen har løst denne feilen på noen bygg, men behandle det som en test og ikke som en varig løsning. Hvis tilkoblingen bare starter med IPv6 slått av, er den underliggende miniporten eller driveren fortsatt årsaken.

Endre ett lag og ta vare på bevisene

Lagre registerverdiene du endrer, noter adapter- og filterlisten før og etter, og start på nytt mellom forsøkene. En omstart er en del av reparasjonen for hver familie her, fordi adapterstabelen bygges ved oppstart og en tjenesteomstart ikke bygger den opp igjen.

Installer klienten på nytt først når den gamle adapteren, filtrene og miniportene er borte. Å installere en ny klient oppå en ødelagt stabel er måten en reparerbar 27850 blir til en maskin med to halvregistrerte adaptere og ingen klar feil. Stopp og eskaler når samme feil overlever den lagspesifikke sjekken to ganger. På det punktet er det nyttige neste steget en ren gjennomgang av nettverksstabelen med installasjonsloggen til leverandøren, ikke et nytt forsøk med den samme nyinstallasjonen.