如果你曾经在 Windows 10 上装过 Docker Desktop、WSL2、安卓模拟器，或者曾经手贱勾选过 Hyper-V，那下面这句英文提示你一定不陌生：
VMware Workstation and Device/Credential Guard are not compatible.
中文版更直白：“您的主机不满足在启用 Hyper-V 或 Device/Credential Guard 的情况下运行 VMware Workstation 的要求。”
我最早遇到这个问题时，屏幕上明明显示 VT-x 已在 BIOS 中开启，VMware 却死活不让我启动虚拟机。后来才知道，是 Windows 自己把虚拟化能力“吃干抹净”了。这个问题的本质，是微软的 Hyper-V、基于虚拟化的安全（VBS）、Device Guard、Credential Guard 这几位“邻居”和 VMware Workstation 抢占同一块 CPU 虚拟化资源，最后 VMware 抢不过，只能报错。
这篇文章我会把禁用 Hyper-V 的几种主流方法、判断依据、验证手段全部理清楚。不管你是为了跑 VMware Workstation，还是被 PLCSIM Advanced、TwinCAT 这类工业软件折磨过，只要你需要让这台 Windows 10 把虚拟化资源让给 VMware，这篇都能给你一条完整的操作路径。
1. 那个让人头疼的报错：到底是谁抢了 VMware 的地盘
1.1 报错出现的典型场景
这个报错出现的场景比我预期的要复杂得多，并不是只有“开了 Hyper-V 的人”才会中招。
我梳理一下自己遇到过和论坛里常见的几种触发方式：
- 手动开启过 Hyper-V：从“启用或关闭 Windows 功能”里勾选了 Hyper-V 相关组件，后来不用了但也没关。
- 安装过 WSL2：WSL2 要求开启“虚拟机平台”。这个功能面板里的选项叫 VirtualMachinePlatform，它同样会让 Windows 在启动时加载虚拟机监控程序。
- 安装过 Docker Desktop：新版 Docker Desktop 默认以 WSL2 为后端，安装时自动打开“虚拟机平台”。
- 企业电脑开启了 Device Guard / Credential Guard：办公本经常通过组策略和注册表打开基于虚拟化的安全，用户自己完全不知道。
- Windows 安全中心里打开了“内核隔离 - 内存完整性”：这是 Win10 自带的安全功能，本质上是 VBS（基于虚拟化的安全），同样占用虚拟机监控程序。
你在“Windows 功能”面板里看不到 Hyper-V 这个词，不代表你没有中招。尤其是 WSL2 场景，很多用户只是安装过 Linux 子系统，就莫名其妙被这个报错堵住。
1.2 Hyper-V、VBS、Credential Guard 到底是一家人还是两家人
要搞清楚为什么关闭 Hyper-V 不是唯一任务，得先明白这几个概念之间的包含关系。简单说：Hyper-V 是整个机制的底层基础设施。
当你在 Windows 功能里勾选 Hyper-V 后，Windows 启动时会首先加载一个叫 hypervisor（虚拟机监控程序）的底层组件。这个组件位于 Windows 内核之下，CPU 的 VT-x/AMD-V 硬件虚拟化能力会被它先行接管。此时 Windows 系统本体就成了跑在这个虚拟机监控程序上的一个“根分区”。
Credential Guard 和 Device Guard 听起来很高大上，本质上是“借用 Hyper-V 虚拟化能力来保护 Windows 的凭据和代码完整性”。它们的实现依赖 VBS，而 VBS 的底层还是 Hyper-V hypervisor。
所以，即使你在 Windows 功能里没勾“Hyper-V”这一项，只要你开启 VBS，系统照样会加载 hypervisor。这就是为什么“关掉 Hyper-V”这个说法其实不太准确，更准确的说法是：让 Windows 不再加载虚拟机监控程序，把 VT-x 释放给 VMware 直接使用。
1.3 为什么 VMware Workstation 抢不过 Hyper-V
VMware Workstation 本身是 Type 2 虚拟机软件，它运行在 Windows 之上，需要直接操作 CPU 的虚拟化指令集来做二进制翻译和硬件辅助虚拟化。
当 Hyper-V 处于激活状态时，CPU 的 VMX（虚拟化扩展）已经被 hypervisor 控制，Windows 系统本身都运行在 root 模式下。VMware Workstation 再去请求 VMX 资源时，只能通过 Windows 提供的接口，而不是直接访问硬件。
这里有个关键的版本差异。VMware Workstation 15.5.5 及以上版本加入了通过 Windows Hypervisor Platform（WHPX）接口运行的兼容模式，也就是说在开启 Hyper-V 的机器上也能跑。但很多老版本、企业内网定制版，或者某些物理机配置下，兼容模式依旧不稳定，最直接的解决办法仍然是“关掉 Hyper-V，让 VMware 走原生 VT-x 路径”。
所以你在搜索框里看到的大多数教程、论坛建议，都指向同一个方向：把 hypervisor 请出系统。
2. 动手之前先做个判断：你未必真的需要彻底关闭 Hyper-V
2.1 先检测当前 Hyper-V 是否真的在运行
我的建议是不要上来就改配置，先看现状。最简单的方法是打开“任务管理器”，切到“性能”选项卡，点击左侧的“CPU”，看右下角的虚拟化信息。
这里有两种显示：
- 虚拟化：已启用
- 基于虚拟化的安全性：未启用
如果“基于虚拟化的安全性”这行显示“未启用”，说明 VBS 没有运行；但这不代表 Hyper-V 没有加载，需要进一步确认。
更保险的办法是打开 CMD 或 PowerShell，输入：
systeminfo往下翻到“Hyper-V 要求”这一段，你会看到四种可能的输出。如果出现“已检测到虚拟机监控程序。将不显示 Hyper-V 所需的功能。”，那说明 hypervisor 正在运行中，VMware 报错的原因就坐实了。
如果显示“已在固件中启用虚拟化”，并且四个子项都是“是”，那么 hypervisor 没有加载，问题大概率不在 Hyper-V，你可以考虑去检查 VMware 版本、BIOS 设置或者驱动兼容性。
2.2 关掉 Hyper-V 后，你会失去什么
在动手之前我必须把这件事讲透，因为很多人在关完之后才想起来：WSL2、Docker Desktop、Windows Sandbox 全挂了。
这是关闭 Hyper-V 的连锁反应：
- WSL2：底层依赖虚拟机平台，hypervisor 不在，WSL2 发行版无法启动。只能用 WSL1，或者干脆放弃。
- Docker Desktop：新版 Docker Desktop 依赖 WSL2 后端，Hyper-V 关闭后 Linux 容器跑不起来。
- Windows Sandbox（沙盒）：这个功能本质是一个轻量 Hyper-V 虚拟机，hypervisor 关闭后无法使用。
- 安卓模拟器：特别是 Android Studio 自带的模拟器，如果配置了 WHPX 后端，也会受影响。
- 其他基于 Hyper-V 的虚拟化方案：VirtualBox 从 7.0 版本开始有改进，但 6.x 版本同样受 Hyper-V 抢占影响。
你需要在“VMware Workstation 能用”和“这些 Microsoft 生态功能能用”之间做取舍。如果你两样都想要，合理的选择不是关掉 Hyper-V，而是升级 VMware 到较新版本，并开启“Windows 虚拟机监控程序平台”功能，让 VMware 基于 WHPX 运行。不过这种方式在部分机器上性能损失明显，如果你对虚拟机的性能敏感，关闭 Hyper-V 仍然是更稳的路径。
2.3 改配置前，先把“后悔药”准备好
禁用 Hyper-V 本身不会删除你的虚拟机和数据，怕的是你不小心把系统搞到无法启动。我的习惯是，面对系统级配置修改，至少把这三个东西提前整理好：
- VMware 虚拟机文件目录：确认你的 .vmx 虚拟机配置文件、vmdk 磁盘文件都在，最好复制一份到移动硬盘。
- 当前系统的“Windows 功能”勾选状态：用 PowerShell 执行
Get-WindowsOptionalFeature -Online或者直接在功能面板截个图，方便日后恢复。 - Bcdedit 当前配置：执行
bcdedit /enum {current}保存输出结果。
另外，如果你用的电脑是公司统一管理的，改之前先确认组策略会不会把你改回去。明明改了注册表，隔天又被刷新，这种事情我在企业环境里见得太多了。
3. 方法一：从“Windows 功能”面板把 Hyper-V 全家桶移除
3.1 图形界面操作步骤
如果你是在普通家用电脑、个人电脑上操作，这是最直观、最不容易出错的路径。
按Win + R，输入control打开控制面板，依次进入“程序” -> “启用或关闭 Windows 功能”。
在弹出的列表中找到“Hyper-V”，展开它，把下面所有子项都取消勾选。这里很多人会漏掉两个隐藏项，需要特别注意：
- 虚拟机平台（VirtualMachinePlatform）
- Windows 虚拟机监控程序平台（HypervisorPlatform）
即使你的功能列表里没有“Hyper-V”这家店，只要有这两项被勾选，系统同样会加载虚拟化平台，导致 VMware 报错。
正确操作是：把“Hyper-V”全部子项取消勾选，把“虚拟机平台”取消勾选，把“Windows 虚拟机监控程序平台”取消勾选。点“确定”后系统会开始应用更改，大概率会提示重启电脑，此时直接重启。
重启之后，建议回头再打开一次这个面板，确认刚才取消的项目没有自动被重新勾选。Windows 更新会在某些情况下重新开启功能，如果你发现没过几天虚拟机监控程序又回来了，需要改装组策略或注册表方法，避免系统自动启用。
3.2 功能面板里根本找不到 Hyper-V 怎么办
这个问题在 Win10 家庭版上非常常见。家庭版默认不提供完整的 Hyper-V 角色安装包，功能面板里就不会显示 Hyper-V 项。
但这不代表虚拟机平台没开启。很多家庭版用户装过 WSL2，安装过程会自动启用“虚拟机平台”和“Windows 虚拟机监控程序平台”。所以即使你在面板里看不到 Hyper-V，也要检查另外两项有没有被勾上。
如果家庭版用户确实想关闭虚拟机平台，只需取消“虚拟机平台”和“Windows 虚拟机监控程序平台”的勾选即可，不需要找到 Hyper-V。
如果你还想使用 DISM 命令行来关闭，可以这样操作：
dism /online /disable-feature /featurename:Microsoft-Hyper-V-All如果你收到的返回值是“错误：0x800f080c”，一般意味着该功能在系统镜像里没有对应组件，你的系统可能就是家庭版或定制精简版。此时不用纠结，直接用后面的 bcdedit 方法关闭 hypervisorlaunchtype 反而更干净。
3.3 为什么关闭功能还不够：hypervisorlaunchtype 的残留
有些用户操作到这一步，明明把功能都取消了，重启后运行systeminfo发现 hypervisor 还在。原因很可能是 Windows 功能面板的变更没有真正生效，或者还在系统里残留了启动配置。
功能面板本质上做的是“启用/禁用 Windows 可选功能包”，但 hypervisor 是否在开机时加载，最终看的是 BCD 启动配置里的hypervisorlaunchtype参数。所以要彻底关闭，必须进入下一步，用 bcdedit 命令把启动类型改成 off。
4. 方法二：一条命令关闭 hypervisorlaunchtype
4.1 管理员 CMD 执行命令
这是我认为最“立竿见影”的方法，也是排错时最常用的一招。
右键点击“开始”菜单，选择“Windows PowerShell（管理员）”或者“命令提示符（管理员）”，注意一定要以管理员身份打开，否则会提示拒绝访问。
在命令行窗口里执行：
bcdedit /set hypervisorlaunchtype off看到“操作成功完成”的提示后，重启电脑。
如果你想恢复 Hyper-V 的正常加载，只需执行：
bcdedit /set hypervisorlaunchtype auto这条命令的本质是修改 BCD（启动配置数据）中的 hypervisor 加载策略。设为 off 之后，Windows 启动时不再主动加载虚拟机监控程序，VT-x 资源就释放给了 VMware Workstation。
我见过有人在执行命令后忘记重启，立刻打开 VMware 测试，发现还是报错，于是怀疑命令无效。其实命令写入了 BCD，但 hypervisor 是开机时加载的系统组件，不重启根本不可能生效。这条路径上的每一步都需要重启验证，不能偷懒。
4.2 验证命令是否真的生效
重启之后，你需要确认 hypervisorlaunchtype 已经变成 off。
再开一个管理员 CMD，执行：
bcdedit /enum {current}在输出内容中找到“hypervisorlaunchtype”这一行，正常情况下应该显示Off。如果是Auto，说明修改没有生效，常见原因是当前用户没有管理员权限，或者系统启用了“采用 Windows 启动管理器”之类的特殊机制。
另外一个终极大招是使用命令行一次性关闭并清理：
bcdedit /set hypervisorlaunchtype off bcdedit /set vsmlaunchtype offvsmlaunchtype是控制 VSM（Virtual Secure Mode，虚拟安全模式）加载的参数，和 Device Guard / Credential Guard 直接相关。如果你是企业电脑，这一步可能被组策略限制，需要结合后面第 5 章的注册表方法和组策略设置一起处理。
4.3 图形面板和 bcdedit 应该组合使用，而不是互相替代
我个人的习惯是：先关功能面板，再改 bcdedit，两个动作都做完再重启。
只关功能面板不关 bcdedit 的后果我上面说了，可能是残留；只改 bcdedit 不关功能面板，下次 Windows 功能状态变化时，启动参数可能被系统改回 auto。两个一起做，等于上了双保险，几乎不会有漏网之鱼。
如果你只跑 VMware Workstation，不关心 WSL2/Docker，那么第 3 章和第 4 章组合操作已经能解决大部分问题。如果依然报错，那就要怀疑是不是 Device Guard 和 Credential Guard 在作怪了。
5. 方法三：连 Device Guard / Credential Guard 一起收拾干净
5.1 组策略关闭基于虚拟化的安全
企业环境或者某些优化过的系统镜像会通过组策略强制开启 VBS。即使你把 Hyper-V 功能全部卸载，VBS 仍然会让系统加载 hypervisor，因为安全功能本身就需要虚拟化支持。
打开组策略编辑器：
按Win + R，输入gpedit.msc，回车。
路径如下：
计算机配置 -> 管理模板 -> 系统 -> Device Guard -> 打开基于虚拟化的安全双击“打开基于虚拟化的安全”，把状态改成“已禁用”。
在较新的 Win10 版本中，这个策略项也可能显示为“设备防护”，位置一样。禁用后，记得回到 CMD 里把虚拟安全模式关闭：
bcdedit /set vsmlaunchtype off重启后检查，如果组策略是本地配置，这一步基本能解决。如果是域环境统一下发的组策略，即使你本地改成禁用，重新执行gpupdate /force后它还是会刷回来。这种情况下你需要联系 IT 管理员，或者在注册表层面绕行。
5.2 Windows 安全中心的“内核隔离 - 内存完整性”
这是普通用户最容易忽略的一环。很多人在“Windows 安全中心”里看到“内核隔离”提示，当时随手点了“开启”，后来完全忘了这件事。
打开“Windows 安全中心”，依次进入“设备安全性” -> “内核隔离”，如果“内存完整性”是打开的，直接关闭它并重启。
关闭之后，VBS 的 HypervisorEnforcedCodeIntegrity（HVCI）机制不再运行，这能释放一部分虚拟化资源。这个问题在“win10 安全中心关闭”这个热词里经常被问到，实际上指的就是这里。
要注意的是，Windows 更新偶尔会尝试重新开启这一项。我遇到过几次：早上升级补丁打完之后，晚上再开 VMware 又报错，一看内存完整性又被打开了。如果你确定自己完全不需要这个安全功能，可以顺手把 Windows 安全中心里与“内核隔离”相关的建议通知关闭，或者通过注册表把关键键值锁死。
5.3 注册表键值一网打尽
如果组策略被锁定、安全中心画面看不到，还可以直接用注册表把 Device Guard 相关的开关关掉。
打开注册表编辑器（Win + R，输入regedit），定位到：
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceGuard在右侧找到EnableVirtualizationBasedSecurity，把值改为0（DWORD）。如果没有这个值，右键新建一个 DWORD（32 位），命名为EnableVirtualizationBasedSecurity，值设置为 0。
然后进入下面这个路径：
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity把Enabled的值改为0。
另外还有一个和 Credential Guard 直接相关的注册表项：
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa新建 DWORD 值LsaCfgFlags，设置为0。
如果你想用命令行一次性完成，管理员 CMD 或 PowerShell 里执行以下三条命令：
reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard" /v EnableVirtualizationBasedSecurity /t REG_DWORD /d 0 /f reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity" /v Enabled /t REG_DWORD /d 0 /f reg add "HKLM\SYSTEM\CurrentControlSet\Control\Lsa" /v LsaCfgFlags /t REG_DWORD /d 0 /f执行完务必重启。注册表不是即插即用型的配置项目，不重启，你会在验证阶段看到 VBS 依然在运行。
5.4 不重启的“临时顶一下”方案：VMware 隐藏虚拟化特征
有些场景下，你实在没法立刻重启，比如正在跑一个重要任务，但 VMware 虚拟机又必须马上打开。此时可以试试给 VMware 虚拟机配置文件加上隐藏 Hyper-V 特征的参数。
找到虚拟机的 .vmx 配置文件，用记事本打开，在文件末尾添加一行：
hypervisor.cpuid.v0 = FALSE保存后重新启动 VMware Workstation，再开虚拟机。
这个参数的作用是让虚拟机内部以为宿主机没有 Hyper-V 的特征值。但请注意，它并不能真正释放 VT-x，只是让 VMware 的检测机制暂时闭嘴。对于部分老版本 VMware 和部分 CPU，这招确实能骗过去，虚拟机也能运行，但实际上底层还是在和 Hyper-V 抢资源，性能很差，稳定性也没有保证。
我不会推荐把这个当作长期方案，它只适合应急。在重启条件允许的情况下，老老实实按 5.1 到 5.3 的路径把 VBS 关闭，才是根治方法。
6. 重启后的完整验证流程
6.1 用 systeminfo 确认 hypervisor 已经让位
关闭 Hyper-V 和 VBS 之后的第一次重启，建议做一次完整验证，不要急着打开虚拟机。
管理员 CMD 执行：
systeminfo观察“Hyper-V 要求”这一段：
- 如果输出是“已在固件中启用虚拟化”，并且四个子项全部显示“是”，恭喜你，hypervisor 已经不再运行，VT-x 已经被释放。
- 如果输出是“已检测到虚拟机监控程序。将不显示 Hyper-V 所需的功能。”，说明 hypervisor 还在，检查你的 bcdedit 和 Windows 功能是否都配置到位。
6.2 用 msinfo32 查看基于虚拟化的安全性状态
输入msinfo32打开系统信息，在“系统摘要”下方找到“基于虚拟化的安全性”。这一项有几个可能的值：
- 未启用：VBS 已经关闭，正常状态。
- 正在运行：VBS 还在运行，注册表或组策略没改干净。
- 已启用但未运行：配置上开了，但缺少某些前提条件，比如固件没开虚拟化，或者 hypervisor 没有加载。
如果你看到“正在运行”，优先检查 5.3 的注册表键值是否真的被改成了 0，再确认是否已经重启。我在企业环境里遇到过注册表被组策略刷新覆盖的情况，此时可以用gpresult /r查看是否有对应的策略对象正在生效。
6.3 实测 VMware Workstation
验证完系统状态之后，再启动 VMware Workstation，点开一个虚拟机。
正常情况下，之前那一句“Device/Credential Guard 不兼容”的报错已经消失，虚拟机可以正常开机进入系统。
第一次启动建议观察三点：
- 虚拟机右上角不再出现黄色警告条。
- 虚拟机内的系统响应速度比之前兼容模式下更快。
- VMware 的“虚拟机 -> 设置 -> 硬件 -> 处理器”里，虚拟化引擎选项中的“虚拟化 Intel VT-x/EPT 或 AMD-V/RVI”可以正常勾选。
如果你以后还要在 VMware 里做嵌套虚拟化测试，这一步很关键。只有 hypervisor 完全让位，这个选项才能真正生效。
7. 关完之后的一连串连锁反应，我踩过哪些坑
7.1 WSL2、Docker Desktop、Windows Sandbox 全部罢工
这是关闭 Hyper-V 后最先浮出水面的问题。
我的实际经历是这样的：一台主力开发机原本 WSL2 + Docker Desktop 用得好好的，后来为了测试某套老版本虚拟化环境，关闭了 Hyper-V。结果第二天打开 WSL2 终端，直接提示“WSL2 需要启用虚拟机平台”，Docker Desktop 的 Linux 容器引擎也起不来了。
解决方案只有两条路：
- 换回 WSL1：
wsl --set-version <发行版名称> 1，Docker 改用 WSL1 后端或者干脆换到 Windows 容器模式。这是一个折中方案，WSL1 的性能表现要差一些。 - 重新开启 Hyper-V：这是最彻底但最“贵”的一条路，你需要重新勾选功能、把 hypervisorlaunchtype 改回 auto，再重启。
我建议你在关闭 Hyper-V 之前，想清楚自己是不是同时依赖 VMware 和 WSL2/Docker。如果两者都离不开，可以试试 VMware 15.5.5 以上版本的 WHPX 模式，同时也保留 WSL2 的“虚拟机平台”。具体做法是在 Windows 功能里勾选“Windows 虚拟机监控程序平台”，然后 VMware 设置里把虚拟机硬件加速改为“使用 Hyper-V”。实测有一些性能损失，但至少两边都可以用。
7.2 工业软件的特殊需求：PLCSIM Advanced 和 TwinCAT
在这个标题的热搜词里我注意到 PLCSIM Advanced 和 TwinCAT 这两个名字。如果你是在做 PLC 仿真或者倍福实时控制开发，情况会特殊一些。
PLCSIM Advanced 在较新的版本中本身支持 Hyper-V 架构，这和你同时使用 VMware 的场景不太一样。如果你是先用 VMware 虚拟出一台 Win10，再在虚拟机里装 PLCSIM Advanced，那宿主机的 Hyper-V 开关状态会直接影响嵌套虚拟化是否可用。TwinCAT 3 在 Win11 下报 0x1024 错误，很多时候也和 hypervisor 抢占资源有关，关闭 hypervisorlaunchtype 是常见的排查手段之一。
我的建议是：对于这类工业软件，先确认软件官方对 Hyper-V 和虚拟化的支持矩阵，再决定关不关。盲目关闭 Hyper-V，可能导致某个工业软件的授权验证或实时通信功能失效。因为这类软件往往绑定了特定硬件驱动或实时网卡，和 Hyper-V 的关系就像一对藕断丝连的冤家。
7.3 我个人的日常方案：按需切换，保持“一套配置两条命”
在老黄历里，“两条命”指的是同一台物理机准备两套启动方案，日常切换到不同配置。现在我用的是更轻量的做法：在 Windows 功能面板和 bcdedit 之间灵活按需切换。
- 平时以 VMware Workstation 为主：功能面板里保持 Hyper-V 相关项为关闭状态，BCD 里 hypervisorlaunchtype 保持 off。
- 偶尔需要跑 Docker Desktop 或 WSL2：临时把 hypervisorlaunchtype 改成 auto，重启，用完再改回 off。
这套流程看着繁琐，但比“一关了之”稳妥。它比重新安装系统或瞎调 BIOS 安全得多，本质上只是修改一个启动参数而已。
我还会把常用的三条验证命令和两条开关命令封装到一个hyperv_switch.bat批处理脚本里，需要切换时右键以管理员身份运行，输入数字选择即可。
脚本内容大致长这样：
@echo off echo 1. 关闭 Hyper-V (VMware 优先) echo 2. 开启 Hyper-V (WSL2/Docker 优先) echo 3. 查看当前状态 set /p choice=请选择: if "%choice%"=="1" ( bcdedit /set hypervisorlaunchtype off bcdedit /set vsmlaunchtype off echo 请重启电脑生效 ) else if "%choice%"=="2" ( bcdedit /set hypervisorlaunchtype auto bcdedit /set vsmlaunchtype auto echo 请重启电脑生效 ) else if "%choice%"=="3" ( bcdedit /enum {current} | findstr hypervisorlaunchtype bcdedit /enum {current} | findstr vsmlaunchtype ) else ( echo 无效输入 ) pause这个脚本只能处理 bcdedit 层面的切换，如果要用图形面板管理功能状态，还是得手动走一遍“Windows 功能”流程。两套操作需要配合起来才能实现彻底的状态切换。
最后再分享一个小细节：关闭 Hyper-V 之后，如果你发现 VMware 虚拟机运行一段时间后出现 CPU 占用异常、虚拟网卡丢包这类小毛病，先去控制面板里看看卸载功能的时候是不是把“Hyper-V Virtual Ethernet”相关的虚拟适配器残留驱动也一并清理干净了。在设备管理器 -> 查看 -> 显示隐藏的设备里，把网络适配器下带 Hyper-V 字样的残留设备直接卸载，很多时候比反复重装 VMware 更管用。
