前几天装完 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-x
1.1 Device Guard 和 Credential Guard 到底是个啥
很多人在中文搜索里看到“Device/Credential Guard”这个词组，容易把它当成一个独立的软件。其实它是 Windows 基于虚拟化的安全功能的总称，底层依赖同一个东西——VBS（Virtualization-Based Security，基于虚拟化的安全性）。
Device Guard 的职责偏“代码执行防护”，它内部的 HVCI（Hypervisor 强制代码完整性）会要求所有内核驱动和系统代码必须签名、必须可信，不满足条件的驱动会被直接挡在门外。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 系统信息里的“基于虚拟化的安全性”状态
最快的办法，Win+R 输入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-V
- Windows 虚拟机监控程序平台
- 虚拟机平台
- 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 功能”窗口（Win+R 输入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 重新打开。所以我习惯再用组策略和注册表双重加固。
Win+R 输入gpedit.msc打开本地组策略编辑器，依次进入“计算机配置-管理模板-系统-Device Guard”，找到“打开基于虚拟化的安全性”，双击改为“已禁用”。如果策略列表里没有这一项，说明你的系统版本是家庭版或者没有安装对应管理模板，可以直接跳到注册表。
注册表路径如下，逐一检查，没有的项就手动新建 DWORD：
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceGuard] "EnableVirtualizationBasedSecurity"=dword:00000000 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\CredentialGuard] "Enabled"=dword:00000000 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity] "Enabled"=dword: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/Docker | VMware 性能损耗，嵌套虚拟化受限 |
| 迁移到 Hyper-V | 主攻 WSL2/Docker，虚拟机只是辅助 | 需要一次转换流程，学习成本高 |
我个人在实际操作中的体会是，没有绝对正确的选项，只有适合你工作流的选项。如果你只是想在 Windows 上开一台虚拟机做实验又不想多操心，直接关闭 VBS 是最干净的；如果你把 WSL2 当日常主力开发环境，那么 WHP 共存模式值得先在自己常用的系统上压测几天，看看性能能不能接受。最后再提醒一句，在公司配发的电脑上执行这些操作之前，先确认 IT 安全策略是否允许，有些域环境会强制启用 VBS，你改了注册表也可能被组策略刷新拉回来，那种情况下就只能协调 IT 或改用远程服务器了。
