企业官网建设流程全解析

VMware Workstation 启动虚拟机时弹窗提示“您的 CPU 不兼容”或“安装程序检测到主机启用了 Hyper-V 或 Device/Credential Guard”，这个问题在近两年几乎是所有 VMware 重度使用者都会撞上的坑。尤其当你换了新电脑、升级了 Windows 11 系统，或者装完某次系统大版本更新之后，VMware 突然就打不开任何虚拟机了，报错信息五花八门，但根子往往只有一个：Windows 的虚拟化安全功能和你本地的 VMware Workstation 抢地盘。

这篇文章我不打算复述官方文档，就从一个实际故障案例出发，把 Device Guard 和 Credential Guard 到底是什么、它们为什么和 VMware 过不去、以及我实测有效的几种解决路径，完整梳理一遍。无论你是刚接触 VMware 的小白，还是被这个问题困扰已久的老手，看完应该都能自己动手搞定。

1. 报错截图背后的完整排查链路

先说一个我前阵子处理的真实案例。朋友一台 ThinkPad，配置不低，i7-12700H、32GB 内存、1TB 固态，系统是 Windows 11 专业版。他装的是 VMware Workstation Pro 17，之前一直好好的，某天 Windows 更新重启后，打开任意虚拟机，直接弹出：

主机不支持嵌套虚拟化。模块“HV”启动失败。

再仔细一看，还有一条更经典的：

您的主机不满足在启用 Hyper-V 或 Device/Credential Guard 的情况下运行 VMware Workstation。

他第一反应是 VMware 版本太旧，升级到当时最新的 17.5.x，问题依旧。又怀疑是 BIOS 里的虚拟化开关被更新重置了，进 BIOS 确认 Intel VT-x 和 VT-d 都开着，还是不行。这时候他才意识到，问题大概率出在 Windows 系统层。

我让他打开 PowerShell（管理员模式），运行：

systeminfo

在输出结果里找到“Hyper-V 要求”那一栏，果然显示：

Hyper-V 要求: 已检测到虚拟机监控程序。将不显示 Hyper-V 所需的功能。

这里“已检测到虚拟机监控程序”直接说明了问题——Windows 自带的 Hypervisor 已经占用了 CPU 的虚拟化扩展，VMware Workstation 作为 Type-2 虚拟机监控程序，正常情况下需要直接访问 VT-x/AMD-V 指令，但此时这些指令已经被 Windows 的 Hypervisor 层接管了，VMware 拿不到硬件的完全控制权，自然就报不兼容。

这个排查链路其实很典型：现象（虚拟机打不开）→ 直接原因（HV 模块启动失败）→ 深层原因（Windows Hypervisor 抢占虚拟化资源）→ 根源（Device Guard / Credential Guard 或 Hyper-V 功能被启用）。很多人卡在第二步就跑去重装 VMware 或者刷 BIOS，方向跑偏了。

1.1 为啥 Windows 更新会突然触发这个问题

很多用户不解：我用得好好的，为什么一次更新之后就崩了？

答案藏在 Windows 11 的安全策略里。从 Windows 10 1803 开始，微软逐步默认在支持设备上开启“内核隔离”和“内存完整性”（Memory Integrity），这两个功能底层依赖 Virtualization-Based Security（VBS），而 VBS 的核心组件就是 Hyper-V Hypervisor。Windows 11 更是把 VBS 作为系统安全基线的一部分，新装系统或者大版本更新后，只要硬件满足条件，系统可能自动开启相关功能。

另外，有些品牌机（尤其是商用机型），出厂镜像里就预置了 Device Guard 相关的组策略或注册表配置。当系统检测到当前环境满足 Credential Guard 的运行条件时，它会在后台悄悄地开启这些安全功能，用户根本感知不到，直到某天打开 VMware 才一脸懵。

所以，你在排查的时候，不要只盯着“我有没有手动开过 Hyper-V”，更要检查那些“被动开启”的项。

2. Windows 虚拟化安全功能与 VMware 的底层冲突原理

先把几个容易混淆的概念理清楚。

Device Guard和Credential Guard是微软基于虚拟化安全（VBS）的兩大安全特性。Device Guard 主要负责代码完整性校验，防止恶意驱动和未签名代码在系统层运行；Credential Guard 则把用户的域凭据、NTLM 哈希等敏感信息隔离在一个独立的虚拟化容器里，即使系统被攻破，攻击者也拿不到内存中的凭据。这俩听着很高大上，但它们运作的前提是：Hyper-V Hypervisor 必须处于运行状态，并且独占 CPU 的虚拟化扩展能力。

VMware Workstation是典型的 Type-2 虚拟机监控程序，它运行在宿主机操作系统之上，通过直接执行特权指令和硬件辅助虚拟化（VT-x/AMD-V）来模拟 CPU 行为。当 Hypervisor 已经加载并持有了 VT-x 的控制权，VMware 只能通过 Hypervisor 提供的接口（即 Windows Hypervisor Platform，简称 WHP）来间接使用虚拟化功能。

这就产生了一个很尴尬的处境：VMware Workstation 本身并不天然支持通过 WHP 来运行所有客户机系统。虽然从 Workstation 15.5.5 开始，VMware 官方加入了 Windows Hypervisor Platform 的支持，但实际体验很多人应该清楚：开启 WHP 后，虚拟机性能明显下降，而且部分依赖特定 CPU 指令的功能（比如嵌套虚拟化）会直接失效或不稳定。

所以 VMware 给出的建议很明确：如果你想获得最佳兼容性和性能，要么关掉 Windows 的虚拟化安全功能，要么就别用 VMware，换 Hyper-V 或 WSL2。两者共存的代价是性能和功能妥协。

2.1 Hyper-V 与 Device/Credential Guard 的联动关系

这里有个关键点要讲透：很多时候你根本没有手动启用“Hyper-V”功能，但 Device Guard 或 Credential Guard 启动后，Windows 会自动加载 Hyper-V Hypervisor。

可以这样理解：Hyper-V 是一个功能组件，你可以通过“启用或关闭 Windows 功能”手动开关它；而 Device Guard / Credential Guard 是安全策略，它们依赖 Hyper-V 的底层 Hypervisor 运行环境。当你开启 Credential Guard 或 VBS 时，即便“Hyper-V 功能”那个勾选框没打上，Hypervisor 也会被拉起来。

这解释了为什么你在“Windows 功能”面板里看“Hyper-V”明明是未勾选状态，却依然报 VMware 不兼容的错。检查路径不能只看功能面板，还要看 VBS 是否处于运行状态。

在 PowerShell 里可以这样确认：

Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard

重点关注VirtualizationBasedSecurityStatus这个字段：

• 值为2：VBS 正在运行
• 值为1：VBS 已启用但未运行
• 值为0：VBS 未启用

如果返回值是2，恭喜你，真相大白。我还遇到过一种情况，VirtualizationBasedSecurityStatus是1，但 VMware 一样报错，原因是系统提示需要重启才生效，重启之后才彻底激活。所以查状态的时候，别只看一次结果，有条件的话重启后复验一次。

3. 组合拳方案：关闭 VBS、Hyper-V 与内核隔离

下面进入实操环节。根据我处理过的几十台机器，最彻底、最省心的方案是三步走：关闭内核隔离、禁用 Hyper-V 功能、通过 bcdedit 关闭 Hypervisor 启动项。这三步做完，基本能解决 99% 的兼容性问题。

3.1 第一步：关闭 Windows 安全中心的内存完整性

Windows 安全中心 → 设备安全性 → 内核隔离 → 内存完整性，把它设为“关”。

这一步的作用是关闭基于虚拟化的代码完整性检查，它是 VBS 最活跃的组件之一。关掉之后系统通常会提示重启，先不急着重启，把下两步做完再统一重启，省时间。

注意：家庭版 Windows 可能没有“内核隔离”这个入口。别慌，直接用后面两招，效果一样。

3.2 第二步：在“启用或关闭 Windows 功能”中关闭 Hyper-V

控制面板 → 程序 → 启用或关闭 Windows 功能，找到“Hyper-V”节点。如果你用不到 Windows 自带的虚拟机，直接取消勾选整个 Hyper-V 根节点。

这里要留意，Hyper-V 节点展开后有“Hyper-V 管理工具”和“Hyper-V 平台”两组。如果你只装了管理工具（比如你平时要远程连 Hyper-V 服务器），可以只取消“Hyper-V 平台”下面的子项，保留管理工具。但严格来说，只要 Hypervisor 不启动，管理工具不会占用虚拟化资源，保留无妨。

Hyper-V ├─ Hyper-V 管理工具 │ ├─ Hyper-V GUI 管理工具 │ └─ Hyper-V 模块 for Windows PowerShell └─ Hyper-V 平台 ├─ Hyper-V Hypervisor ├─ Hyper-V 服务 └─ Hyper-V 数据交换

真正导致 VMware 报错的核心是“Hyper-V Hypervisor”这一项，它必须处于关闭状态。

3.3 第三步：用 bcdedit 强制关闭 Hypervisor 启动项

这一步是关键中的关键。在某些系统版本上，即便你手动关闭了 Hyper-V 功能，Hypervisor 依然会随系统启动。这通常是组策略或注册表安全策略在背后起作用。这时候就要动用 boot loader 层面的开关。

以管理员身份打开命令提示符或 PowerShell，执行：

bcdedit /set hypervisorlaunchtype off

执行成功后会提示“操作成功完成”。这个命令的含义是：告诉 Windows Boot Manager，不要启动 Hypervisor，即使有安全策略要求也不启动。

使用bcdedit修改的是启动配置数据，修改前建议先备份一下：

bcdedit /export C:\bcd_backup

万一之后出问题，可以随时恢复：

bcdedit /import C:\bcd_backup

改完之后重启电脑，再次运行systeminfo，如果看到“已检测到虚拟机监控程序。将不显示 Hyper-V 所需的功能。”这句话消失了，取而代之的是正常的硬件虚拟化信息，说明 Hypervisor 已经彻底退场。

3.4 开启 Hyper-V 场景下的备用方案：Windows Hypervisor Platform

有些用户不是想关 Hyper-V，而是确实需要同时跑 Docker（依赖 WSL2/Hyper-V）和 VMware。遇到这种情况，强制关闭 Hypervisor 虽然能救 VMware，但会牺牲 WSL2 和 Docker 的可用性，有点拆东墙补西墙的意思。

针对这类需求，VMware 被微软“说服”后加入了对 WHP 的支持。你可以在 Windows 功能里打开“Hyper-V”和“Windows 虚拟机监控程序平台”，然后在 VMware 虚拟机设置里把“虚拟化引擎”从“Intel VT-x/AMD-V”切换为“Hyper-V”：

虚拟机设置 → 处理器 → 虚拟化引擎 → 首选模式：Hyper-V

但这不算完美的解决方案。我自己实测下来，开启 WHP 后虚拟机性能大概会有 5%~10% 的损失，而且如果你的虚拟机里还要跑独立的虚拟化服务（比如开安卓模拟器、再套一层 VMware/ VirtualBox），大概率会失败。所以，能用“关”解决的问题，就别用“兼容模式”硬扛。

4. 不动系统功能也能跑的临场办法：运行时关闭 Hypervisor

某些场景下你既不想关 VBS（比如公司安全策略强制要求开启），又需要临时跑一下 VMware，有没有办法？

有。你可以使用运行时切换 Hypervisor 的方式：系统启动时正常带 Hypervisor，等你需要运行 VMware 时，在引导层面临时切换到“无 Hypervisor”模式，用完之后再切回来。Windows 为此提供了原生的双引导配置支持。

4.1 创建无 Hypervisor 的独立引导项

以管理员身份打开命令行，按顺序执行以下命令：

bcdedit /copy {current} /d "Windows 11 - 无 Hypervisor"

这条命令会生成一个新的引导项，并返回一个新 GUID。然后依次执行：

bcdedit /set {你的新GUID} hypervisorlaunchtype off bcdedit /set {你的新GUID} description "Windows 11 - 无 Hypervisor"

之后重启电脑，在引导菜单里选择“Windows 11 - 无 Hypervisor”进入系统，这个环境下的 Windows 不会加载 Hypervisor，VMware 可以完美运行。需要 Docker/WSL2 时，再重启选回正常系统。

有人会问，每次切换都要重启，麻烦不麻烦？麻烦，但这是在不关闭安全功能的前提下最稳的路径。对于公司强制开启 VBS 的场景，你几乎没有别的选择。而且现在固态硬盘重启也就是半分钟的事，比起性能损失和虚拟化嵌套失败，这点代价是可以接受的。

4.2 日常使用中的引导项管理技巧

引导菜单默认等待时间是 30 秒，如果你经常切换，可以调短一点：

bcdedit /timeout 5

想删除那个备用引导项，执行：

bcdedit /delete {你的新GUID}

需要注意的是，删除前确认你当前不是正在使用那个引导项，否则会提示失败。

5. 常见场景对照：你的情况适合哪种方案

不同用户遇到这个问题的背景千差万别，对应的最优解也不一样。我按场景做了个分类，你可以直接对号入座。

这个表格不是我凭空拍的，是根据我处理过的真实求助案例做的归类。尤其“必须开 VBS”那一行，我见过太多人被公司安全软件卡得死死的，最后全靠引导项切换这一招脱困。

6. 绕不开的另一道坎：关闭 VBS 后依然报错的排查方向

如果你按照上面的步骤全部操作完，重启后 VMware 还是报错，那就需要往更深一层排查了。我总结了三个概率较高的隐藏因素。

6.1 注册表残留的 Device Guard 策略

关闭 VBS 后，注册表里可能残留一些 Device Guard 相关策略，导致下一次系统启动时又自动触发 Hypervisor。检查以下路径：

HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard HKLM\SYSTEM\CurrentControlSet\Control\Lsa

在Lsa键下面，找到LsaCfgFlags、RunAsPPL等键值，确认它的值是否为0。如果之前用组策略开启过 Credential Guard，LsaCfgFlags的值可能是1或2。你可以手动改成0，或者直接删除这些键。改注册表前记得导出备份。

其实更稳妥的做法是使用组策略编辑器（gpedit.msc）：

计算机配置 → 管理模板 → 系统 → Device Guard → 打开基于虚拟化的安全性

把它设为“已禁用”，然后强制更新组策略：

gpupdate /force

这个方法比手工改注册表更干净，不会留下后遗症。

6.2 平台安全功能入口被隐藏

Windows 10/11 的“设备安全性”页面里，如果“内核隔离”下面的功能灰显不可操作，通常是因为组策略锁定了。这种情况在 OEM 品牌机上非常常见，厂商预置了安全策略，用户无法在界面里关闭。

解决路径还是登到组策略编辑器：

计算机配置 → 管理模板 → 系统 → Device Guard → 启用基于虚拟化的安全性

设为“已禁用”，然后重启。这一步做了之后，VBS 大概率会被彻底关停。

6.3 虚拟机镜像本身的问题

排除宿主机因素之后，如果新建一个空白虚拟机还是报错，那问题就转移到了虚拟机配置上。打开虚拟机的.vmx文件，检查是否有这几行：

vhv.enable = "TRUE" hypervisor.cpuid.v0 = "FALSE"

如果虚拟机是之前从别的机器拷贝过来的，这些配置项可能会残留。vhv.enable是嵌套虚拟化开关，如果宿主机已经不支持嵌套，开启它反而导致启动失败。你可以尝试把vhv.enable改成FALSE，或者删掉这几行，让 VMware 用默认逻辑重新识别硬件。

修改.vmx文件前确认 VMware 已经完全退出，否则保存后会被覆盖。

7. 最后聊几句实测感受

我前后折腾这个问题不下十次，从最早的 VMware 15 一直到现在 Workstation Pro 17，踩过的坑总结下来就一句话：先看清楚自己的核心需求，再决定是“关”还是“切”，不要盲目跟风关系统功能。

如果你只是普通用户，日常用 VMware 跑个 Linux 虚拟机、装个软路由测试，那就果断关闭 Hyper-V 和 VBS，换来的是最稳定、最接近物理机的体验。如果你是开发人员，Docker 和虚拟机两手都要抓，那就老老实实做双引导项，或者在 VMware 里切换 WHP 模式，各退一步获取共存空间。

另外，务必养成一个习惯：修改任何系统引导或安全配置前，先做一次系统还原点。Windows 的还原点虽然不是什么万能灵药，但在这种涉及底层引导的改动中，它可能是你最后的后悔药。

按照“关内核隔离 → 关 Hyper-V 功能 → bcdedit 关闭 hypervisorlaunchtype → 重启 → systeminfo 复验”这条链路走下来，绝大多数机器都能解决 VMware 不兼容的问题。如果你照着做完了仍没解决，再回头检查一遍注册表和组策略的残留项，基本不会再有漏网之鱼。