Адаптер 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 для этой отметки времени объясняет почему. Устройство с проблемным состоянием указывает на драйвер или его подпись, и это другой разговор, нежели отсутствующее устройство. Адаптер, который существует и сообщает об отключении, — это работающее устройство без активного туннеля, а не неудачная установка. Прочитайте все три вывода вместе, прежде чем выбирать этап для починки.
Отключение проверки подписей, сброс сетевого стека или удаление всех адаптеров заставляют доказательства исчезнуть. Ни одно из этих трёх действий не исправляет этап, который вы ещё не определили, и каждое убирает то, что сказало бы вам, какой это был этап.