不吃章鱼烧虚拟机装不上这种问题，我这些年见太多了，但十次里有八次，最后都发现不是 VMware 安装包坏了，也不是系统文件损坏，而是 VMware 和 Windows 自己搭的那套虚拟化环境互相顶了牛。如果你在 VMware Workstation 安装过程里看到“安装程序检测到主机启用了 Hyper-V 或 Device/Credential Guard”，或者一启动虚拟机就提示“VMware Workstation 和 Hyper-V 不兼容”，先别急着重装系统，也别急着卸载杀毒软件，多数情况按下面这套思路走一遍就能解决。
这个问题的本质不是 VMware 单方面故障，而是 Windows 的 Hyper-V、Device/Credential Guard、基于虚拟化的安全性（VBS）等机制先占用了 CPU 的硬件虚拟化能力。VMware Workstation 需要直接访问 Intel VT-x 或 AMD-V，却被 Windows 的 Hypervisor 挡在了外面，于是安装程序检测到环境不干净，直接弹窗劝退。接下来我会从原理、检测、修复到共存方案，把整套排查动作讲清楚。无论你是刚装 VMware 的新手，还是维护了一批虚拟机、隔三差五被兼容性问题折磨的老手，这篇文章都值得收藏。
1. 这个报错到底在说什么：Hyper-V、Device Guard 和 CPU 虚拟化的“抢地盘”关系
1.1 为什么 VMware 会“排斥” Hyper-V
很多人把 Hyper-V 理解成 Windows 系统里的一个普通组件，觉得“我没用 Hyper-V 啊，怎么 VMware 老提它”。实际上，只要 Hyper-V 相关功能处于启用状态，Windows 开机后就会加载一个比操作系统权限还高的 Hypervisor，也就是虚拟机监控程序。Intel VT-x 或 AMD-V 这套 CPU 虚拟化扩展，本质上只能被一个高特权层的 Hypervisor 直接管理。Hyper-V 先把这个地盘占了，VMware Workstation 再去请求 VT-x，就会碰壁。
这就像你租了一个共享办公室，工位上已经坐了一位持有整层钥匙的“管理员”，你进去之后想自己再装一套门禁系统，房主当然不答应。VMware 和 Hyper-V 的角色冲突不是靠“改个兼容模式”“换个安装路径”能绕开的，必须从系统层面把已经占用的虚拟化通道释放出来。
1.2 Device/Credential Guard 和 VBS 又是怎么回事
Device Guard 和 Credential Guard 不是独立软件，而是 Windows 基于 Hyper-V 虚拟化技术做出来的安全功能。简单说，就是 Windows 在 Hypervisor 之上隔离了一块内存区域，专门跑安全代理、保存登录凭据、校验内核代码完整性的东西。这块隔离区域叫 VBS（基于虚拟化的安全性），它会强制 Windows 加载 Hypervisor，哪怕你在“启用或关闭 Windows 功能”里根本没手动勾选过 Hyper-V。
Windows 11 默认开启的内存完整性（Memory Integrity），就是 VBS 的一部分。所以很多新笔记本用户明明没碰过 Hyper-V，装 VMware 时照样报错，原因往往就是 Win11 的“核心隔离”开关在背后把 Hypervisor 拉起来了。还有的企业电脑，IT 部门通过组策略开了 Device Guard 或 Credential Guard，这类机器即使你手动把开关关了，重启后策略又会把它拉回来，必须额外处理。
1.3 排查前先区分：你是安装报错，还是启动虚拟机报错
先别急着套方案，要搞清楚你是在哪一步挂的。装 VMware Workstation 安装程序时弹出“安装程序检测到主机启用了 Hyper-V 或 Device/Credential Guard”，这叫安装检查失败。安装完成后创建虚拟机、点“开启此虚拟机”时提示“VMware Workstation 和 Hyper-V 不兼容。请先从系统中移除 Hyper-V 角色”，这叫运行期检查失败。
两种情况指向同一个根因，但处理力度可能不同。安装报错时，安装程序只是做了环境预检，你可以先把所有相关功能关掉再装；运行期报错则说明系统里 Hypervisor 还开着，需要关闭后重启。还有一种更隐蔽的报错是“VMware Workstation 不可恢复错误: (vcpu-1) Exception 0xc0000005 (access violation)”，这个通常和 VBS、内存完整性有关，不一定是 Hyper-V 功能本身。不同报错对应的排查重点不一样，下面我会分章节逐个说。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 判断当前系统虚拟化状态：先看这些地方有没有开
2.1 用 systeminfo 快速看 Hyper-V 状态
检测系统里 Hypervisor 到底有没有在运行，最朴素的工具就是 systeminfo。打开 CMD，执行：
cmd复制systeminfo
输出信息比较多，重点看最后那段“Hyper-V 要求”。如果看到“已检测到虚拟机监控程序。将不显示 Hyper-V 所需的功能”，说明当前 Hypervisor 正在运行。如果所有条目都显示“是”，也说明虚拟化特性已就绪，但这只能说明 CPU 和系统支持 Hyper-V，不能直接判断 Hyper-V 是否被启用。“已检测到虚拟机监控程序”这一条是最直接证据。
更精准的办法是用 bcdedit 查启动项：
cmd复制bcdedit /enum | find "hypervisorlaunchtype"
如果结果是 hypervisorlaunchtype Auto，表示 Windows 开机时会自动加载 Hypervisor。如果是 Off，表示启动时不会主动加载 Hypervisor，但这个命令不能反映 VBS/内存完整性是否又重新把它打开，所以还要结合其他检查。
2.2 PowerShell 检查 Windows 功能列表
Windows 功能对话框里能看到的虚拟化相关组件有好几个，光关一个“Hyper-V”往往不够。我建议用 PowerShell 统一看，管理员权限执行：
powershell复制Get-WindowsOptionalFeature -Online | Where-Object {$_.FeatureName -match "Hyper|Virtual|Hypervisor|Sandbox"} | Select-Object FeatureName, State
重点看这几项：
- Microsoft-Hyper-V-All：Hyper-V 完整功能
- Microsoft-Hyper-V-Hypervisor：Hyper-V Hypervisor 组件
- VirtualMachinePlatform：虚拟机平台，WSL2 依赖它
- HypervisorPlatform：Windows Hypervisor Platform，VMware 共存模式依赖它
- Windows-Sandbox：Windows 沙盒，它底层也走 Hyper-V
- Microsoft-Windows-Subsystem-Linux：WSL1/2 组件，WSL2 需要虚拟化支撑
如果这几项里有 Enable 状态，那就是 VMware 报错的主要来源。尤其要注意 VirtualMachinePlatform 和 HypervisorPlatform，它们不叫“Hyper-V”，很多人忽略，但它们确实会加载 Hypervisor。
2.3 检查 VBS、内存完整性和 Device Guard
光看功能列表还不够，还要看 VBS 是否在运行。最简单的入口在 Windows 安全中心：设置 → 隐私和安全性 → Windows 安全中心 → 设备安全性 → 核心隔离。把“内存完整性”开关打开，说明 VBS 正在跑。Win11 上这个开关默认经常是开着的。
想看得更细，可以用 msinfo32。运行 msinfo32，在“系统摘要”里找“基于虚拟化的安全性”。如果显示“正在运行”或“已启用”，说明 VBS 已生效。如果显示“未启用”，说明 Hypervisor 可能没有通过 VBS 加载。
再高级一点，用 PowerShell 检查 Device Guard 运行状态：
powershell复制Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard
这里的 SecurityServicesRunning 如果有值，比如 1 或 2，说明基于虚拟化的安全服务正在运行。配合注册表检查会更清楚，命令如下：
powershell复制Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\DeviceGuard"
Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity"
如果 EnableVirtualizationBasedSecurity 是 1，或 HypervisorEnforcedCodeIntegrity 的 Enabled 是 1，那就是 VBS 和内存完整性在背后托底，必须一起关掉。
2.4 关于 Windows 11 版本升级引入的隐藏选项
Windows 11 24H2 之后，微软把“内存完整性”更名为“核心隔离内存完整性”，位置不变，但部分电脑上还会有“应用程序安全控制”“内核 DMA 保护”等附加开关。Windows 11 25H2、26H1 预览版对虚拟化安全的管理方式也有变化，某些安全功能甚至不允许普通用户直接关，需要到 Windows 安全中心里操作，或者用命令行强制关。
如果你遇到的是新版本 Windows，比如 Win11 26H1，并且同时面对 VMware 报错，有一点要特别留意：新版系统里即使你关了 Hyper-V 功能，只要系统还开着“管理员保护”之类依赖 VBS 的东西，Hypervisor 依然会运行。这种情况下，与其逐个找开关，不如先把核心隔离和内存完整性关掉，再检查 hypervisorlaunchtype，通常就能恢复 VMware 的正常使用。
3. 通用修复步骤：彻底关闭 Hyper-V、VBS 和相关安全功能
3.1 关闭 Hyper-V 相关 Windows 功能（GUI 和命令行）
如果你是 Windows 10/11 专业版或企业版，最直观的入口是运行 optionalfeatures，打开“启用或关闭 Windows 功能”。把下面几项全部取消勾选：
- Hyper-V（整个节点）
- 虚拟机平台
- Windows 虚拟机监控程序平台
- Windows 沙盒
- 适用于 Linux 的 Windows 子系统（如果你不用 WSL，可以一并关）
注意，Windows 11 家庭版默认看不到 Hyper-V 勾选项，但能看到“虚拟机平台”和“Windows 虚拟机监控程序平台”。这两个照样会导致 VMware 报错，所以也要取消。
如果是企业批量机器，或者你想通过命令行处理，管理员权限开 PowerShell，执行：
powershell复制dism /online /disable-feature /featurename:Microsoft-Hyper-V-All /norestart
dism /online /disable-feature /featurename:VirtualMachinePlatform /norestart
dism /online /disable-feature /featurename:HypervisorPlatform /norestart
dism /online /disable-feature /featurename:Windows-Sandbox /norestart
等命令跑完，重启系统。如果 dism 提示找不到组件，可能是系统精简版，或者是家庭版里功能名不同，建议直接用 GUI 取消勾选。
3.2 通过 bcdedit 关闭 hypervisorlaunchtype
关完功能之后，还要确保 Windows 启动项里不加载 Hypervisor。这一步很关键，因为很多用户已经取消了 Hyper-V 勾选，但 bcdedit 里 hypervisorlaunchtype 还保持 Auto，开机仍然会拉起 Hypervisor。
管理员 CMD 执行：
cmd复制bcdedit /set hypervisorlaunchtype off
重启前可以先确认一下：
cmd复制bcdedit /enum | find "hypervisorlaunchtype"
显示 Off 就成功。但我要提醒你一句：如果系统里 VBS、内存完整性还开着，Windows 更新或安全策略会在启动时重新把 hypervisorlaunchtype 改回 Auto。所以 bcdedit 只是其中一环，不是全部。
3.3 关闭内存完整性和基于虚拟化的安全性
接下来处理 Windows 安全中心里的核心隔离。打开 Windows 安全中心 → 设备安全性 → 核心隔离，把“内存完整性”开关关闭。如果开关是灰色的，或者关闭后又自动打开，说明 VBS 是被组策略或注册表锁定的，需要去注册表里强制关。
按 Win+R 输入 regedit，定位到：
reg复制HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceGuard
把 EnableVirtualizationBasedSecurity 的值设为 0。如果没有这个值，就新建一个 DWORD（32 位）值，命名 EnableVirtualizationBasedSecurity，值填 0。
然后继续定位到：
reg复制HKEY_LOCALACHINE\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity
把 Enabled 的值设为 0。再检查是否有：
reg复制HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\CredentialGuard
如果有，同样把 Enabled 设为 0。 CredentialGuard 就是 Credential Guard 的注册表开关，企业电脑经常会遇到。
我看过很多教程只教关内存完整性，不教处理 Credential Guard，导致用户重启后发现 Hypervisor 又回来了。这次把注册表都改掉，能减少一层隐患。
3.4 排查组策略和设备防护残留
如果你用的是公司统一配发的电脑，或者系统里预装了企业安全策略，单靠 GUI 和注册表可能不够。需要检查组策略。
Win+R 运行 gpedit.msc，依次进入：
计算机配置 → 管理模板 → 系统 → Device Guard
右侧找“打开基于虚拟化的安全性”，双击设为“已禁用”。它下面还有一项“基于虚拟化的安全性的凭据保护”，如果有，也改成“已禁用”。
改完后在 CMD 执行：
cmd复制gpupdate /force
再重新启动。如果机器是 Windows 11 家庭版，没有 gpedit.msc，那就只能靠注册表，把 DeviceGuard 和 Scenarios 下的相关键值全部清成 0。这里注意：有些策略是通过 MDM 或 Intune 下发的，会再次覆盖注册表。如果是公司电脑，最稳妥的办法是联系 IT 部门，让管理员把 VBS 策略关掉，或者给你一台不强制开启 Device Guard 的机器。
3.5 清理完成后的启动顺序与验证
关闭操作不是一次重启就万事大吉。我自己的习惯是：所有修改完成后，先正常重启一次，再重新打开 CMD 执行验证：
cmd复制bcdedit /enum | find "hypervisorlaunchtype"
确保是 Off。然后再开 msinfo32 看“基于虚拟化的安全性”，显示“未启用”。再运行 systeminfo，如果 Hyper-V 要求部分显示“已检测到虚拟机监控程序”这句话，说明还没关干净，需要回到 3.3 和 3.4 继续排查。
只有这三项都满足，才能确定 Hypervisor 没有占着 VT-x。这时再安装 VMware Workstation，或启动之前的虚拟机，基本不会再被“不兼容”弹窗卡住。
4. BIOS 层面的配合操作：别让 VT-x 设置拖后腿
4.1 确认 BIOS 中的虚拟化开关已经打开
系统层面的关停做完后，还得看 BIOS 里 CPU 的虚拟化开关是否打开。Intel 平台叫 Intel Virtualization Technology 或 VT-x，AMD 平台叫 SVM Mode。有些笔记本厂商默认把这个选项关掉，尤其是办公本。
进 BIOS 的方法不用我说太多了，开机时按 DEL、F2、F10、F12 都试一下。进 BIOS 后找 Advanced、CPU Configuration、Security 这类菜单，看到 Intel Virtualization Technology、Intel VT-x、AMD SVM Mode 或类似的选项，设为 Enabled。
设置完保存退出，进系统后再验证一次 systeminfo 的 Hyper-V 要求部分，看到“虚拟化：是”，说明 CPU 虚拟化已经开放。你可能会问，为什么系统层面关了 Hypervisor，还要管 BIOS？因为 VMware Workstation 直接跑虚拟机时，需要物理 CPU 的 VT-x/EPT 或 AMD-V/RVI 支持，如果 BIOS 里关着，VMware 会报“此主机支持 Intel VT-x，但 Intel VT-x 被禁用”。这个报错和 Hyper-V 不兼容是两回事，但经常一起出现，所以我会在排障时顺便检查。
4.2 关闭 Hyper-V 之后仍然不兼容？检查这些细节
有读者会问：“我 BIOS 里的 VT-x 开着，系统功能也关了，hypervisorlaunchtype 也 Off 了，怎么 VMware 还说不兼容？”遇到这种情况，最容易被忽略的是这几个细节：
第一，Windows 更新后续又把 VBS 开起来了。Win11 的月度更新有时会重置安全基线，把内存完整性重新打开。检查一下 Windows 安全中心里的核心隔离，如果是开着的，关掉再重启。
第二，Windows 功能里有个“Windows Hypervisor Platform”被漏掉。它和“虚拟机平台”长得像，位置也挨着，但它们是两个独立组件。如果你开了这个组件，Hypervisor 依旧会运行，VMware 照样报错。
第三，组策略或注册表里 Device Guard 的 CredentialGuard 残留。公司电脑最常见，必须按 3.4 的方法处理干净。
第四，VMware 版本太老。旧版 Workstation 15 之前对 Hyper-V 共存支持很差，Win11 24H2 之后建议至少用 Workstation 17.6.1 或 17.6.4。
把上面四点逐项过一遍，基本能定位到残留项。
5. 如果不想关闭 Hyper-V：使用 Windows Hypervisor Platform 共存
5.1 开启 Windows Hypervisor Platform 的前提
看到这里可能有人会犹豫：“我家里的 Docker Desktop 依赖 WSL2，WSL2 又依赖虚拟机平台，我不能把 Hypervisor 全关掉啊。”确实，现代开发环境里 WSL2、Docker、Windows 沙盒都是建立在 Hyper-V 虚拟化栈之上的。如果为了 VMware 把这一切全关掉，开发环境就得重做，代价太高。
这种情况的解决方案不是硬碰硬，而是让 VMware 走 Windows Hypervisor Platform（WHP）这条中间通道。原理是：Hypervisor 仍然运行，VMware 不再直接操作 VT-x，而是通过 Windows 提供的 API 去调用 Hypervisor。VMware Workstation 15.5.5 之后开始支持这种方式，到 17.x 版本已经比较成熟。
所以首先需要开启 Windows Hypervisor Platform 功能。管理员 PowerShell 执行：
powershell复制dism /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart
dism /online /enable-feature /featurename:HypervisorPlatform /all /norestart
开完之后重启。注意，bcdedit 里的 hypervisorlaunchtype 必须保持 Auto，如果之前被设置成 Off，要先改回来：
cmd复制bcdedit /set hypervisorlaunchtype auto
否则 Hypervisor 不启动，WHP 通道也不可用。
5.2 VMware 虚拟机设置中的虚拟化引擎选项
WHP 功能开启后，VMware 通常能自动识别并切换兼容模式。但为了稳一点，我还会手动检查虚拟机设置：选中虚拟机 → 编辑设置 → 处理器 → 虚拟化引擎。这里有几个复选框，重点看两个：
- “虚拟化 Intel VT-x/EPT 或 AMD-V/RVI”
- “通过 Windows Hypervisor Platform 使用虚拟机监控程序”（部分版本显示为“Hyper-V 应用程序兼容性”之类，具体以你界面为准）
把“虚拟化 Intel VT-x/EPT 或 AMD-V/RVI”勾上，再把通过 Windows Hypervisor Platform 使用的选项勾上。保存后启动虚拟机，VMware 会通过 WHP 通道工作，而不是直接和 Hyper-V 抢 VT-x。
需要提醒的是，这一步只针对已经创建好的虚拟机。如果你连安装 VMware 时都报“检测到 Hyper-V”，先把功能装好，再在虚拟机设置里勾选这些选项，不要反过来。
5.3 共存方案的注意事项和已知问题
共存不是免费的，代价主要在三方面：
一是性能。WHP 通道相当于在 Hypervisor 和 VMware 之间加了一层翻译，CPU 虚拟化指令走的是间接路径，尤其是高 I/O 负载场景，虚拟机会比原生 VT-x 模式慢一些。我实测跑同一个 Linux 编译任务，WHP 模式比原生模式慢 10% 到 20%。
二是嵌套虚拟化受限。如果虚拟机里还想继续跑 Docker、再套一层 Hyper-V，在 WHP 模式下会有兼容问题。虽然 VMware 17 已经改善了嵌套虚拟化，但复杂场景仍然不稳定。
三是故障排查复杂度增加。开启 WHP 后，如果 VMware 报错，你需要同时考虑 VMware、Windows 功能、Hypervisor 三层的问题。这也是为什么我一般会建议：除非必须用 WSL2/Docker，否则能关 Hyper-V 就关，别给自己增加排障难度。
6. 常见报错和排查速查表
6.1 安装程序检测到主机启用了 Hyper-V 或 Device/Credential Guard
这是最典型的安装期报错。主要原因就是 1.2 里说的 VBS、内存完整性、虚拟机平台、Windows Hypervisor Platform、Hyper-V 任一存在。解决步骤按第 3 章走一遍即可。如果按第 3 章走完还报错，多半是组策略或者注册表里 Credential Guard 没清干净，重点查 3.4。
6.2 VMware Workstation 和 Hyper-V 不兼容。请先从系统中移除 Hyper-V 角色
这种弹窗在启动虚拟机时最常见。它与 6.1 的区别在于：安装程序可能已经放行，但 VMware 启动虚拟机时发现 Hypervisor 仍在运行。原因集中在两类：
- 第一类：hypervisorlaunchtype 还是 Auto，没有设成 Off。
- 第二类：内存完整性和 VBS 又自己打开了。
如果你坚持要用 WSL2/Docker，就按第 5 章走 WHP 共存。如果你不需要共存，就回第 3 章把 hypervisorlaunchtype、VBS、内存完整性全部关掉。
6.3 不可恢复错误 (vcpu-1) Exception 0xc0000005 (access violation)
这个报错不是在安装时出现，而是在虚拟机运行过程中直接崩出来。Win11 上特别多见，和内存完整性强相关。核心隔离打开时，Hypervisor 会在内存层面做隔离校验，VMware 的虚拟 CPU 线程一旦访问被保护的内存区域，就可能触发 0xc0000005 访问冲突。
解决办法很简单：关闭内存完整性和 VBS，重启虚拟机。如果不想全局关闭 VBS，可以试试把虚拟机设置里的虚拟化引擎改成不勾选“虚拟化 Intel VT-x/EPT”，让 VMware 用纯软件模拟方式跑，但这会明显变慢，我不推荐。最好还是彻底关掉 VBS。
还有一种情况是 VMware 的 .lck 锁文件残留在虚拟机目录里，导致 vcpu-1 线程异常。针对这种情况，关闭 VMware，去虚拟机目录里把扩展名为 .lck 的文件夹删掉，重新打开。
6.4 其他容易忽略的关联问题
- 安装 VMware 后提示“无法打开内核设备 \.\Global\vmx86”。一般是安装完成后没重启，或者 VMware 服务没起来。用管理员身份启动 VMware，或到服务管理器里确认 VMware Authorization Service、VMware Host 相关服务处于运行状态。
- 虚拟机一直转圈打不开。这和 Hyper-V 不兼容不一定直接相关，但 Win11 的 VBS 会拖慢虚拟机启动速度。可以先关闭 VBS 再试。
- VMware 升级后许可证失效。Workstation Pro 17 对旧版许可证兼容性要求较高，升级后需要重新输入密钥。不要拿 Player 的授权去激活 Workstation Pro，这会导致激活失败，看起来像软件装坏了。
下面给一个简化的速查表，方便你对照处理：
| 报错现象 | 最可能原因 | 核心处理 |
|---|---|---|
| 安装程序检测到 Hyper-V 或 Device/Credential Guard | Hyper-V/VBS/内存完整性开启 | 关闭相关功能 + bcdedit off |
| VMware 与 Hyper-V 不兼容 | hypervisorlaunchtype Auto 或 VBS 残留 | 设置 off，关闭 VBS |
| vcpu-1 访问冲突 0xc0000005 | 内存完整性/VBS | 关闭内存完整性 |
| 无法打开 vmx86 内核设备 | 未重启/服务未启动 | 重启后以管理员运行 |
| Intel VT-x 被禁用 | BIOS 设置关闭 | 进 BIOS 开启 VT-x/SMV |
| 模块 Disk 启动失败 | Hypervisor 残留 | 按第 3 章清理后重启 |
7. 收尾：我的实际操作习惯和建议
我自己日常维护的机器上同时跑 VMware、WSL2 和 Docker，所以不会傻乎乎地把 Hyper-V 全关掉。我的做法是：主力 Windows 机器走 WHP 共存方案，VMware 17.6.4 + Windows Hypervisor Platform，WSL2 照常开。如果是临时测试用的虚拟机，或者客户那边的机器只跑 VMware，我会直接把 hypervisorlaunchtype 关掉，VBS 和内存完整性也顺手关，这样最省心。
还有一个小技巧，每次 Windows 大版本更新之后，第一时间检查 bcdedit 的 hypervisorlaunchtype 和 Windows 安全中心的内存完整性开关。微软更新经常把安全基线重置，导致上次关好的功能又被打开。这个坑我踩过好几次，后来就养成了“更新后必查两项”的习惯。
如果你按这篇文章一步步操作后仍然报错，不要急着格式化。先在 VMware 官网下载最新的 Workstation Pro 版本，再检查 BIOS 里 VT-x 是否真正开启，然后看 Windows 更新是否最近推送过安全补丁。绝大多数 Hyper-V 冲突问题都逃不出这三个方向。实在不行，把 Windows 事件查看器里与 vmms、hypervisor、vmx86 相关的错误日志截图，作为排查线索，比盲目重装系统高效得多。