OpenVPN TAP-adaptilo malsukcesis instaliĝi: kiu etapo rompiĝis?

La instalilo diras, ke la TAP-adaptilo ne povis esti kreita, kaj tiu frazo kovras almenaŭ tri malsamajn paneojn. La pako eble neniam estis preparita, ĝi eble estis preparita sen krei aparaton, aŭ la aparato eble ekzistas kun problema stato, kiun la instalilo raportis kiel unu ĝeneralan eraron. Kiu el tiuj vi havas, decidas kiu riparos ĝin kaj kiajn pruvojn vi bezonas.

Antaŭ ĉio alia kolektu la konstru-numeron kaj la instaladan tempostampon. Ambaŭ transformas dosierujon da protokoloj en serĉon, kiun vi povas efektive plenumi.

Tri etapoj, tri malsamaj protokoloj

La unua etapo estas la instalilo mem, kiu malpakas dosierojn, tenas sian propran protokolon kaj raportas resuman kodon kiel 1603, kiu diras, ke la transakcio malsukcesis, sed ne diras kie. La dua estas la pelila stokejo, kie subskribita pako prepariĝas por posta uzo, kio estas alia atingaĵo ol ligi ĝin al aparataro. La tria estas kreado de aparato, kie Windows konstruas aparatan kazon, aplikas la INF kaj registras la rezulton en la setupapi-protokolo. Silenta breĉo inter ajnaj du el tiuj etapoj produktas la saman frazon por la uzanto.

La resuma kodo apartenas al la transakcio, dum la malsukcesa ago troviĝas ie pli frue en la sama protokolo. Serĉu malantaŭen de la kodo anstataŭ provi klarigi la kodon.

Legu setupapi.dev.log ĉirkaŭ la provo

Ĉiu aparata instalado skribas sekcion al C:\Windows\INF\setupapi.dev.log, kaj la gvidilo pri la SetupAPI-protokolo klarigas, kiel tiuj sekcioj kaj ilia fina stato estas organizitaj. Trovu la sekcion, kies tempostampo ĉirkaŭas vian provon, poste legu ĝin tutan anstataŭ la unuan erarlinion, kiun vi rimarkas. Avertoj pri nerilataj aparatoj aperas tra longa protokolo kaj klarigas nenion pri ĉi tiu paneo. La fina stato de la kongrua sekcio estas la fakto inda citaĵi en raporto.

Kunrilatigu tiun sekcion kun la adaptila nomo, la aparata identigilo kaj la INF-pako nomita en la instalila protokolo. Tri identigiloj kongruantaj ĉe unu tempostampo estas tio, kio faras la atribuon sekura.

Kontrolu la pakon kaj la aparaton aparte

Preparita pako pruvas nur, ke subskribita INF atingis la pelilan stokejon. En ĉi tiu Windows-generacio, pnputil /enum-drivers listigas triapartajn pakojn laŭ provizanto, klaso, versio kaj publikigita nomo, kio ebligas al vi trovi la pakon de la OpenVPN-adaptilo anstataŭ diveni el oem-numero. Nenio en tiu listo diras, ke aparato ekzistas, ekfunkciis aŭ estas ligita al la pako, kiun vi trovis. Tiuj estas apartaj demandoj kun apartaj respondoj.

La aparata flanko havas sian propran vidon. Nurlega adaptila inventaro montras, kion Windows nun opinias pri la interfaco, kaj kaŝitaj enskriboj kovras aparatojn, kiuj ĉeestas sed estas neaktivaj. Kompari la du listojn diras al vi, kiu etapo malsukcesis: pako mankas, aparato mankas, aŭ aparato ĉeestas kun problema stato.

Kontrolu la adaptilon antaŭ ol tuŝi subskribojn

Legu la staton de la maŝino anstataŭ de la resumo de la instalilo. La subaj komandoj listigas preparitajn pelilajn pakojn, la adaptilan inventaron inkluzive de kaŝitaj enskriboj, kaj la retaparatojn, kiuj ne raportas OK. Rulu ilin post restarto, por ke pendantaj aparataj operacioj trankviliĝu.

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

Pako ĉeesta sen kongrua aparato indikas kreadon de aparato, kaj la setupapi-sekcio por tiu tempostampo klarigas kial. Aparato ĉeesta kun problema stato indikas la pelilon aŭ ĝian subskribon, kio estas alia konversacio ol mankanta aparato. Adaptilo, kiu ekzistas kaj raportas esti malkonektita estas funkcianta aparato sen aktiva tunelo, ne malsukcesa instalado. Legu la tri eligojn kune antaŭ ol elekti etapon por ripari.

Malŝalti subskriban devigon, restarigi la retan stakon aŭ forigi ĉiun adaptilon igas la pruvojn malaperi. Neniu el tiuj tri riparas etapon, kiun vi ankoraŭ ne identigis, kaj ĉiu forigas tion, kio dirus al vi, kiu etapo ĝi estis.