前几天装完 VMware Workstation Pro 17.5.2兴冲冲地导入一个 CentOS 虚拟机按下电源键没几秒弹窗直接糊脸“VMware Workstation 与 Device/Credential Guard 不兼容。在禁用 Device/Credential Guard 后可以运行 VMware Workstation。”我当时第一反应是 VMware 装坏了重装了一遍还是这样又以为是 BIOS 里虚拟化没开进固件翻了一圈VT-x 明明开得好好的。折腾半天才意识到问题根本不在 VMware是 Windows 自己把 CPU 的虚拟化指令给“锁”了。这篇文章就把这个问题讲透报错的原因是什么、怎么确认你的机器确实中招了、如何彻底关闭 Device/Credential Guard 让 VMware 恢复运行以及如果你还要用 Docker/WSL2 的话能不能两全。适合所有在 Windows 10/11 上跑 VMware Workstation、以及正准备下载安装这款软件的朋友提前避坑。1. 问题本质Windows 的 VBS 机制和 VMware 谁在抢 CPU 的 VT-x1.1 Device Guard 和 Credential Guard 到底是个啥很多人在中文搜索里看到“Device/Credential Guard”这个词组容易把它当成一个独立的软件。其实它是 Windows 基于虚拟化的安全功能的总称底层依赖同一个东西——VBSVirtualization-Based Security基于虚拟化的安全性。Device Guard 的职责偏“代码执行防护”它内部的 HVCIHypervisor 强制代码完整性会要求所有内核驱动和系统代码必须签名、必须可信不满足条件的驱动会被直接挡在门外。Credential Guard 则偏“凭据防护”它会把域账号的哈希凭据从 LSASS 进程里隔离到一个独立的安全环境中防止类似 Pass-the-Hash 的攻击手法盗取凭据。这两兄弟的共同点是都要求 Windows 在启动阶段先把 Hyper-V 的 Hypervisor 拉起来运行在比操作系统内核更高的特权级别上再在这个 Hypervisor 之上构建隔离的安全世界。听上去很安全代价就是 CPU 的硬件虚拟化扩展被 Windows 长期占用了。1.2 VMware 为什么会被堵住VMware Workstation 是典型的 Type 2 虚拟机监控器运行在被称之为“裸机”的宿主机操作系统之上它不额外依赖 Hyper-V而是直接去操作 CPU 的 Intel VT-x/AMD-V 指令再配上 SLAT二级地址转换来调度虚拟机的 CPU 指令。一旦 Windows 启用了 VBS 且 Hypervisor 处于运行状态VT-x 和 SLAT 就被 Windows 的 Hypervisor 接管了。VMware 再去请求同一组硬件虚拟化能力就像你已经把唯一的会议室预订出去了另一个人强行刷卡进来系统只能直接拒绝。VMware 检测到 Hyper-V Hypervisor 正在运行、且 Windows Hypervisor Platform 又没有启用时就会显示这个“Device/Credential Guard 不兼容”的报错。1.3 为什么新电脑、新系统更容易中招如果你用的是 Windows 11 22H2 及以上版本并且 CPU 是近几年的酷睿/锐龙系统默认就开启了 VBS只是很多用户看不见而已。再加上 OEM 预装系统可能打开了安全中心里的“内核隔离-内存完整性”WSL2、Docker Desktop、Windows 沙盒这些功能又会自动把“虚拟机平台”勾上这些操作都会导致 Hypervisor 自启。也就是说这台机器以前不一定是你手动开的 Hyper-V只要跑过 Docker、玩过 WSL 或安卓子系统Hyper-V 的底层就已经在你机器上待命了。这时候你再装 VMware Workstation Pro 17 或者 17.5.2启动虚拟机几乎是必报错。2. 确诊比解决重要先看三个地方再动手出错以后最忌讳的就是盲目改我先说几个快速确诊的方法确认你的机器到底有没有启用 VBS 和 Hypervisor。2.1 系统信息里的“基于虚拟化的安全性”状态最快的办法WinR 输入msinfo32回车打开系统信息窗口在左侧选“系统摘要”右侧找“基于虚拟化的安全性”。这个字段可能会显示下列几种状态显示状态含义未启用VBS 没有开启问题大概率不在这里已启用但未运行系统配置了 VBS但 Hypervisor 还没有真正跑起来可能缺硬件支持或没重启正在运行Hypervisor 已占据虚拟化层VMware 报错的最典型状态顺带说一下任务管理器“性能”标签里的“虚拟化已启用”只表示 BIOS 层把 VT-x 打开了并不能说明 Hypervisor 是否在运行。很多人看到这个以为是正常状态其实它是两码事。2.2 systeminfo 和 bcdedit 告诉你有没有 Hypervisor管理员权限打开 Windows 终端或命令提示符执行systeminfo | findstr /C:Hyper-V在输出末尾找“Hyper-V 要求”那一段如果看到“已检测到虚拟机监控程序。将不显示 Hyper-V 所需的功能”可以直接断定 Hypervisor 在运行。再用bcdedit查看启动项bcdedit /enum {current}找到hypervisorlaunchtype这一项如果它的值是Auto说明 Windows 开机时会把 Hypervisor 加载起来如果是Off则不会。2.3 Windows 功能里被偷偷勾上的组件还有一个重要排查点控制面板-程序和功能-“启用或关闭 Windows 功能”里看下面这几项有没有被动过Hyper-VWindows 虚拟机监控程序平台虚拟机平台Windows 沙盒如果你没有印象自己开过 Hyper-V但这里却被勾上了那大概率是之前装 Docker Desktop、WSL2、或者运行过 Windows 沙盒时系统自动帮你打开的。这几个组件里面“虚拟机平台”是 WSL2 依赖的“Windows 虚拟机监控程序平台”是给第三方虚拟化软件提供 Hyper-V API 的“Hyper-V”则是完整虚拟化服务。只要这三项有任一项处于启用状态又没走 VMware 的共存模式报错就属于“必现”。3. 完整关闭 VBS 的操作链路确认了 VBS 在运行之后接下来就是动手关。我不建议只关其中一个开关最好按下面的链路全部走一遍彻底把 Hypervisor 从启动链里摘下来。3.1 先关 Windows 安全中心的“内存完整性”进入 Windows 安全中心-设备安全性-内核隔离把“内存完整性”开关关掉。“内存完整性”本质上就是 HVCI 的用户界面你关掉它HVCI 就不会在下次开机时启动。这一步能让基于虚拟化的安全少一个最主要的启动条件。Win11 用户如果界面路径对不上可以直接在设置里搜“内核隔离”通常也能找到这个页面。部分企业版或开启了严格安全策略的机器这个开关可能是灰的那就需要先看组策略后面会讲。3.2 取消 Windows 功能里的虚拟化组件管理员权限打开“启用或关闭 Windows 功能”窗口WinR 输入optionalfeatures回车把下面这些项全部取消勾选Hyper-V 整个目录包括 Hyper-V 管理工具和 Hyper-V 平台Windows 虚拟机监控程序平台虚拟机平台Windows 沙盒如果你还在用“适用于 Linux 的 Windows 子系统WSL”并且已经迁到了 WSL2那“虚拟机平台”关掉之后 WSL2 会失效。这一点先心理有数后面第五节会聊怎么取舍。点确定后Windows 会要求重启先不急着重启把后续命令和注册表一起处理完再统一重启。3.3 bcdedit 命令停止 hypervisor 自启动管理员权限打开终端执行bcdedit /set hypervisorlaunchtype off这条命令的作用是修改 Windows 启动配置数据直接把启动链里的 Hypervisor 摘掉。执行成功后提示“操作成功完成”再继续往下。以后如果哪天又想重新开启 Hyper-V比如要用 WSL2恢复命令是bcdedit /set hypervisorlaunchtype auto3.4 用组策略和注册表堵住“春风吹又生”单纯关 UI 开关和 bcdedit通常能解决 90% 的问题但还有两种情况会翻车一是企业域环境里有组策略下发二是 Windows 更新后自动把 VBS 重新打开。所以我习惯再用组策略和注册表双重加固。WinR 输入gpedit.msc打开本地组策略编辑器依次进入“计算机配置-管理模板-系统-Device Guard”找到“打开基于虚拟化的安全性”双击改为“已禁用”。如果策略列表里没有这一项说明你的系统版本是家庭版或者没有安装对应管理模板可以直接跳到注册表。注册表路径如下逐一检查没有的项就手动新建 DWORD[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceGuard] EnableVirtualizationBasedSecuritydword:00000000 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\CredentialGuard] Enableddword:00000000 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity] Enableddword:00000000第一个EnableVirtualizationBasedSecurity 0是总开关后面两个分别是 Credential Guard 和 HVCI 的子开关。全部设完再重启确保注册表改动生效。3.5 重启后验证重启完成后按 2.1 和 2.2 的方法重新确认一遍msinfo32里“基于虚拟化的安全性”应该变成“未启用”systeminfo的“Hyper-V 要求”部分不应该再出现“已检测到虚拟机监控程序”的提示bcdedit /enum {current}里的hypervisorlaunchtype应该变成Off。这时候再打开 VMware Workstation启动刚才那个 CentOS 虚拟机应该就能正常进系统了。64 位客户机的运行速度和之前 32 位无感的状态没有明显差别说明 Hypervisor 已经让出了 VT-x。4. 踩坑实录常见弯路与连锁反应这部分说说我实际踩过的坑以及读者反馈里出镜率很高的几个弯路。写出来是想让你别把时间浪费在无效操作上。4.1 弯路一重装 VMware、升级到 17.5.2 也没用很多人第一次看到这个报错都会本能地认为是 VMware 安装文件损坏或者版本有 bug。我一开始也是这么想的把 VMware Workstation Pro 卸载清理又下载最新版 17.5.2 重装结果开机照样弹窗。原因其实很简单VMware 安装过程本身不需要抢占 VT-x所以安装阶段一切正常只有真正启动虚拟机时才会去请求硬件虚拟化资源此时冲突才暴露。你重装一百遍Windows 里的 Hypervisor 还霸占着 VT-x结果不会变。所以遇到这个弹窗先别折腾 VMwaer去查 VBS。4.2 弯路二以为 BIOS 的 VT-x 没开这个报错的英文里包含“Device/Credential Guard”中文翻译里也带着同样的词很多人第一反应去 BIOS 里找“虚拟化技术”这一项将其从 Disabled 改成 Enabled。结果进 BIOS 一看VT-x 本来就开着。不要被误导。Device/Credential Guard 是 Windows 层的功能不是 BIOS 层的设置。只要任务管理器显示“虚拟化已启用”BIOS 层面就没问题。去 BIOS 乱改不但解决不了问题还可能会误改其他启动项。4.3 弯路三关了内存完整性重启后又被“复活”只关掉安全中心里的“内存完整性”确实让一部分人暂时进了 VMware但没过多久又报错。原因就在于 Windows 功能里的“虚拟机平台”或“Windows 虚拟机监控程序平台”还开着Windows 在更新或者某些功能触发时又把 VBS 拉起来了。严格说把“虚拟机平台”和“Windows 虚拟机监控程序平台”关闭后再重启VBS 就不会被复用比只关内存完整性牢靠得多。组策略和注册表则是再上一道保险防止企业策略或更新把它设回去。4.4 连锁反应Docker、WSL2、Windows 沙盒一起罢工关闭 VBS 最直接的副作用就是依赖 Hypervisor 的功能全部失效。如果你平时用 Docker Desktop 的 WSL2 后端关闭“虚拟机平台”后 Docker Desktop 启动会直接报错WSL2 里的 Linux 发行版也会无法进入Windows 沙盒则干脆从“启用或关闭 Windows 功能”里取消勾选后就不能用了。这个连锁反应对开发者的影响比报错本身更大。所以我不建议所有人都无脑关 VBS先想清楚你日常主力工作流是什么。5. 不想二选一VMware 和 Docker/WSL2 共存的可行路线如果你既要用 VMware Workstation又离不开 WSL2 或 Docker Desktop那还有一条路子启用 Windows Hypervisor Platform让 VMware 通过 Windows 的 Hypervisor 接口来运行而不是直接抢占 VT-x。5.1 VMware 官方支持的共存方式Windows Hypervisor Platform在“启用或关闭 Windows 功能”里重新勾选“Windows 虚拟机监控程序平台”重启。这个功能通俗讲就是微软给第三方虚拟化软件开了一个 API 通道让 VMware 等软件不用直接跟 Hypervisor 抢 VT-x而是调用 Windows 提供的虚拟化接口来创建虚拟机。VMware Workstation 15.5.5 及以后的版本都支持这条共存路径17.x 版本更成熟一些。启用后VMware 会自动检测到 Windows 的 Hypervisor并使用 WHP API 运行虚拟机。注意这个模式下你还是需要保留“虚拟机平台”等相关功能所以 WSL2 和 Docker Desktop 也能继续用。5.2 WHP 模式的真实体验与性能代价我在 Win11 23H2 上实测启用 WHP 后 VMware 确实可以正常运行日常跑一些 Linux 服务器、编译环境没有太大问题。但性能不是免费的WHP API 相当于在 VMware 和硬件之间多包了一层系统调用CPU 密集型任务会有可见损耗特别是嵌套虚拟化这种对硬件特性要求极高的场景。官方支持文档里也列了限制包括嵌套虚拟化场景不支持或表现不稳定需要充足的内存来承载 Windows Hypervisor 本身的资源开销有些处理器的 AVX-512 等高级指令集在 WHP 模式下无法直接透传给虚拟机。所以如果你只是想跑一个轻量级测试环境顺带用 WSL2 写代码共存模式挺香如果你要在 VMware 里做性能测试、玩模拟器或者经常跑嵌套虚拟化建议还是走第 3 节彻底关闭 VBS 的路线。5.3 彻底转换把 VMware 虚拟机迁移到 Hyper-V如果你的工作流打算全面转向 Hyper-V 生态也可以把 VMware 的虚拟机迁移到 Hyper-V。这一步并不复杂在 VMware 虚拟机内先卸载 VMware Tools然后正常关机。使用 StarWind V2V Converter 或者 VMware vCenter Converter把 vmdk 磁盘文件转成 vhdx 格式。在 Hyper-V 管理器里新建虚拟机挂载转换好的 vhdx 磁盘。启动虚拟机后安装 Hyper-V 集成服务网卡和磁盘驱动一般会在系统更新后自动补上。迁移后性能基本看齐原生 Hyper-V而且能和 WSL2、Docker 共存。注意转换前一定要卸载 VMware Tools否则 Windows 系统里残留的驱动容易在迁移后触发蓝屏这是比较容易忽略的步骤。5.4 按场景选方案总结一下三种思路适合的人不一样方案适合场景代价彻底关闭 VBS/Hyper-V只跑 VMware不依赖 WSL2/Docker/沙盒WSL2、Docker Desktop、Windows 沙盒失效启用 WHP 共存既要 VMware 又要 WSL2/DockerVMware 性能损耗嵌套虚拟化受限迁移到 Hyper-V主攻 WSL2/Docker虚拟机只是辅助需要一次转换流程学习成本高我个人在实际操作中的体会是没有绝对正确的选项只有适合你工作流的选项。如果你只是想在 Windows 上开一台虚拟机做实验又不想多操心直接关闭 VBS 是最干净的如果你把 WSL2 当日常主力开发环境那么 WHP 共存模式值得先在自己常用的系统上压测几天看看性能能不能接受。最后再提醒一句在公司配发的电脑上执行这些操作之前先确认 IT 安全策略是否允许有些域环境会强制启用 VBS你改了注册表也可能被组策略刷新拉回来那种情况下就只能协调 IT 或改用远程服务器了。