前几天给一台 Windows 11 的模板机装 VMware Tools，Workstation 16 Pro 弹出这行提示：“安装程序无法自动安装 Virtual Machine Communication Interface(VMCI) 驱动程序。必须手动安装此驱动程序。”第一反应是安装包坏了，重装一遍还是原样，设备管理器里那个带黄色感叹号的设备怎么看怎么扎眼。后来排查才发现，问题根本不在 VMware 这一侧，是系统的安全机制在拦截驱动加载。这篇就把 VMCI 驱动手动安装的完整链路、连带的各种报错和解决方案一次讲清楚。
1. VMCI 驱动到底是个什么东西，为什么装不上比想象中频繁
1.1 vmci.sys 在虚拟机里的角色和一些常见误解
VMCI 全称 Virtual Machine Communication Interface，是 VMware 虚拟机和宿主机之间的一组高速通信通道。你可以把它想成虚拟机内部的一个信箱，宿主机要往虚拟机里送文件、同步剪贴板、做拖拽复制、共享文件夹，都由这个设备承担。Windows 虚拟机里对应的驱动文件是 vmci.sys，设备管理器里显示为 VMware VMCI，硬件 ID 通常是PCI\VEN_15AD&DEV_0740，厂商 ID 15AD 就是 VMware 的 PCI 编号。
很多资料把它当成“可选的性能增强组件”，这个说法容易误导人。VMCI 不工作，虚拟机不是不能跑，但体验下降非常明显：拖拽文件失效、剪贴板不同步、共享文件夹偶尔能连上偶尔报错，有时候鼠标在虚拟机里也会出现轻微卡顿。所以遇到安装报错，最好还是第一时间解决，不要直接跳过。
1.2 VMware Tools 安装程序为什么会选择“跳过并让你手动装”
VMware Tools 在 Windows 上安装时，会依次做几件事：复制驱动文件到C:\Program Files\VMware\VMware Tools\Drivers\下对应子目录，创建驱动服务，再通过系统的设备安装机制绑定到虚拟设备上。VMCI 驱动在这个流程里被归类为非阻断组件，意思是它装失败了，安装程序不会回滚整个 Tools，而是继续往下走，最后给你弹一段“必须手动安装”的提示。
这就有个问题：很多人以为 Tools 装完了就等于所有功能都正常了，其实 VMCI 设备可能一直在设备管理器里躺着报错。我遇到得最多的场景，就是用户装完 Tools 后虚拟机内拖拽没反应，打开设备管理器才发现 VMCI 是黄叹号，然后才回来翻安装日志。所以装完 Tools 后顺手看一眼设备管理器，应该成为固定习惯，尤其是 Windows 10 1809 之后的系统。
提示：如果在设备管理器里看到的是“PCI 简单通讯控制器”而不是“VMware VMCI”，说明 VMCI 设备已经枚举出来了，但驱动完全没绑定，这也符合“必须手动安装”的提示逻辑。
2. 动手装驱动之前，先花三分钟确认三件事
2.1 用 PowerShell 确认 VBS 开没开，这步排第一
Windows 10 1809 和 Windows 11 默认会开启基于虚拟化的安全（VBS），其中最常见的影响项是内存完整性（内核隔离），它会阻止未通过兼容性校验的第三方内核驱动加载。VMCI 驱动虽然是 VMware 官方签名的，但如果 Tools 版本偏老，驱动没在微软的兼容清单里，照样会被拦下来。
检查方法有两种。图形界面在“Windows 安全中心 → 设备安全性 → 内核隔离”里看“内存完整性”是不是开着，但更靠谱的是用 PowerShell 一次性查清楚：
Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard | Select-Object VirtualizationBasedSecurityStatus, SecurityServicesConfigured, SecurityServicesRunning返回结果里，VirtualizationBasedSecurityStatus为 0 表示 VBS 未启用，为 2 表示已启用并正在运行；SecurityServicesRunning为 2 表示 HVCI 正在运行，也就是内存完整性处于工作状态。如果这两个值都中招，那很大概率就是它拦截了 VMCI 驱动的自动安装。
2.2 设备管理器里实际看到的设备状态
打开设备管理器，展开“系统设备”，找到 VMware VMCI 或带黄叹号的 PCI 简单通讯控制器。右键属性，切换到“详细信息”，查看硬件 ID，确认里面包含VEN_15AD&DEV_0740。这一步很重要，因为有些机器上 Tools 装到一半，设备名称可能显示成“未知设备”，用户根本意识不到这是 VMCI。
看状态时留意两列信息：设备状态代码和问题代码。常见的代码 28 是“未安装设备驱动程序”，代码 31 是“无法加载驱动程序”。这两个的处理方向不一样：代码 28 走“从磁盘安装”这条路就行；代码 31 通常代表驱动文件已经绑到设备上了，但被系统策略拦下，或者驱动服务无法启动，解法要复杂一些，后面第 4 章专门说。
2.3 清理残留旧驱动，防止“覆盖安装”逻辑卡死
如果在排查之前已经反复重装过 Tools，系统里很可能残留了旧版 vmci 服务。安装程序在覆盖安装时碰到同名服务，有时候不会干净地替换，导致设备一直处于错误状态。清理方法是用管理员权限执行：
sc.exe query vmci sc.exe stop vmci sc.exe delete vmci设备管理器里如果有带叹号的 VMware VMCI，右键选择卸载设备，勾选“删除此设备的驱动程序软件”，然后重启一次虚拟机。这一步能避免后面手动安装时，安装程序以为“驱动已经存在”而拒绝真正落盘。
3. 手动安装 VMCI 驱动的完整链路，GUI 和命令行两条路都走一遍
3.1 先把 Tools 安装镜像挂上，确认驱动文件在哪
Workstation 自带的 Tools 镜像文件叫 windows.iso，默认路径是：
C:\Program Files (x86)\VMware\VMware Workstation\windows.iso如果你的 Workstation 装在别的盘，直接搜索 windows.iso 就行。在虚拟机设置里把 CD/DVD 指到这个镜像，重启虚拟机后在资源管理器里打开光驱，运行 setup64.exe。如果 Tools 主程序已经装完，只是 VMCI 失败，那么驱动文件其实已经解压到本机了，路径固定在：
C:\Program Files\VMware\VMware Tools\Drivers\vmci里面应该能找到 vmci.inf 和 vmci.sys。如果 Tools 主程序本来就装不成功，可以把 windows.iso 用 7-Zip 解压后搜索 vmci.inf，同样能拿到驱动源文件，只是路径会绕一些。
3.2 图形界面操作：从磁盘安装驱动，注意选择顺序
在设备管理器里找到 VMCI 设备，选择“更新驱动程序”，然后按下面顺序操作：
- 选择“浏览我的电脑以查找驱动程序”
- 选择“让我从计算机上的可用驱动程序列表中选取”
- 点击“从磁盘安装”
- 浏览到
C:\Program Files\VMware\VMware Tools\Drivers\vmci或解压出来的驱动目录 - 选中 vmci.inf，确认安装，等待系统完成绑定
这里有一个很多人不知道的细节：在“从列表选取”这一步，系统会先列出自己内置的兼容驱动库，里面往往已经有一条 VMware VMCI。如果列表里出现了它，直接选它比“从磁盘安装”更稳，因为系统会先做一轮签名和兼容性校验。只有列表里没有的时候，才需要点“从磁盘安装”去指定 vmci.inf。我一般在现场会先看一眼列表，能少踩很多签名问题的坑。
3.3 命令行安装 pnputil，适合批量复制环境
如果是给一批模板机做策略，直接走命令行更高效。用管理员权限打开 PowerShell，执行：
pnputil /add-driver "C:\Program Files\VMware\VMware Tools\Drivers\vmci\vmci.inf" /install/install参数会尝试直接为匹配的设备安装驱动，不用打开设备管理器。完成后再验证：
pnputil /enum-drivers | Select-String -Pattern "vmci" sc.exe query vmci如果 pnputil 返回错误 0xe0000247 之类的签名类问题，说明还是被 VBS 或驱动签名策略拦住了，那就得回到第 2 章去处理系统层面的拦截，而不是死磕命令本身。
3.4 装完以后如何确认真的生效了
驱动装上不代表立刻生效，建议执行两步检查。第一步看服务状态：
sc.exe query vmci返回值里STATE应该是RUNNING。如果只是STOPPED，需要看WIN32_EXIT_CODE，常见的是 31 或 127，说明驱动虽然安装了但加载失败。第二步重新认一遍设备状态：
Get-PnpDevice | Where-Object { $_.InstanceId -like '*VEN_15AD&DEV_0740*' } | Select-Object Status, ProblemStatus 显示 OK，Problem 为 0，说明设备已经正常。这时候再去测一下宿主机和虚拟机之间的拖拽复制，基本就恢复了。
4. 装上不等于没事，后续这些报错要一起处理
4.1 设备管理器代码 31 的排查链路
代码 31 在 VMCI 设备上出现的频率很高，而且往往在手动安装完成、重启之后才暴露出来。这时驱动文件其实已经落盘了，服务也创建了，但 Windows 加载驱动时被拦了回来。排查顺序我建议按下面走：
- 事件查看器 → Windows 日志 → 系统，找 kernel-driver 或 Service Control Manager 来源的错误，确认具体是哪个驱动被拒绝
- 管理员 PowerShell 执行
sc.exe query vmci，确认服务状态 - 尝试手动拉起来：
sc.exe start vmci，如果报错，记住错误码再去搜
代码 31 最常见的根因有两个：一是 VBS 拦截，二是驱动被新的安全策略标记为易受攻击。前者回到内存完整性那一步处理，后者看下面的 4.2 节。
4.2 Windows 11 24H2 常见的“易受攻击驱动”拦截
最近在 Windows 11 24H2 上特别典型的一个现象是：设备管理器里报错原因显示“某个安全设置将其检测为易受攻击的驱动程序”。这是 Windows 安全中心的“Microsoft 易受攻击的驱动程序阻止列表”在起作用，老版本 VMware Tools 12.4、12.5 的 vmci.sys 就曾被列入这个清单。
解决办法是升级 VMware Tools。Workstation 16 Pro 如果想继续用，建议把 Tools 升到 12.6 以上的版本；如果 Workstation 版本本身偏老，直接升级到 17.6 或更新的版本，内置的 Tools 自然就是新版，vmci.sys 也已经重新签名。
如果由于环境限制无法升级，临时路口是关闭这个阻止列表：Windows 安全中心 → 设备安全性 → 内核隔离 → Microsoft 易受攻击的驱动程序阻止列表，关掉后重启。注意这个开关在企业域环境里经常是灰色不可改的，说明被组策略或 Intune 锁定了，这时候不要硬改注册表，应该联系管理员下发新版本 Tools 或添加白名单。
4.3 vmx86.sys 版本不匹配，和虚拟机内 VMCI 是两件事
热词里经常出现“vmx86 驱动程序的版本不匹配: 预期为 418.0, 实际为 385.0”，这里提醒一句：vmx86.sys 是 Workstation 主机侧的驱动，跟虚拟机内部的 vmci.sys 不是同一个东西，但很多人在排查 VMCI 问题时会把它们混在一起。
vmx86 版本不匹配，通常是主机上残留了旧版 Workstation 的内核驱动，或者从 16 Pro 升级到 17 时旧驱动没清理干净。处理方向是：先卸载旧版 Workstation，重启后用文件搜索确认C:\Windows\System32\drivers\vmx86.sys已被删除，再安装新版 Workstation。如果你打算彻底换个版本，装完后在“应用与功能”里执行一次修复安装，也会重新覆盖一遍驱动。
下面整理了一张常见报错和处理方向的对照表，排查时可以直接对号入座：
| 现象 | 根因方向 | 处理建议 |
|---|---|---|
| 安装程序提示必须手动安装 VMCI | 内存完整性拦截或 Tools 版本过旧 | 优先升级 Tools，必要时关闭内存完整性后从磁盘安装 |
| 设备管理器中 VMCI 设备代码 28 | 驱动未安装 | 手动指定 vmci.inf 从磁盘安装 |
| 设备管理器中 VMCI 设备代码 31 | 驱动被策略拦截或服务无法启动 | 查事件日志，检查易受攻击驱动阻止列表 |
| 提示易受攻击的驱动 | vmci.sys 未被新系统信任 | 升级 VMware Tools 到 12.6+ |
| Workstation 启动报 vmx86 版本不匹配 | 主机侧旧驱动残留 | 彻底卸载旧版 Workstation 后重新安装 |
5. 根据运行环境选择处理顺序，别一上来就关内存完整性
5.1 不同场景下的优先级排序
第 2、3、4 章讲了各种招，但实际处理时不能一上来就关内存完整性，那是最后一招。我给不同环境做了个优先级排序，大家可以参照：
| 场景 | 第一步 | 第二步 | 最后手段 |
|---|---|---|---|
| 个人开发机，Windows 11 23H2，Tools 12.4 | 升级 Tools 到 12.6+ | 重装 Tools，观察是否自动装好 VMCI | 关闭内存完整性后从磁盘安装 |
| 个人开发机，Windows 11 24H2 | 直接升 Workstation 17.6 或 Tools 12.6+ | 正常重装 Tools | 临时关闭易受攻击驱动阻止列表 |
| 内网离线环境，无法获取新版 Tools | 清理残留 vmci 服务 | 正常模式从磁盘安装 | 临时关内存完整性，装完再开 |
| 企业域环境，策略锁定安全设置 | 联系管理员下发新版 Tools 或白名单 | 让管理员执行批量化安装 | 不要绕策略，会引发合规问题 |
我个人更推荐优先更新 Tools 版本，而不是去动系统安全设置。新版 vmci.sys 已经通过了 Windows 硬件兼容性签名，在 VBS 开启的状态下也能正常安装，这才是治本。手动从磁盘安装驱动只是应急手段，适合临时恢复环境，不适合作为长期方案。
5.2 内存完整性真的非关不可吗，关闭前先想清楚
内存完整性是 VBS 保护体系里的一道重要防线，负责确保内核模式驱动在加载前通过签名和完整性验证。关闭它，系统整体的防御等级会明显下降，尤其是面对易受攻击驱动攻击时少了一层关键防护。所以我的判断标准很简单：
- Tools 版本很旧，且升级Tools在当下不可行——临时关，装完立刻恢复
- Tools 已经是新版，但仍然报 VMCI 失败——大概率不是内存完整性的问题，别急着关，先查设备状态和事件日志
- 设备管理器里显示的是代码 31 而不是代码 28——关内存完整性往往也没用，要考虑易受攻击驱动阻止列表
如果确实走到临时关闭这一步，路径是：Windows 安全中心 → 设备安全性 → 内核隔离 → 内存完整性，关闭后重启，装好驱动后再重新打开，重启一次。逻辑上驱动一旦装好并注册进系统，重新开启内存完整性后通常不会再次拦截，但我还是建议装完后验证一次。
5.3 装完 Tools 后值得顺手检查的几项
问题解决之后，别急着关虚拟机。模板机如果后续还要系统封装或分发给其他人，VMCI 状态必须稳定，不然发出去的镜像个个拖拽失效。我会再花几分钟做一遍完整检查：
sc.exe query vmci Get-PnpDevice | Where-Object { $_.InstanceId -like '*VEN_15AD&DEV_0740*' } | Select-Object Status, Problem然后测一次宿主机往虚拟机拖文件，确认剪贴板能双向同步，再右键虚拟机的“设置” → “选项” → “客户机隔离”，确认启用拖拽和复制粘贴。如果这些都正常，VMCI 这个坑就算真正跨过去了。
最后再分享一个小技巧：如果你手上有多个环境反复遇到这个问题，建议在虚拟机模板里把 vmci.inf 的驱动文件路径固定下来，后续只需要直接指向C:\Program Files\VMware\VMware Tools\Drivers\vmci就能完成手动安装。养成装完 Tools 就看一眼设备管理器的习惯，能让这套虚拟化环境的稳定性提升不少。
