企业官网建设流程全解析

碰到那个提示的人，十有八九都是同一个表情——昨天VMware Workstation还用得好好的，今天开机就给我整这出：您的主机不满足在启用 Hyper-V 或 Device/Credential Guard 的情况下运行 VMware Workstation。点确定之后虚拟机直接罢工，连电源键都是灰的。有人一气之下重装了三次Win10，装完VMware照样报错，后来才发现根本不是系统坏了，是Win10在后台偷偷把虚拟化相关的安全功能拉起来了。这篇文章就把这个问题拆开揉碎讲清楚：Hyper-V和Device/Credential Guard到底是怎么影响VMware的，有哪些办法能彻底关掉，以及关不干净的时候该怎么一步步排查。不管你是刚碰VMware的新手，还是已经被这个报错折磨几天了，照着下面的顺序走一遍，大概率能救回来。

1. 问题本质：为什么Hyper-V和VMware Workstation水火不容

1.1 报错的完整表达和触发场景

VMware Workstation这个报错的完整弹窗信息比标题里那段还长，大意是检测到主机启用了Hyper-V或Device/Credential Guard，然后拒绝了虚拟机的启动。注意它说的是"不满足运行条件"，不是"虚拟机文件损坏"，也不是"许可证失效"，说明VMware检测到的是底层虚拟化资源被占用了。

触发这个报错的场景，我整理过，最常见的有这么几类：

• 之前为了用WSL2，按照微软官方教程勾选了"虚拟机平台"和"Windows虚拟机监控程序平台"，装完之后WSL2能用，但VMware开始闹脾气。
• 为了跑Docker Desktop，装的时候它会在Windows功能里把Hyper-V相关组件一并打开，之后VMware就再也起不来虚拟机。
• 电脑是品牌机预装的Win10，厂商在系统镜像里默认开启了内核隔离和内存完整性，用户自己根本没碰过任何虚拟化设置。
• 系统自己更新到Win10 21H2以上版本，部分新安装或重置过的系统默认把基于虚拟化的安全（VBS）开着。
• 试过Windows沙盒，用完忘了关。

很多人觉得，我又没主动装Hyper-V，凭什么报这个错？问题就出在Win10把Hypervisor（虚拟机监控程序）当成了很多"安全功能"的底座，你不装Hyper-V，不代表Hypervisor不在后台启动。

1.2 Hyper-V为什么会跑到你机器上

Hyper-V是微软自家的虚拟机方案，以一个Windows可选功能的形式存在。它和VMware Workstation这种桌面级虚拟机软件最大的区别在于：Hyper-V是Type 1虚拟机监控程序，跑起来之后直接坐在硬件和Windows之间，CPU的硬件虚拟化扩展（Intel VT-x或AMD-V）会被它独占。

VMware Workstation是Type 2虚拟机，它依赖的操作是让Windows宿主系统能直接调用硬件虚拟化指令。一旦Hypervisor已经先占住那一层，VMware再去申请就会碰壁，于是干脆弹窗拒绝运行。这个逻辑用大白话讲就是：Hypervisor像一个先上车的乘客，把车门堵住了，VMware只能站在车外干瞪眼。

有个很容易被忽略的点：Hyper-V未必是你手动开的功能。WSL2、Windows沙盒、Windows安全中心里的"内核隔离"，甚至某些品牌机预装的优化软件，都会在系统后台把Hyper-V的底层组件带起来。你打开"启用或关闭Windows功能"一看，咦，Hyper-V那个勾是灰的或者根本没勾，但Hypervisor已经悄悄在跑了。这也是为什么单纯在功能列表里取消勾选，往往解决不了问题。

1.3 Device/Credential Guard：更隐蔽的"隐形开关"

Device Guard和Credential Guard这对组合，微软给它的定位是"基于虚拟化的安全"（VBS，Virtualization-Based Security）。具体干的事是把Windows的代码完整性校验、LSASS进程隔离这些敏感功能，放进一个用Hypervisor隔离出来的安全内存区域里运行。听起来确实很安全，但它有一个前提条件：必须先把Hypervisor拉起来。

也就是说，哪怕你在"启用或关闭Windows功能"里一个虚拟机相关的勾都没打，只要VBS开着，Hypervisor照样会随系统启动。这就是很多人踩坑的根源——关了半天Hyper-V，发现Device/Credential Guard还在后台撑腰，VMware照样不认账。

还有一个概念叫内存完整性（Memory Integrity），在Win10安全中心里显示为"内核隔离"下的一个开关，底层就是基于Hypervisor的代码完整性检查（HVCI）。这个东西在近几年的Win10版本里越来越普及，新装机或者重置系统后经常默认开启。它也是导致VMware和Hyper-V不兼容的大户。所以你遇到的报错，表面上写着Hyper-V或Device/Credential Guard，实际上一张完整的排查清单还要把VBS、HVCI、内核隔离、内存完整性都算进去。

2. 第一阶段：先关掉能看到的Hyper-V

2.1 关闭Windows功能里的Hyper-V全家桶

先从最直观的开关下手。按Win+R，输入optionalfeatures，回车，打开"启用或关闭Windows功能"对话框。

在这个列表里需要检查的项目不止Hyper-V一项，我的习惯是全部过一遍：

• Hyper-V：如果勾选了，取消。
• 虚拟机平台（Virtual Machine Platform）：取消。
• Windows虚拟机监控程序平台（Windows Hypervisor Platform）：取消。
• Windows沙盒（Windows Sandbox）：如果勾选了，取消。
• 适用于Linux的Windows子系统：如果不用WSL，建议一并取消。

点确定后系统会进入配置界面，提示重启就重启。

这个操作的本质是移除Hyper-V的"用户态组件"，也就是Hyper-V管理器、虚拟机监控程序服务、网络虚拟化服务这些对普通用户可见的部分。但注意，它未必能干掉Hypervisor本身。很多文章写到这里就结束了，实际操作下来你会发现问题远远没完。

2.2 禁用三个Hyper-V后台服务

重启之后如果你仍然怀疑Hyper-V残留，可以打开服务管理器（Win+R输入services.msc），按H键定位到Hyper-V开头的服务。比较常见的几个：

• Hyper-V Host Compute Service（vmms）：虚拟机的核心管理服务。
• Hyper-V Virtual Machine Management（vmcompute）：虚拟机计算服务。
• Hyper-V Networking Management Service：虚拟网络管理服务。
• Hyper-V Data Exchange Service、Hyper-V Guest Service Interface、Hyper-V Remote Desktop Virtualization Virtual Machine：这些属于辅助服务，一般随着主功能关闭也会消失，但偶尔会有残留。

操作方式很简单：双击服务，启动类型改成"禁用"，如果当前状态是"正在运行"，先点停止，然后确定。

这里有个经验之谈：单纯禁用服务，对解决VMware报错的作用非常有限。因为Hypervisor的启动时机比这些服务早得多，是Windows引导阶段就决定的事。服务禁用只能防止Hyper-V相关组件被唤醒，真正决定Hypervisor是否加载的，是下一章要讲的引导项。

2.3 已经关了但报错仍在？这才是常态

如果你按照前面两步操作完，满心欢喜打开VMware，大概率还是会看到同一个报错。别慌，这不是你操作错了，而是问题的核心还没动到。

从Win10 1607版本开始，Microsoft把Hypervisor的启动独立成了一个引导项，叫hypervisorlaunchtype。只要这个值不是off，Windows在开机时就会尝试把Hypervisor加载进内存。而且这个引导项的开关和"启用或关闭Windows功能"里的勾选是两套逻辑：功能列表里没勾Hyper-V，不代表引导项会自动变off；反过来，引导项开着的状态下，即使你看到的Windows功能列表干干净净，Hypervisor照样在跑。

这也是为什么网上很多教程会说"关Hyper-V要用命令"，而不是只教你勾取消。走到这一步，CMD窗口该上场了。

3. 第二阶段：用命令行彻底断掉Hypervisor

3.1 bcdedit：关闭hypervisorlaunchtype

这是整个关闭流程里最关键的一步。用管理员身份打开命令提示符（右键开始菜单，选择"终端(管理员)"或"命令提示符(管理员)"），执行：

bcdedit /set hypervisorlaunchtype off

看到"操作成功完成"的提示后，重启电脑。重启后再看VMware，报错通常已经消失。

如果之后想恢复Hyper-V，或者你还要用WSL2、Docker Desktop，把off改回auto即可：

bcdedit /set hypervisorlaunchtype auto

想确认当前值，可以用：

bcdedit /enum {current}

在输出信息里找到hypervisorlaunchtype这一行，看到Off就是已经关闭，Auto就是还在开。我自己的习惯是改完命令后顺手执行一次查看命令，确认真的写进去了，避免重启之后才发现没生效。

这里要提醒一句：bcdedit操作的是系统引导配置数据，改错有进不去系统的风险。虽然hypervisorlaunchtype这个项非常安全，但无论如何，操作前把重要资料备份一下总没错。

3.2 DISM：把Hyper-V组件连根拔掉

如果你已经确定以后完全不会再用Hyper-V，也不想让它再占用任何系统资源，可以用DISM把Hyper-V组件整体卸载掉。管理员CMD里执行：

dism.exe /Online /Disable-Feature /FeatureName:Microsoft-Hyper-V-All /NoRestart

这个命令会一次性把Hyper-V的所有功能组件标记为禁用，包括平台、管理工具、PowerShell模块等。加上/NoRestart参数是不想它立刻重启，你可以等其他配置都改完再一次性重启。

不过说实话，DISM这一步对于解决VMware报错来说，不是必须的。因为bcdedit把hypervisorlaunchtype设成off之后，Hypervisor已经不加载了，VMware就能正常工作。DISM更大的意义在于清理磁盘空间、减少系统服务驻留、让"启用或关闭Windows功能"里不再出现Hyper-V的影子。如果你有洁癖，或者实在搞不清到底系统里还有多少Hyper-V残留，可以执行一次。

3.3 两条验证命令看懂当前状态

关闭工作做没做到位，不能靠感觉，要看输出。除了前面说的bcdedit /enum {current}，系统里还有两个自带工具可以验证：

第一条是systeminfo。管理员CMD执行：

systeminfo

在输出末尾找到"Hyper-V 要求"这一段。正常情况下应该显示：已检测到虚拟机监控程序。将不显示 Hyper-V 所需的功能。或者类似信息。还有一种情况是直接提示找不到Hyper-V，说明组件已经被彻底移除。同时留意"基于虚拟化的安全"这一行，如果显示"正在运行"，说明VBS还在生效，需要进入第四阶段的处理。

第二条是msinfo32。直接在运行框里输入msinfo32，打开系统信息，在"系统摘要"右侧找"基于虚拟化的安全性"这一项。如果显示"未启用"，恭喜你，最麻烦的那部分已经处理完了；如果显示"已启用"且后面的括号里写着"未运行"，说明策略开了但Hypervisor没在跑，这种情况VMware也能正常工作。

4. 第三阶段：收拾Device/Credential Guard这套隐藏BOSS

4.1 组策略：关闭基于虚拟化的安全

前面提到，Device Guard和Credential Guard底层靠VBS支撑，所以要治本，就得把VBS关掉。Win10专业版、企业版、教育版可以用组策略编辑器操作。

Win+R输入gpedit.msc，回车，然后依次展开：

计算机配置 → 管理模板 → 系统 → Device Guard

右侧找到"打开基于虚拟化的安全"，双击打开，改成"已禁用"，确定。

这一步的作用是告诉Windows：不要再启动任何基于虚拟化的安全功能。改完同样需要重启。

注意，Win10家庭版没有gpedit.msc这个工具，双击运行会提示找不到。家庭版用户直接跳过这一节，用下一节的注册表方法即可。另外，如果你打开组策略后根本没看到Device Guard这个文件夹，说明系统组件缺失或版本精简过，也走注册表路线。

4.2 注册表：彻底干掉Device Guard和Credential Guard

注册表是最后的手段，也是覆盖版本最全的手段。Win+R输入regedit，回车，依次检查以下三个位置。

位置一：Device Guard的VBS总开关。

路径：HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceGuard

右侧找EnableVirtualizationBasedSecurity这个DWORD（32位）值，把数值数据改成0。如果没有这个值，右键新建 → DWORD（32位）值，命名成EnableVirtualizationBasedSecurity，数值填0。

位置二：内核隔离/HVCI的内存完整性开关。

路径：HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity

右侧找Enabled这个DWORD值，改成0。同样，没有就新建。

位置三：Credential Guard的LSASS隔离开关。

路径：HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa

右侧找LsaCfgFlags这个DWORD值，改成0。没有就新建。

这三个地方改完，重启系统，VBS相关的几大件基本就全关了。我建议在改注册表之前，右键对应的键，选择"导出"，把原始状态备份成一个.reg文件，万一要恢复，双击导入就回去了。

4.3 Windows安全中心的"内存完整性"别忘了关

注册表改完之后，还有一个入口容易被忽略：Win10自带的安全中心。

打开Windows安全中心 → 设备安全性 → 内核隔离 → 内存完整性。如果这个开关是开着的，把它关掉。

内存完整性就是HVCI在用户界面层的开关，和注册表里那个HypervisorEnforcedCodeIntegrity的Enabled值是对应的。如果你在4.2里已经把注册表值改成0，这里通常会显示"已关闭"；但反过来，如果只在这里关了开关，注册表里的值不一定同步变成0。所以实操时我会两头都检查一遍，确保状态一致。

Win10 21H2之后的版本，很多OEM预装系统或重置后的系统，内存完整性默认是开启的。这也是为什么有人全新安装完系统，刚装好VMware就报错，因为根子就在这。

4.4 LTSC这类特殊版本没得选怎么办

Win10 LTSC 2021这个版本比较特殊。它是企业长期服务版，系统精简掉了不少东西，Windows安全中心里的"设备安全性"页面经常是空的，没有内核隔离开关；组策略里也可能没有Device Guard条目。遇到这种情况，注册表那套方法就是唯一正路。

直接按照4.2的三个路径手动建DWORD、改值，然后执行一次：

bcdedit /set hypervisorlaunchtype off

重启之后，用msinfo32确认"基于虚拟化的安全性"变成"未启用"，问题就解决了。

顺带提一下Win11。如果你是Win11遇到类似的VMware报错，思路完全一样：Windows功能里关Hyper-V相关项，bcdedit关hypervisorlaunchtype，安全中心关内存完整性，VBS用注册表或组策略关。Win11的内核隔离入口也在Windows安全中心里，路径和Win10几乎一致。

5. 组合拳实操全过程（实测完整的关闭顺序）

5.1 一份从头到尾的可复制操作清单

很多人看完前面的原理，动手时容易乱。这里给一份我实测过多次的完整操作顺序，按这个顺序来，基本不会漏。

第一步，Win+R运行optionalfeatures，取消勾选Hyper-V、虚拟机平台、Windows虚拟机监控程序平台、Windows沙盒（如果不需要），确定后重启一次。

第二步，用管理员身份打开CMD，依次执行：

bcdedit /set hypervisorlaunchtype off

第三步，如果确定以后不用Hyper-V，再执行：

dism.exe /Online /Disable-Feature /FeatureName:Microsoft-Hyper-V-All /NoRestart

第四步，Win+R运行gpedit.msc，修改"打开基于虚拟化的安全"为"已禁用"（仅Pro及以上版本）。

第五步，Win+R运行regedit，把4.2节提到的三个注册表值全部改成0，没有就新建。

第六步，打开Windows安全中心，关掉"内存完整性"开关（如果页面里有）。

第七步，如果担心服务残留，再进services.msc把Hyper-V相关服务禁用一遍。

第八步，重启电脑。

第九步，用systeminfo和msinfo32验证Hypervisor和VBS的状态。

第十步，打开VMware Workstation，启动一台虚拟机测试。

这套流程走完，99%的报错都能解决。剩下的1%，多半是BIOS里还有虚拟化安全选项在捣乱。

5.2 重启后怎么验证VMware真的能跑了

重启之后，先别急着灌系统跑大业务，按下面三步验证：

先用msinfo32确认"基于虚拟化的安全性"是"未启用"状态，再用systeminfo看一眼Hyper-V要求段落，确认没有"虚拟机监控程序"处于运行状态。这两个都过了，基本就稳了。

然后打开VMware Workstation，随便选一台虚拟机，点"开启此虚拟机"。如果之前卡在报错界面，现在应该能正常走启动进度条。我习惯先启动一台轻量级的Linux虚拟机做快速验证，能进桌面、响应流畅就算过了。

最后在虚拟机里跑一个稍微吃CPU的任务，比如系统更新或者编译一点小东西，同时开着宿主机任务管理器观察CPU占用。如果宿主机CPU频率能正常提升，虚拟机内部运行流畅，说明硬件虚拟化资源已经完全归VMware调度。

5.3 我踩过的坑：最容易翻车的几个环节

坑一：只关了Windows功能里的Hyper-V，没关hypervisorlaunchtype。这是最普遍的情况，你以为关了，实际上Hypervisor还在跑，报错自然还在。

坑二：关掉了VBS之后，Windows Hello、PIN码登录可能失效。这个在重启后会直接遇到，提示"由于此设备上的安全设置已更改，请重新设置PIN"。这不是故障，是VBS关闭后的正常现象，按提示重新设置一次就行。

坑三：Docker Desktop和WSL2会跟着一起瘫掉。这俩都依赖Hypervisor，hypervisorlaunchtype设成off之后，WSL2子系统起不来，Docker也打不开。如果你日常要用这些，要么用VMware Workstation 15.5.5以上版本配合Windows Hypervisor Platform共存运行，要么就别关Hyper-V，二选一。

坑四：某些主板BIOS里有与虚拟化安全相关的选项，比如Intel的VT-d、Trusted Execution Technology，或者一些品牌机特有的"Virtualization Based Security"选项。软件层面全关了，但BIOS还强制开启，会导致状态不确定。必要时候进BIOS把这些选项也关掉。

坑五：Windows大版本更新偶尔会把hypervisorlaunchtype悄悄改回auto。遇到过几次，系统更新完VMware突然又报错，一查bcdedit果然被改回去了。所以更新系统后如果VMware异常，先把引导项检查一遍。

6. 常见问题与排查技巧实录

6.1 高频问题速查表

把这些年遇到的典型情况整理成一张表，方便你按症状快速定位：

6.2 排查思路：还是报错就往这几个方向查

如果你把前面所有能关的都关了，重启之后VMware依然报错，按下面这个顺序继续深挖。

第一步，重新打开msinfo32，看"基于虚拟化的安全性"这一行。如果还是"已启用"，说明有东西强制拉起了VBS，直接跳到注册表三个键值逐一确认，一个都别漏。

第二步，用PowerShell执行：

Get-CimInstance -ClassName Win32_DeviceGuard

看输出里的SecurityServicesRunning字段。如果里面有值，说明VBS相关的安全服务在运行；如果值是0或者空，基本就是关了。

第三步，查看事件查看器。Win+R输入eventvwr.msc，展开Windows日志 → 系统，过滤Hyper-V和Hypervisor关键字，看有没有相关的错误或信息事件。有时候能直接看到是哪个组件触发了Hypervisor启动。

第四步，检查Windows功能列表，重新打开optionalfeatures，看看有没有什么不该勾的东西自己勾上了。尤其是Windows沙盒和虚拟机平台这两个，经常被其他软件自动打开。

第五步，如果以上都查了还是没结果，进BIOS清一次安全启动和虚拟化设置。办法是把Intel VT-x/AMD-V关闭，保存重启进系统，再关机进BIOS重新打开。这个操作本质是让CPU的虚拟化状态重置一遍，偶尔能解决一些顽固残留。

6.3 什么情况下其实不该关Hyper-V

不是所有报错都适合用"关闭Hyper-V"来解决。如果你日常依赖这些东西，关掉之前先想清楚：

• WSL2。Linux子系统重度用户基本离不开，它的第二代架构就是跑在Hypervisor上的。
• Docker Desktop。Windows版Docker Desktop默认用的是WSL2后端，同样依赖Hypervisor。
• Windows 沙盒。一个临时桌面环境，功能上和虚拟机没区别，底层还是Hyper-V。
• 一些SDK自带的模拟器，比如某些嵌入式、移动开发环境，会直接调用Hyper-V的API。

如果你离不开这些，又必须用VMware Workstation，还有一条折中路：升级到VMware Workstation 15.5.5以上版本，然后在VMware里开启"使用Windows Hypervisor Platform"的兼容选项（软件设置里可以勾选）。这会让VMware跑在微软Hypervisor之上，代价是性能和嵌套虚拟化能力打折，但至少能启动虚拟机。

我的个人建议是：如果你主力是VMware，同时WSL2只是偶尔用用，那就关掉Hyper-V，WSL2临时要用的时候再开回来，虽然麻烦点，但VMware的完整性能和兼容性都能保住。如果你每天WSL2和Docker不离手，那不如把VMware的虚拟机迁移到Hyper-V里，省得两边打架。

最后再分享一个实测小技巧：改完所有配置后，不要急着关机走人，先在CMD里跑一遍systeminfo，确认Hyper-V要求那一段没有红色警告，再去启动VMware。有一次我改完注册表忘了确认引导项，结果重启后报错还在，一查是bcdedit命令没以管理员身份运行，根本没写进去。所以每一步做完都验证一下，比最后一次性排查省事得多。