拓冰网站定制 
WSABuilds / MagiskOnWSAWSA 突然无法运行的 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/WSABuildsWindows 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 PlayL54-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 上通过 WSABuildsMagiskOnWSA安装方式部署的 WSA修改注册表Start值与执行bcdedit均需管理员权限且Start0的改动在确认无效后应按原文档提示改回3全流程共涉及三次重启第 2、7、9 步中间步骤不可跳过顺序保证“先彻底关闭 Hypervisor 相关组件 → 重新配置 → 按原顺序恢复”仓库只读本文所有步骤均发生在你的系统上不涉及修改 WSABuilds 仓库内容。【免费下载链接】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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 WSABuilds / MagiskOnWSA：WSA 突然无法运行的 Hypervisor 层重置修复指南
WSABuilds / MagiskOnWSAWSA 突然无法运行的 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/WSABuildsWindows 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 PlayL54-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 上通过 WSABuildsMagiskOnWSA安装方式部署的 WSA修改注册表Start值与执行bcdedit均需管理员权限且Start0的改动在确认无效后应按原文档提示改回3全流程共涉及三次重启第 2、7、9 步中间步骤不可跳过顺序保证“先彻底关闭 Hypervisor 相关组件 → 重新配置 → 按原顺序恢复”仓库只读本文所有步骤均发生在你的系统上不涉及修改 WSABuilds 仓库内容。【免费下载链接】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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考