WSABuilds：WSA 突然罢工（WSA Stopped Working）的完整修复与虚拟化环境重置指南-二趣网

WSABuilds：WSA 突然罢工（WSA Stopped Working）的完整修复与虚拟化环境重置指南

【免费下载链接】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

WSABuilds 用户常遇到一类"无征兆"故障：Windows Subsystem for Android（WSA）此前运行正常，某次更新或系统变动后突然无法启动、界面卡死或点击无响应，官方文档将其称为 "WSA Stopped Working!"。本文基于仓库内 WSA Stopped Working!.md 修复指南展开，完整讲解该故障的 10 步修复流程（Windows 功能开关、BIOS 虚拟化切换、Control Flow Guard、FsDepends注册表项、bcdedit引导项重置），并结合仓库中 Run.bat 与 Install.ps1 的源码说明修复后如何正确重新拉起 WSA，读完你可以独立完成一套"虚拟化栈完全重置 + WSA 重新注册"的实战操作。

故障表现：正常运行的 WSA 突然失效

该文档针对的典型场景是：WSA 一直在你的电脑上正常工作，但突然某一天它就坏了——启动失败、闪退或完全没有响应，而你没有做任何显式的改动。这类问题通常不是 WSA 包本身损坏，而是 Windows 的虚拟化相关组件（Hypervisor 启动方式、虚拟机平台特性、BIOS 虚拟化开关、安全加固项）状态出现不一致，导致 WSA 依赖的底层虚拟化环境失效。

文档原文用一句话概括了这个处境："WSA has been working fine for you, but all of a sudden, it breaks/stops working." 对应的处理思路是：先把 Windows 侧的虚拟化环境干净地拆掉，再按正确顺序重新装回去，最后通过安装器重新拉起 WSA。

修复流程总览

完整修复共 10 步，可按四个阶段理解：

阶段	步骤	目的
一、拆除	1–4：禁用四个 Windows 虚拟化特性 → 重启 → BIOS 关闭虚拟化 → 确认 Control Flow Guard 开启	让系统回到"无 Hypervisor 活动"的干净基线
二、修正关键项	5–6：修改`FsDepends`服务的`Start`值 → 以管理员 CMD 执行`bcdedit`命令	修正已知的会阻止 WSA 启动的配置缺陷
三、重建	7–9：重新启用步骤 1 禁用的特性 → 重启 → BIOS 开启虚拟化 → 再次重启	按正确顺序恢复完整虚拟化栈
四、验证	10：运行`Run.bat`或通过 WSA 设置应用重新启动	确认 WSA 恢复正常

下面逐步展开，每一步都保留原文档的具体操作要点，并补充可核验的依据。

阶段一：拆除 Windows 虚拟化组件并建立干净基线

步骤 1：在"启用或关闭 Windows 功能"中禁用四项特性

打开"启用或关闭 Windows 功能"（Turn Windows features on and off），检查以下四个特性，凡是已启用的，全部禁用：

Hyper-V
Virtual Machine Platform（虚拟机平台）
Windows Hypervisor Platform
Windows Subsystem for Linux

这四者都直接或间接挂在 Windows Hypervisor 之上。同时禁用它们的意义在于：彻底停掉 Hypervisor 的占用，避免残留的 Hypervisor 会话/驱动状态干扰后续重置。

步骤 2：重启电脑

禁用特性需要重启才能完全生效，此步不可跳过。

步骤 3：进入 BIOS 关闭虚拟化（Virtualization）

重启时进入 BIOS，将 CPU 虚拟化开关（Intel VT-x / AMD-V 对应的项）关闭。原文档为此提供了 Windows 11 与 Windows 10 两个平台的官方 BIOS 虚拟化设置指引（微软支持文档《Enable virtualization on your Windows PC》），不同主板厂商的 BIOS 界面略有差异，可按该指引找到对应选项。

步骤 4：确认 Control Flow Guard 处于开启状态

在Windows 安全中心（Windows Security）> 应用和浏览器控制（Apps & browser control）> 漏洞利用保护（Exploit protection）中，确保Control Flow Guard（CFG）已启用。原文明确指出："This is a known issue that can prevent WSA from starting"——CFG 未开启是已知的、会直接阻止 WSA 启动的原因，因此这一步是在"拆"的同时把这一已知问题一次性排掉。

阶段二：修正两个已知会卡住 WSA 的配置项

步骤 5：将`FsDepends`服务的`Start`值由 3 改为 0

打开注册表编辑器（regedit），定位到：

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\FsDepends

将其中的Start值从3改为0（即由"手动启动"改为"自动启动"）。

原文档特别注明："You can change it back to 3, if it makes no difference"—— 如果这项修改最终对你的问题没有影响，可以改回 3。

FsDepends是 Windows 文件系统依赖相关的服务项，该值异常会影响 WSA 包在启动时挂接文件系统依赖组件，因此修复指南将其列为必查项。

步骤 6：以管理员身份在 CMD 中执行 bcdedit

以管理员身份打开命令提示符（CMD），执行：

bcdedit /set hypervisorlaunchtype auto

该命令把 BCD（Boot Configuration Data）中的hypervisorlaunchtype设为auto，含义是"由系统根据已安装的 Hypervisor 组件自动决定是否启动 Hypervisor"。这是整个流程中最核心的一步：前面步骤 1–3 把环境拆到干净基线后，用auto让 Windows 在下次启动时重新协商并正确拉起 Hypervisor，而不是沿用之前可能已损坏/错位的固定值（如off或旧的enabled状态）。

阶段三：按正确顺序重建虚拟化栈

步骤 7：重新启用步骤 1 禁用的特性并第二次重启

回到"启用或关闭 Windows 功能"，把 Hyper-V、Virtual Machine Platform、Windows Hypervisor Platform、WSL 这些你刚才禁用的特性重新启用（保持你原本的使用习惯即可），然后第二次重启电脑。

步骤 8：在 BIOS 中重新开启虚拟化

再次进入 BIOS，将 Virtualization 打开（原文档同样给出 Windows 11 与 Windows 10 两份官方指引入口）。此时系统会以"干净基线 +hypervisorlaunchtype auto"的状态重新初始化虚拟化层。

步骤 9：第三次重启电脑

让所有变更（Windows 特性、BIOS、BCD、注册表）全部落地。

阶段四：重新拉起 WSA 并验证

步骤 10：运行`Run.bat`或通过 WSA 设置应用启动

原文档给出的验证方式是："Try re-running WSA by runningRun.bator via the Windows Subsystem for Android Settings app"，即两种入口任选其一：

运行解压目录中的Run.bat；
通过"Windows Subsystem for Android 设置"应用启动。

这一步在仓库里有完整的源码依据，值得展开看：

Run.bat 的逻辑非常简短：它先切到自己的目录，确认Install.ps1存在，然后以-ExecutionPolicy Bypass方式调用 PowerShell 执行 Install.ps1（第 28 行：start powershell.exe -ExecutionPolicy Bypass -File .\Install.ps1）。
Install.ps1 做了与"修复后重新拉起"直接相关的几件事：
- 管理员校验与提权（第 20–27、66–81 行）：用WindowsIdentity::GetCurrent()判断当前用户是否属于 Administrators 组，若不是则通过Start-Process -Verb RunAs重新以管理员身份拉起自身；
- 自动补齐虚拟机平台特性（第 110–120 行）：检查Get-WindowsOptionalFeature -Online -FeatureName 'VirtualMachinePlatform'，若未启用则自动Enable-WindowsOptionalFeature并提示重启。这也印证了为什么修复流程要关注 Virtual Machine Platform——安装器自身就依赖它是启用的；
- 依赖包版本校验（第 122–142 行）：读取AppxManifest.xml，按依赖包声明的MinVersion逐个比对已安装的 Appx 包版本，不足则用Add-AppxPackage安装对应.appx；
- 注册 WSA 主包（第 159–168 行）：先尝试WsaClient /shutdown关闭既有实例并结束残留WsaClient进程，再用Add-AppxPackage -Register .\AppxManifest.xml注册开发模式包，成功后Finish函数会拉起wsa://com.topjohnwu.magisk与wsa://com.android.vending两个 URI（第 54–58 行）；
- 升级失败时的降级重装路径（第 169–178 行）：若覆盖注册失败且已存在旧包，会提示并执行Remove-AppxPackage -PreserveApplicationData保留用户数据后重新注册。

从源码结构看，Run.bat这条路径本质是"关闭旧实例 → 校验依赖 → 重新注册开发模式包"的完整流程，因此把它作为"虚拟化环境重置之后的重新拉起入口"是合适的。如果Run.bat路径过深、提示路径过长，可参考仓库中 FixPathTooLong.md 处理。

与"虚拟化错误"故障的边界：何时该用另一篇指南

仓库中另有一篇同目录文档 FixVirtError.md，处理的是明确出现虚拟化错误的场景——即使 BIOS 里开了虚拟化、任务管理器里也显示已启用、且 Virtual Machine Platform + Windows Hypervisor Platform 都开着，WSA 仍报错。两者的流程骨架高度相似（同为"禁用特性 → 关 BIOS 虚拟化 → CFG 检查 → 注册表 →bcdedit→ 恢复特性 → 开 BIOS 虚拟化 → 重装"），但虚拟化错误版本多两处更彻底的动作，可作为本指南的进阶补充：

前置动作是卸载：原文要求先卸载 WSA（右键 WSA 设置应用选择卸载，并删除解压的安装文件夹）；
多一项 DeviceGuard 注册表修正：在HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\DeviceGuard下将EnableVirtualizationBasedSecurity设为0（若不存在该 DWORD 值，右键新建 DWORD（32 位）值、命名后设为 0）；
面向 AtlasOS 用户的兜底：若上述步骤仍无效，到 AtlasOS 配置目录中运行 "Enable Hyper-V and VBS" 的 CMD 脚本，重启后再试。

经验法则：有明确虚拟化报错 → 走 FixVirtError；WSA 之前正常、现在突然罢工且无明确虚拟化报错 → 走本文的 10 步流程。两篇指南的共同入口都列在 Having Issues.md 的常见问题徽章导航中。

仍无法恢复时的排查路径

如果完整走完 10 步 WSA 依旧不工作，仓库的 Troubleshooting.md 给出了下一步判断逻辑：

区分是 WSA 本体问题还是 WSABuilds 包问题：从 Microsoft Store（或官方 WSA 包仓库）安装官方 WSA 测试能否正常工作。官方版本也不能用，说明问题在系统/虚拟化层面，应按该文档指引通过 Feedback Hub 提交报告，并附完整复现步骤；
官方 WSA 正常但 WSABuilds 不正常：优先怀疑包/安装器环节，可考虑用仓库自带工具链重新安装——WSAUpdater.py 用于更新、WSAUninstaller.py 用于卸载，二者位于WSABuilds Utilities/目录下；
以上都不适用：在项目的 Issue 区或官方 Discord 社区求助（Troubleshooting.md 与原文档末尾都指向该渠道）。

小结与操作要点核对清单

整套修复的本质是"虚拟化栈的完全重置"：拆除 → 修正两个已知缺陷（CFG、FsDepends、hypervisorlaunchtype）→ 按顺序重建 → 用安装器重新注册。执行后可按此清单自查：

四个特性（Hyper-V / Virtual Machine Platform / Windows Hypervisor Platform / WSL）是否经历了"禁用 → 重启 → 再启用 → 再重启"的完整循环；
BIOS 虚拟化是否经历了"关闭 → 开启"的完整循环，且中间执行过bcdedit /set hypervisorlaunchtype auto；
Windows 安全中心的 Control Flow Guard 是否已确认开启；
HKLM\SYSTEM\CurrentControlSet\Services\FsDepends的Start是否已改为 0；
最后是否通过Run.bat（其底层为 Install.ps1 的依赖校验 + 开发模式包注册流程）或 WSA 设置应用成功拉起了 WSA。

只要按此顺序完成，绝大多数"WSA 突然罢工"的场景都能恢复；若个别机器对FsDepends改动无感知，可按原文档提示将其改回 3，不影响最终状态。

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

企业官网建设流程全解析