L'adaptateur TAP d'OpenVPN n'a pas pu s'installer : quelle étape a échoué ?

Le programme d'installation indique que l'adaptateur TAP n'a pas pu être créé, et cette phrase couvre au moins trois défaillances différentes. Le paquet n'a peut-être jamais été préparé, il a peut-être été préparé sans qu'aucun appareil ne soit créé, ou l'appareil existe peut-être avec un état de problème que le programme d'installation a signalé comme une erreur générique unique. Le cas que vous avez détermine qui le réparera et quelles preuves vous devez réunir.

Recueillez le numéro de build et l'horodatage d'installation avant tout le reste. Les deux transforment un dossier de journaux en une recherche que vous pouvez réellement exécuter.

Trois étapes, trois journaux différents

La première étape est le programme d'installation lui-même, qui décompresse des fichiers, tient son propre journal et signale un code récapitulatif comme 1603, qui dit que la transaction a échoué sans dire où. La deuxième est le magasin de pilotes, où un paquet signé est préparé pour un usage ultérieur, ce qui est une réussite différente de sa liaison à du matériel. La troisième est la création de l'appareil, où Windows construit une instance d'appareil, applique l'INF et consigne le résultat dans le journal setupapi. Un silence entre deux de ces étapes produit la même phrase pour l'utilisateur.

Le code récapitulatif appartient à la transaction, tandis que l'action défaillante se trouve plus haut dans le même journal. Cherchez en remontant depuis le code au lieu de tenter d'expliquer le code.

Lisez setupapi.dev.log autour de la tentative

Chaque installation d'appareil écrit une section dans C:\Windows\INF\setupapi.dev.log, et le guide du journal SetupAPI explique comment ces sections et leur état final sont organisés. Trouvez la section dont l'horodatage encadre votre tentative, puis lisez-la en entier plutôt que la première ligne d'erreur que vous remarquez. Les avertissements concernant des appareils sans rapport apparaissent tout au long d'un long journal et n'expliquent rien sur cette défaillance. L'état final de la section correspondante est le fait qui mérite d'être cité dans un rapport.

Corrélez cette section avec le nom de l'adaptateur, l'identifiant de l'appareil et le paquet INF nommé dans le journal du programme d'installation. Trois identifiants concordant au même horodatage, voilà ce qui rend l'attribution sûre.

Vérifiez le paquet et l'appareil séparément

Un paquet préparé prouve seulement qu'un INF signé a atteint le magasin de pilotes. Dans cette génération de Windows, pnputil /enum-drivers liste les paquets tiers par fournisseur, classe, version et nom publié, ce qui vous permet de trouver le paquet de l'adaptateur OpenVPN au lieu de deviner à partir d'un numéro oem. Rien dans cette liste ne dit qu'un appareil existe, a démarré ou est lié au paquet que vous avez trouvé. Ce sont des questions distinctes avec des réponses distinctes.

Le côté appareil a sa propre vision. Un inventaire d'adaptateurs en lecture seule montre ce que Windows croit actuellement de l'interface, et les entrées masquées couvrent les appareils présents mais inactifs. Comparer les deux listes vous dit quelle étape a échoué : paquet absent, appareil absent ou appareil présent avec un état de problème.

Vérifiez l'adaptateur avant de toucher aux signatures

Lisez l'état depuis la machine plutôt que depuis le récapitulatif du programme d'installation. Les commandes ci-dessous listent les paquets de pilotes préparés, l'inventaire des adaptateurs, entrées masquées comprises, et les appareils réseau qui ne signalent pas OK. Exécutez-les après un redémarrage pour que les opérations d'appareil en attente se soient stabilisées.

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

Un paquet présent sans appareil correspondant pointe vers la création de l'appareil, et la section setupapi de cet horodatage explique pourquoi. Un appareil présent avec un état de problème pointe vers le pilote ou sa signature, ce qui est une autre conversation qu'un appareil manquant. Un adaptateur qui existe et signale être déconnecté est un appareil fonctionnel sans tunnel actif, et non une installation échouée. Lisez les trois sorties ensemble avant de choisir une étape à réparer.

Désactiver l'application des signatures, réinitialiser la pile réseau ou supprimer tous les adaptateurs fait disparaître les preuves. Aucune de ces trois actions ne répare une étape que vous n'avez pas encore identifiée, et chacune supprime ce qui vous aurait dit de quelle étape il s'agissait.