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 段落会说明原因。设备存在但处于问题状态，说明问题在驱动或其签名上，这与设备缺失是两回事。适配器存在并报告已断开，说明它是一个没有活动隧道的正常设备，而不是安装失败。在选定要修的环节之前，请把三份输出放在一起读。

关闭签名强制、重置网络栈，或删掉所有适配器，都会让证据消失。这三件事没有一件能修复你还没定位到的环节，而且每一件都拿掉了本可以告诉你问题出在哪一阶段的线索。