Не ўдалося ўсталяваць адаптар OpenVPN TAP: на якім этапе збой?

Усталёўнік паведамляе, што адаптар TAP не ўдалося стварыць, і гэты сказ ахоплівае як мінімум тры розныя няспраўнасці. Пакет мог ніколі не быць падгатаваны, мог быць падгатаваны без стварэння прылады, або прылада можа існаваць са статусам праблемы, які ўсталёўнік паказаў як адну агульную памылку. Які з гэтых выпадкаў у вас, вызначае, хто будзе выпраўляць і якія доказы патрэбны.

Сабярыце нумар зборкі і адзнаку часу ўсталявання перш за ўсё. Абодва ператвараюць папку журналаў у пошук, які вы сапраўды можаце выканаць.

Тры этапы, тры розныя журналы

Першы этап — гэта сам усталёўнік, які распакоўвае файлы, вядзе ўласны журнал і паведамляе зводны код, напрыклад 1603, які кажа, што транзакцыя не ўдалася, але не кажа дзе. Другі — сховішча драйвераў, дзе падпісаны пакет падгатоўваецца для далейшага выкарыстання, што з'яўляецца іншым дасягненнем, чым прывязка да абсталявання. Трэці — стварэнне прылады, дзе Windows будуе асобнік прылады, ужывае INF і запісвае вынік у журнал setupapi. Ціхая прага паміж любымі двума з гэтых этапаў дае той жа сказ для карыстальніка.

Зводны код належыць транзакцыі, а збойнае дзеянне знаходзіцца раней у тым жа журнале. Шукайце ў зваротным кірунку ад кода, замест таго каб спрабаваць патлумачыць код.

Прачытайце setupapi.dev.log вакол спробы

Кожнае ўсталяванне прылады запісвае раздзел у C:\Windows\INF\setupapi.dev.log, а кіраўніцтва па журнале SetupAPI тлумачыць, як арганізаваны гэтыя раздзелы і іх канчатковы статус. Знайдзіце раздзел, чыя адзнака часу ахоплівае вашу спробу, потым прачытайце яго цалкам, а не толькі першы заўважаны радок памылкі. Папярэджанні пра староннія прылады сустракаюцца па ўсім доўгім журнале і нічога не тлумачаць пра гэты збой. Канчатковы статус адпаведнага раздзела — гэта факт, які варта цытаваць у справаздачы.

Суаднясіце гэты раздзел з імем адаптара, ідэнтыфікатарам прылады і пакетам INF, названым у журнале ўсталёўніка. Тры ідэнтыфікатары, што супадаюць на адной адзнацы часу, робяць атрыбуцыю надзейнай.

Праверце пакет і прыладу асобна

Падгатаваны пакет даказвае толькі тое, што падпісаны INF дабраўся да сховішча драйвераў. У гэтым пакаленні Windows pnputil /enum-drivers пералічвае староннія пакеты па пастаўшчыку, класе, версіі і апублікаванай назве, што дазваляе знайсці пакет адаптара OpenVPN замест здагадак па нумары oem. Нішто ў гэтым спісе не кажа, што прылада існуе, запушчана ці прывязана да знойдзенага пакета. Гэта асобныя пытанні з асобнымі адказамі.

Бок прылады мае свой погляд. Інвентарызацыя адаптараў толькі для чытання паказвае, што Windows цяпер думае пра інтэрфейс, а схаваныя запісы ахопліваюць прылады, якія ёсць, але неактыўныя. Параўнанне двух спісаў скажа, які этап зведаў збой: пакет адсутнічае, прылада адсутнічае або прылада ёсць са статусам праблемы.

Праверце адаптар, перш чым чапаць подпісы

Чытайце стан з машыны, а не са зводкі ўсталёўніка. Каманды ніжэй пералічваюць падгатаваныя пакеты драйвераў, інвентарызацыю адаптараў разам са схаванымі запісамі і сеткавыя прылады, якія не паведамляюць OK. Запусціце іх пасля перазагрузкі, каб чаканыя аперацыі з прыладамі завяршыліся.

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

Прысутнасць пакета без адпаведнай прылады паказвае на стварэнне прылады, і раздзел setupapi для гэтай адзнакі часу тлумачыць чаму. Прылада са статусам праблемы паказвае на драйвер ці яго подпіс, што з'яўляецца іншай размовай, чым адсутная прылада. Адаптар, які існуе і паведамляе пра стан адключэння, гэта працаздольная прылада без актыўнага тунэля, а не няўдалае ўсталяванне. Прачытайце тры вынікі разам, перш чым выбіраць этап для выпраўлення.

Адключэнне праверкі подпісаў, скід сеткавага стэка або выдаленне ўсіх адаптараў прымушае доказы знікнуць. Ніводнае з гэтых трох не выпраўляе этап, які вы яшчэ не вызначылі, і кожнае выдаляе тое, што сказала б вам, які гэта быў этап.