ARTICLE · INTELLIGENCE

战地情报 · 详情页

来自尧图项目组的一线实战观察与深度解析

VMware与Hyper-V/VBS冲突解决:彻底关闭Device/Credential Guard指南

VMware与Hyper-V/VBS冲突解决:彻底关闭Device/Credential Guard指南 平时做虚拟化调试的朋友对下面这行红底白字的报错肯定不陌生VMware Workstation 与 Device/Credential Guard 不兼容。禁用 Device/Credential Guard 后可以运行 VMware Workstation。我早些年被这个弹窗坑过好几次明明 Windows 功能里连 Hyper-V 的勾都没打重启完照样报错一度以为是 VMware 安装包坏了。后来把 Windows 10 的底层虚拟化机制翻了个底朝天才算彻底弄明白真正卡住 VMware 的不只是“Hyper-V 功能”本身而是 Windows 10 从系统启动阶段就拉起来的一套基于虚拟化的安全机制。这篇文章就把这个问题的来龙去脉、全部关闭步骤、验证方法和副作用一次讲透适合被 VMware 报错折腾过的用户、工控仿真开发、嵌入式调试以及经常在 VMware 和 Docker/WSL 之间切换的朋友。1. 先搞清楚报错背后的机制再动手关1.1 报错到底是谁在“打架”很多人的第一反应是我没装 Hyper-V、也没建过虚拟机为什么 VMware 还说不兼容这里很容易混淆两个概念一个是 Hyper-V 角色可选功能另一个是 Windows 10 的基于虚拟化的安全VBSVirtualization-Based Security。VBS 是 Windows 10 在启动阶段由 bootmgr 引导的底层安全机制Device Guard 和 Credential Guard 都构建在它之上。VBS 想正常工作必须让 Windows 的Hyper-V hypervisor虚拟机监控程序先于内核加载也就是说即使你根本没碰过“启用或关闭 Windows 功能”里的 Hyper-V 条目只要 VBS 被打开系统底层照样会启动一个 hypervisor。VMware Workstation 自己也是一个 hypervisor它需要直接访问 CPU 的 VT-x/AMD-V 虚拟化扩展来运行虚拟机。一旦 Windows 先启动了自己的 Hyper-V hypervisorVT-x 扩展就被底层占住了VMware 只能识别到“虚拟化能力被占用”于是干脆拒绝运行。这就是报错里“Device/Credential Guard 不兼容”的真实原因本质上是在抢 CPU 的虚拟化控制权。有个很迷惑人的细节VBS 和 Hyper-V 功能组件虽然都依赖 hypervisor但它们可以独立存在。系统里“Hyper-V”功能完全卸载了VBS 照样可以把 hypervisor 拉起来所以当你只做“关闭 Windows 功能里的 Hyper-V”这一步重启后大概率还是看到同一个报错。1.2 先判断这台机器到底开了哪些虚拟化安全功能动手关之前我建议先做一次“体检”确定你的机器被哪一层机制卡住了。最简单的办法是 WinR 打开运行框输入msinfo32回车在系统信息窗口里找一个叫“基于虚拟化的安全性”的字段。常见状态有三种未启用说明 VBS 没开如果这时 VMware 还报错问题多半出在“Windows 功能”里勾了 Hyper-V或者启用了“虚拟机监控程序平台”等选项。已启用但未运行配置上开了 VBS但当前会话里 hypervisor 没跑。这种情况对 VMware 的干扰相对小不过最好也清理干净。正在运行这是最麻烦的状态说明 hypervisor 已经加载VBS 或 Credential Guard 正在工作。你需要按后文步骤逐一关闭。除了系统信息Windows 安全中心里也藏着一个关键开关Windows 安全中心 → 设备安全性 → 内核隔离 → 内存完整性。这个“内存完整性”就是 VBS 的 HVCIHypervisor-protected Code Integrity一旦打开它也会强制 hypervisor 随系统启动。很多电脑出厂时就默认开了内核隔离这一步往往才是 VMware 报错的大头。2. 动手前先选路线临时关、永久关、不关也能用2.1 三种方案对比关闭操作不是只有一种方式我建议你先判断自己的使用场景再决定走哪条路。方案操作内容适用场景优点缺点临时关闭 hypervisor 启动使用bcdedit /set hypervisorlaunchtype off偶尔用一次 VMware之后还想用 Docker/WSL2一条命令恢复对系统改动最小如果 VBS 组策略还开着重启后可能被再次打开彻底关闭 VBS / Device Guard / Credential Guard关闭内核隔离、组策略、注册表联动长期以 VMware 为主不需要 WSL2 和沙盒一劳永逸不会再被底层抢占后续要用 WSL2、Docker 桌面版时得重新开启不关 Hyper-V用 WHP 模式运行 VMwareVMware Workstation 15.5.5 配合 Windows Hypervisor Platform必须在 WSL2 和 VMware 之间来回切换不用关底层重启一次即可两边共存性能比直接使用 VT-x 差部分嵌套虚拟化功能受限方案一适合那种“今天要跑一个 VM明天还要用 Docker”的状态因为你随时可以用bcdedit /set hypervisorlaunchtype auto恢复原状。方案二适合工作内容基本绑死在 VMware 上的用户比如我的实际场景平时主要调试虚拟机、跑不同 Linux 发行版很少碰 Docker那我就会选择彻底关掉 VBS。方案三则是新版 VMware Workstation 官方支持的共存路线后面单独说。2.2 不关 Hyper-V 的替代思路让 VMware 走 WHP如果你不想关闭 Hyper-V也别急着按老办法硬关。VMware Workstation 15.5.5 之后的版本以及现在的 Workstation 16/17都支持通过Windows Hypervisor PlatformWHP在启用了 Hyper-V 的 Windows 系统上运行。原理是VMware 不再直接访问 VT-x而是通过 Windows 提供的 WHP API 借用 hypervisor 的能力来执行虚拟机。好处很明显你不需要改动系统底层的 hypervisor 启动设置WSL2、Docker Desktop、Windows 沙盒都能继续用。坏处也很直接多了一层中间调用CPU、内存、磁盘 I/O 的虚拟化路径变长实测下来虚拟机的磁盘吞吐和网络性能会明显下降某些对硬件虚拟化指令集敏感的工作负载比如嵌套虚拟化、部分内核调试和硬件直通实验也容易碰壁。所以我的判断是轻度使用或者只是临时跑个虚拟机测试WHP 模式可以用。但如果你要靠 VMware 跑大型构建、内核编译、游戏系统或者复杂的网络实验还是老老实实把 Hyper-V/VBS 关掉让 VMware 直接接管 VT-x 更稳。3. 超详细实操一步一步关掉冲突源下面这套流程我排过很多遍兼容性最好也能覆盖大部分人的机器。你不需要每一步都做按顺序检查到哪一步发现 msinfo32 显示“未启用”了就可以停手。3.1 第一步关闭 Windows 功能里的 Hyper-V 相关组件进入控制面板 → 程序和功能 → 左侧“启用或关闭 Windows 功能”在弹出的 Windows 功能窗口里找到Hyper-V把勾选全部取消。如果看到“虚拟机平台”和“Windows 虚拟机监控程序平台”这两个选项同样建议取消勾选它们也是常见的 VT-x 占用源。这里注意一点如果你后面想走 WHP 共存方案就不要取消“Windows 虚拟机监控程序平台”取消 Hyper-V 本身可以但这个平台必须保留否则 VMware 无法调用 WHP API。确认后系统会要求重启。很多教程到此为止就结束了实际上远远不够因为这台机器的 VBS 可能还在工作。所以这一步只能算开胃菜。3.2 第二步关闭安全中心里的“内核隔离 / 内存完整性”打开 Windows 安全中心 → 设备安全性 → 内核隔离把“内存完整性”的开关拨到关系统会再次提示重启。这是关闭 VBS 的最直接开关绝大多数家用电脑开启 VBS 都是因为这里默认打开了。如果你在设置界面里找不到这个开关说明它被组策略或注册表锁定了别慌继续看下面两步用组策略或注册表强制关效果一样。这一步操作完后建议重启一次再继续。因为内存完整性和 hypervisor 的加载属于系统启动阶段行为不重启不会生效。3.3 第三步用 bcdedit 关闭 hypervisor 自启动这是最核心的一步。右键开始菜单打开“Windows PowerShell管理员”或“命令提示符管理员”执行bcdedit /set hypervisorlaunchtype off如果你用的是较早的 Windows 10 版本或者系统里存在 Virtual Secure Mode 残余配置可能还要再执行一条bcdedit /set vsmlaunchtype off如果系统提示“设置元素数据时出错”或者“找不到指定的元素”直接忽略即可说明你的引导配置里没有这个项目不影响结果。这条命令做的事情是告诉 Windows 引导加载器下次启动时不要再自动拉起 hypervisor。注意它只影响 hypervisor 的启动行为本身不会卸载 Hyper-V 功能所以以后你想恢复只要管理员命令窗口执行bcdedit /set hypervisorlaunchtype auto就可以让 hypervisor 重新跟随系统启动非常方便。3.4 第四步用组策略和注册表禁用 Device Guard / Credential Guard如果你的系统是专业版、企业版或教育版可以用组策略关闭。WinR 输入gpedit.msc回车依次展开“计算机配置 → 管理模板 → 系统 → Device Guard”部分中文系统显示为“设备保护”右侧找到“打开基于虚拟化的安全性”双击改为“已禁用”。如果同一界面下还有“已启用 Credential Guard”的策略项也一并以禁用处理。家庭版没有组策略编辑器就用注册表方式。打开注册表编辑器定位到HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceGuard在右侧新建或修改一个 DWORD 值名称为EnableVirtualizationBasedSecurity数值设为0。继续定位到HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\CredentialGuard把Enabled的值改为0。有些机器没有Scenarios\CredentialGuard这个子键手动新建“CredentialGuard”项再建 DWORD 即可。需要注意如果你的电脑是企业批量部署或者有安全策略统一下发本地组策略和注册表改完后可能过一段时间又被安全中心自动改回来。遇到这种情况就要考虑是不是有其他策略强制打开 VBS。没有统一管理环境的话一般不会这么顽固。3.5 第五步重启验证确认 VMware 恢复正常所有设置完成后重启电脑。再次打开msinfo32看“基于虚拟化的安全性”字段是否变成“未启用”。这里有个细节如果显示“已启用但未运行”你也别慌这说明策略层面还留有配置但当前 hypervisor 没加载VMware 基本可以正常运行。确认系统信息干净后启动 VMware Workstation随便打开一台之前报错的虚拟机。我习惯先把虚拟机的 CPU 设置里“虚拟化 Intel VT-x/AMD-V”选项打开再开机测试。如果虚拟机正常进入系统说明 VT-x 已经被 VMware 接管问题解决。4. 关完之后遇到的问题看这里排查4.1 典型问题速查表我把这些年处理 VMware/Hyper-V 冲突时遇到的典型问题整理成了速查表按“现象 → 可能原因 → 解决办法”排序建议收藏备用。现象可能原因排查与解决办法重启后 VMware 依然报错不兼容VBS 没有真正关闭打开 msinfo32 看“基于虚拟化的安全性”关闭安全中心“内存完整性”检查组策略“打开基于虚拟化的安全性”是否为“已禁用”hypervisorlaunchtype off 命令执行后重启被还原组策略或安全中心策略强制开启检查组策略 Device Guard 项检查注册表EnableVirtualizationBasedSecurity是否被改回 1家庭版没有 Hyper-V 选项也打不开 gpedit系统版本限制但 VBS 可能默认开启直接用注册表方式和 bcdedit 命令不影响效果关闭后 WSL2 或 Docker Desktop 无法启动WSL2 依赖 Hyper-V hypervisor暂时需要 WSL2 时执行bcdedit /set hypervisorlaunchtype auto恢复或改用 WHP 模式运行 VMwareVMware 虚拟机内系统运行明显变卡走了 WHP 中间层或仍残留 hypervisor确认没有勾选“Windows Hypervisor Platform”后端彻底关闭 VBS 后对比性能系统热更新后问题复发Windows 的安全基线策略重新开启了 VBS再次检查组策略和注册表确认无策略强推TwinCAT/PLCsim Advanced 等软件报 0x1024 错误这些软件要求 Hyper-V 处于开启状态按当前主业开/关 hypervisor两套需求不可同时满足时只能切换4.2 几个我踩过的坑和心得第一只关 Windows 功能的 Hyper-V然后不关内核隔离这是最多人走过的弯路。我最早在一台 ThinkPad 上折腾了一整天就是因为忽略了“内存完整性”开关。现在我的固定排查顺序是先看安全中心内核隔离再看 msinfo32 确认状态最后才动 bcdedit 和组策略。第二bcdedit 命令执行时机有讲究。我习惯在关闭 Hyper-V 功能、关闭内核隔离之后再执行 bcdedit重启一次而不是每次改一项就重启。一次重启把所有配置吃进去省时间也能观察到冲突是否被彻底清理。第三内存完整性开关和 bcdedit 的关系容易搞混。内存完整性是 HVCI它一旦开启会强制 hypervisor hook 内核所以它本质上和 hypervisorlaunchtype 是两条控制路径。我见过有人只关内存完整性、不执行 bcdedit重启后 msinfo32 依然显示“正在运行”就是因为 hypervisorlaunchtype 还是 auto。第四新版 VMware Workstation 17 在安装时如果检测到 Hyper-V 处于开启状态会默认启用“Windows Hypervisor Platform”支持。如果你后来把 Hyper-V/VBS 关了但 VM 设置里还保留着 WHP 后端虚拟机可能启动报错。这种时候在虚拟机设置里把“基于 Windows Hypervisor Platform 运行”取消勾选再试试。5. 必要的提醒关闭 Hyper-V 后哪些功能会跟着受影响5.1 WSL2、Docker Desktop、Windows 沙盒都不能用了关闭 Hyper-V、并把 hypervisorlaunchtype 设为 off 之后系统底层 hypervisor 不再加载等于把整个“虚拟化底座”拿掉了。受影响最大的是 WSL2WSL2 从架构上就依赖 Hyper-V 的轻量级虚拟机hypervisor 没了WSL2 直接起不来WSL1 不受影响。Docker Desktop 如果走的是 WSL2 后端同样会罢工。Windows 沙盒Windows Sandbox也依赖 Hyper-V 组件关闭后沙盒功能会报错。如果你平时经常用沙盒来测试可疑文件关闭 Hyper-V 之前一定要想清楚别解决了一个 VMware 报错又给日常使用添了新堵。我的解决思路是把这套开关流程做成两套“预设”需要 VMware 干活时执行bcdedit /set hypervisorlaunchtype off需要 Docker/WSL 时执行bcdedit /set hypervisorlaunchtype auto配合重启五分钟切换一次。虽然麻烦但比在两种需求间反复安装卸载功能靠谱得多。5.2 我的建议按使用场景决定要不要彻底关如果你 90% 的虚拟化诉求都在 VMware 上而且短期内不碰 WSL2 和 Docker那放心大胆地按文章里的方案彻底关掉 VBS体验是“从报错到一路顺畅”。如果你需要在 VMware 和 WSL2 之间频繁切换我更建议用新版 Workstation 的 WHP 共存模式让一步性能换便捷。如果你只是偶尔打开一次 VM那临时bcdedit /set hypervisorlaunchtype off就够了完全没必要动组策略和注册表。根据我的实操经验绝大多数机器走到 3.3 步bcdedit 命令就已经能让 msinfo32 显示“未启用”。走到组策略和注册表那一步的通常都是系统安全中心策略比较顽固或者做过企业安全加固的机器。所以别一开始就把所有方法全部执行先做最小改动验证后不够再追加这样对系统影响最小出问题时也容易回头排查。
RELATED READING

延伸阅读

更多一线实战笔记与深度复盘,助您持续精进