El adaptador TAP de OpenVPN no se pudo instalar: ¿qué etapa falló?

El instalador dice que el adaptador TAP no se pudo crear, y esa frase abarca al menos tres fallos distintos. Puede que el paquete nunca se haya preparado, que se haya preparado sin crear ningún dispositivo, o que el dispositivo exista con un estado de problema que el instalador informó como un único error genérico. Cuál de esos casos tenga decide quién lo arregla y qué pruebas necesita.

Recoja el número de compilación y la marca de tiempo de instalación antes que nada. Ambos convierten una carpeta de registros en una búsqueda que realmente puede ejecutar.

Tres etapas, tres registros distintos

La primera etapa es el propio instalador, que descomprime archivos, mantiene su propio registro e informa un código resumen como 1603 que dice que la transacción falló sin decir dónde. La segunda es el almacén de controladores, donde un paquete firmado se prepara para su uso posterior, lo que es un logro distinto de vincularlo al hardware. La tercera es la creación del dispositivo, donde Windows construye una instancia de dispositivo, aplica el INF y registra el resultado en el registro de setupapi. Un hueco silencioso entre dos cualesquiera de esas etapas produce la misma frase para el usuario.

El código resumen pertenece a la transacción, mientras que la acción fallida está en algún punto anterior del mismo registro. Busque hacia atrás desde el código en lugar de intentar explicar el código.

Lea setupapi.dev.log en torno al intento

Cada instalación de dispositivo escribe una sección en C:\Windows\INF\setupapi.dev.log, y la guía del registro de SetupAPI explica cómo se organizan esas secciones y su estado final. Encuentre la sección cuya marca de tiempo envuelve su intento y luego léala entera en lugar de la primera línea de error que note. Los avisos sobre dispositivos no relacionados aparecen a lo largo de un registro largo y no explican nada sobre este fallo. El estado final de la sección coincidente es el dato que merece citarse en un informe.

Correlacione esa sección con el nombre del adaptador, el identificador del dispositivo y el paquete INF nombrado en el registro del instalador. Tres identificadores que coinciden en una misma marca de tiempo es lo que hace segura la atribución.

Compruebe el paquete y el dispositivo por separado

Un paquete preparado solo demuestra que un INF firmado llegó al almacén de controladores. En esta generación de Windows, pnputil /enum-drivers enumera los paquetes de terceros por proveedor, clase, versión y nombre publicado, lo que le permite encontrar el paquete del adaptador OpenVPN en lugar de adivinarlo a partir de un número oem. Nada en esa lista dice que exista un dispositivo, que se haya iniciado o que esté vinculado al paquete que encontró. Son preguntas separadas con respuestas separadas.

El lado del dispositivo tiene su propia visión. Un inventario de adaptadores de solo lectura muestra lo que Windows cree actualmente sobre la interfaz, y las entradas ocultas abarcan dispositivos que están presentes pero inactivos. Comparar las dos listas le dice qué etapa falló: paquete ausente, dispositivo ausente o dispositivo presente con un estado de problema.

Verifique el adaptador antes de tocar las firmas

Lea el estado de la máquina en lugar del resumen del instalador. Los comandos siguientes enumeran los paquetes de controladores preparados, el inventario de adaptadores incluidas las entradas ocultas y los dispositivos de red que no informan OK. Ejecútelos tras un reinicio para que las operaciones pendientes de dispositivos se hayan asentado.

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

Un paquete presente sin dispositivo coincidente apunta a la creación del dispositivo, y la sección de setupapi para esa marca de tiempo explica por qué. Un dispositivo presente con un estado de problema apunta al controlador o a su firma, que es una conversación distinta de un dispositivo ausente. Un adaptador que existe e informa estar desconectado es un dispositivo funcional sin túnel activo, no una instalación fallida. Lea las tres salidas juntas antes de elegir una etapa que reparar.

Desactivar la aplicación de firmas, restablecer la pila de red o borrar todos los adaptadores hace que las pruebas desaparezcan. Ninguna de esas tres repara una etapa que aún no ha identificado, y cada una elimina lo que le habría dicho cuál era la etapa.