27850, 442 og 651: éin stabel, tre første kontrollar

Installasjonsprogrammet stoppar med 27850, ei tilkopling blir avvist med 442, og ein annan profil returnerer 651. Tala ser ut som tre uavhengige feil, og den vanlege responsen er å installere klienten på nytt tre gonger. Men dei kjem frå eitt delsystem: den virtuelle adapteren og filterstabelen rundt han. Feilnummeret fortel kva lag som svikta, og det avgjer den første kontrollen. Ny installasjon før du har lese nummeret gjer oftast same feilen om att.

Kople nummeret til laget

Kvar feil oppstår på ein annan stad, så den første kontrollen er ulik sjølv når det synlege symptomet er den same avviste tilkoplinga. Tre familiar dekkjer kvart tilfelle: installasjonsprogrammet, adapteren og porten under han. Tabellen nedanfor set kvart nummer ved sida av kontrollen det krev.

Viser feilen seg før nokon profil er vald, høyrer han til installasjonsfamilien. Viser han seg når klienten prøver å reise adapteren, høyrer han til adapterfamilien. Er adapteren synleg og porten aldri blir opna, er det miniportfamilien. Skriv ned nummeret før du endrar noko. Dei tre reparasjonane rører ulike delar av stabelen, og ei endring for feil familie gjer neste forsøk vanskelegare å lese.

Ein full filterstabel, eller ein tryggleikspakke som blokkerer drivaren

Installasjon av klienten registrerer ein liten filterkomponent i adapterkjeda. Windows har eit hardt tak for kor mange slike komponentar som kan bindast, og standardverdien lèt lite plass att når antivirus, ei virtualiseringsbru og ein opptaksdrivar er til stades. Då feilar installasjonen med 27850 sjølv om VPN-pakken er i orden. Installasjonsprogrammet kan ikkje skilje ein overfylt stabel frå ein øydelagd.

Les gjeldande verdi, auk han, og start på nytt før du prøver igjen. Eit nytt filter kan ikkje bindast før stabelen er bygd opp att:

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 årsaka er ein tryggleikspakke som blokkerer drivarinstallasjon utan eit synleg varsel. Sjølvforsvaret kan hindre filteret i å registrere seg, og installasjonsprogrammet melder då ein generisk komponentfeil. Sjå i den eigen loggen til pakken, og om sjølvforsvaret er blokkeringa, slå det av berre i installasjonsvindauget og set det straks tilbake etterpå. Er verdien alt auka og ingen pakke blokkerer, sjå etter foreldrelause filterdrivarar frå eit tidlegare VPN-produkt. Eit gamalt filter utan tilhøyrande teneste opptek framleis ein plass og kan få den nye installasjonen til å feile.

Adapteren er der og blir liggjande nede

Feil 442 tyder at den virtuelle adapteren er til stades og at klienten ikkje får reist han. Den første kontrollen er Einingar med skjulte einingar viste: ein deaktivert adapter, ein adapter med åtvaringsteikn og ein manglande adapter ser like ut i klienten, men krev ulike reparasjonar. Internet Connection Sharing held han ofte. Har tenesta teke adapteren, stopp tenesta og prøv igjen før du rører registeret. Ein attverande delingskonfigurasjon kan ta han igjen etter ein omstart, så noter om rettinga overlever omstart.

Ein ny installasjon kan etterlate eit feil forma visingsnamn som gjer adapteren uhantérbar. Verdien skal vere rein tekst, ikkje eit uløyst installasjonsteikn:

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 visingsnamnet klienten din ventar, og start så på nytt slik at adapteren blir talt opp igjen. Å setje verdien utan omstart lèt oftast den gamle tilstanden stå, og neste tilkopling gir 442 igjen.

Porten under blir aldri opna

Feil 651 blir meldt når tilkoplingshandsamaren ikkje får opna WAN-miniporten. Adapteren kan sjå sunn ut i klienten medan porten under han aldri når ein starta tilstand. List miniportane og statusen deira før du installer noko på nytt:

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

Ein miniport med feilstatus er det direkte sporet. Ny installasjon frå Einingar opnar porten på nytt, og difor verkar denne reparasjonen når ein klientnyinstallasjon ikkje gjer det. Tredjepartsdrivarar bundne til den fysiske adapteren er den andre vanlege årsaka. Ein VirtualBox-brunettverksdrivar, ein attverande TAP-drivar frå OpenVPN eller eit opptaksfilter kan ta porten først. Å fjerne avkryssinga av komponenten under ein installasjon er ikkje nok når drivaren alt er bunden; han må fjernast frå eigenskapane til adapteren eller avinstallerast frå drivarlageret.

Å slå av IPv6 på VPN-tilkoplinga har løyst denne feilen på nokre bygg, men handsam det som ein test og ikkje som ei varig løysing. Om tilkoplinga berre startar med IPv6 avslått, er den underliggjande miniporten eller drivaren framleis årsaka.

Endre eitt lag og ta vare på prova

Lagra registerverdiane du endrar, noter adapter- og filterlista før og etter, og start på nytt mellom forsøka. Ein omstart er ein del av reparasjonen for kvar familie her, fordi adapterstabelen blir bygd ved oppstart og ein tenesteomstart ikkje byggjer han opp att.

Installer klienten på nytt først når den gamle adapteren, filtera og miniportane er borte. Å installere ein ny klient oppå ein øydelagd stabel er måten ein reparerbar 27850 blir til ei maskin med to halvregistrerte adapterar og inga klår feil. Stopp og eskaler når same feilen overlever den lagspesifikke kontrollen to gonger. På det punktet er det nyttige neste steget ein rein gjennomgang av nettverksstabelen med installasjonsloggen til leverandøren, ikkje eit nytt forsøk med den same nyinstallasjonen.