Адаптер TAP OpenVPN не встановився: який етап зламався?

Інсталятор повідомляє, що адаптер 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 для цієї позначки часу пояснює чому. Пристрій із проблемним станом указує на драйвер або його підпис, і це інша розмова, ніж відсутній пристрій. Адаптер, який існує й повідомляє про від'єднання, — це робочий пристрій без активного тунелю, а не невдале встановлення. Прочитайте всі три виводи разом, перш ніж обирати етап для виправлення.

Вимкнення перевірки підписів, скидання мережевого стека або видалення всіх адаптерів змушують докази зникнути. Жодна з цих трьох дій не виправляє етап, який ви ще не визначили, і кожна прибирає те, що сказало б вам, який це був етап.