WSABuilds / MagiskOnWSA：WSA 突然无法运行的 Hypervisor 层重置修复指南-二趣网

WSABuilds / MagiskOnWSA：WSA 突然无法运行的 Hypervisor 层重置修复指南

【免费下载链接】WSABuildsRun Windows Subsystem For Android on your Windows 10 and Windows 11 PC using prebuilt binaries with Google Play Store (MindTheGapps) and/or Magisk or KernelSU (root solutions) built in.项目地址: https://gitcode.com/GitHub_Trending/ws/WSABuilds

Windows Subsystem for Android 在安装后一直正常，却某天突然打不开或闪退，这是 WSA 用户最常遇到的“无报错式”故障。本篇基于仓库中的 WSA Stopped Working 修复文档，完整继承其 10 步修复流程，并结合 MagiskOnWSA 安装器源码（Run.bat/Install.ps1）解释每一步背后的 Hypervisor 依赖关系，帮助你在 Windows 10 / 11 上系统性地重置虚拟化环境、恢复 WSA 启动。

故障特征与成因

原文档描述的症状是：WSA 此前工作正常，突然停止工作（图标点击无响应、设置应用闪退、无启动画面）。仓库中 Documentation 目录的同一篇修复指南与它互为镜像，内容一致。

这类故障绝大多数与 Windows 虚拟化栈的状态错乱有关，常见诱因包括：

Hypervisor 启动方式残留：bcdedit中的 hypervisor 启动类型与当前系统服务状态不一致；
Windows 可选功能互相冲突：Hyper-V、Virtual Machine Platform、Windows Hypervisor Platform、WSL 四个功能开关在系统更新后可能出现启停状态与底层服务不匹配；
虚拟化开关状态不同步：BIOS/UEFI 中 Virtualization 已启用，但 Windows 侧服务未按预期接管（该场景的详细排查见 FixVirtError 文档）；
Control Flow Guard 未启用：文档明确指出，这是“已知会阻止 WSA 启动的问题”；
FsDepends 服务启动类型异常：注册表中该服务的Start值停留在默认值3（按需启动）而非0（系统启动），可能导致底层依赖加载时序异常。

完整修复流程（10 步）

以下步骤完整继承自原文档，按顺序执行即可。操作前建议创建系统还原点，涉及注册表与 BIOS 改动。

第 1 步：关闭全部虚拟化相关 Windows 功能

打开“启用或关闭 Windows 功能”（Turn Windows features on and off），如果以下功能处于启用状态，全部取消勾选（禁用）：

Windows 功能	处理方式
Hyper-V	禁用
Virtual Machine Platform	禁用
Windows Hypervisor Platform	禁用
Windows Subsystem for Linux	禁用

第 2 步：重启电脑

让功能卸载在服务层面生效。

第 3 步：进入 BIOS，关闭 Virtualization

重启进入 BIOS/UEFI，将 CPU 虚拟化（Intel VT-x / AMD-V 或类似选项）禁用。原文档为 Windows 10 和 Windows 11 分别给出了微软官方的虚拟化开关指引链接，这里不再外链，可在系统设置或微软支持文档中检索“enable virtualization”获取对应机型的操作说明。

第 4 步：确认 Control Flow Guard 已启用

路径：Windows 安全中心 → 应用和浏览器控制 → 漏洞保护。确保Control Flow Guard（控制流保护）处于启用状态。文档特别标注：这是一个已知的、可阻止 WSA 启动的问题。

第 5 步：修改 FsDepends 注册表项

打开regedit，定位到：

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\FsDepends

将值Start从3改为0（即从“手动/按需启动”改为“系统启动”）。

注（原文档 Note）：如果改完后没有效果，可以把它改回3。

第 6 步：管理员 CMD 中设置 Hypervisor 自动启动

以管理员身份运行 CMD，执行：

bcdedit /set hypervisorlaunchtype auto

该命令让 Hypervisor 在每次开机时自动随系统加载，这是 WSA 运行的硬性前提。

第 7 步：重新启用第 1 步禁用的功能并再次重启

回到“启用或关闭 Windows 功能”，重新勾选之前禁用的全部功能（Hyper-V、Virtual Machine Platform、Windows Hypervisor Platform、WSL，按你此前的实际状态），完成后第二次重启。

第 8 步：进入 BIOS，重新启用 Virtualization

与第 3 步路径相反，将 CPU 虚拟化选项恢复为启用。

第 9 步：第三次重启

让 BIOS 虚拟化与 Windows Hypervisor 服务在开机时序上重新对齐。

第 10 步：重新运行 WSA 验证

通过Run.bat或 “Windows Subsystem for Android 设置”应用重新拉起 WSA，观察是否恢复正常。

结合安装器源码理解修复逻辑

WSABuilds 的修复流程之所以强调Run.bat作为最后入口，可以从仓库源码中找到依据。

Run.bat 是统一启动入口

Run.bat 本身非常短：它切到脚本所在目录，检查Install.ps1是否存在，然后用-ExecutionPolicy Bypass启动 PowerShell 执行安装脚本。原文档中“RunRun.bator via the Windows Subsystem for Android Settings app”两条路径，前者走的就是这条链路。

Install.ps1 依赖 Virtual Machine Platform 可用

从 Install.ps1 源码看，安装流程对虚拟化平台有强依赖：

脚本开头通过Test-Administrator检查管理员权限，不足时以RunAs提权重启自身（约 L20-L77），这也解释了为什么bcdedit与注册表步骤都需要管理员上下文；
脚本显式检查并启用VirtualMachinePlatform可选功能，未启用时调用Enable-WindowsOptionalFeature并要求重启（L110-L120）——这正是修复流程第 1、7 步反复开关功能后，最终状态必须收敛到“Virtual Machine Platform 启用”的原因；
安装主体通过Add-AppxPackage -Register .\AppxManifest.xml注册 WSA 包，注册前会先WsaClient /shutdown关闭运行中的 WSA 实例（L159-L165）；
成功后Finish函数会直接以wsa://com.topjohnwu.magisk与wsa://com.android.vendingURI 拉起 Magisk 和 Google Play（L54-L58），因此第 10 步验证时，Magisk 主界面能打开即是恢复成功的直观标志。

从源码结构看，Install.ps1本身只负责“在虚拟化栈健康时把包装好”，它不修复 Hypervisor 状态错乱；因此当 WSA 已安装但突然罢工、而Run.bat重装无效时，就必须回到本文档的 10 步流程，从 bcdedit、功能开关、BIOS、注册表四个层面重置环境。

与仓库其他修复文档的关系

FixVirtError.md：处理的是“BIOS 中虚拟化和任务管理器都显示已启用，但 Virtual Machine Platform / Hypervisor Platform 报错”的场景，其修复步骤与本文高度同源（同样是禁用功能 → 关虚拟化 → CF Guard → FsDepends → bcdedit → 恢复），额外多了“先卸载 WSA 及安装包目录”的前置步骤；如果你的故障伴随具体的虚拟化报错弹窗，优先参考那一篇；
Troubleshooting.md：通用排障入口，建议在走完本文 10 步仍无效时，用官方 WSA 包做交叉验证，再按该文档提交反馈。

适用前提与注意事项

本文流程适用于 Windows 10 / 11 上通过 WSABuilds（MagiskOnWSA）安装方式部署的 WSA；
修改注册表Start值与执行bcdedit均需管理员权限，且Start=0的改动在确认无效后应按原文档提示改回3；
全流程共涉及三次重启（第 2、7、9 步），中间步骤不可跳过，顺序保证“先彻底关闭 Hypervisor 相关组件 → 重新配置 → 按原顺序恢复”；
仓库只读，本文所有步骤均发生在你的系统上，不涉及修改 WSABuilds 仓库内容。

创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考

企业官网建设流程全解析