WSABuilds 安装报错 0x80073D10 排查指南WSA 包与 CPU 架构不匹配的识别与修复【免费下载链接】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 / MagiskOnWSA 用户在 Windows 10 / Windows 11 上运行Run.bat安装 Windows Subsystem for Android (WSA) 时遇到的0x80073D10错误。该错误的核心根因是下载并安装了与当前 CPU 架构不匹配的 WSA 安装包典型场景在 x64 电脑上误装了 arm64 包。读完本文你将掌握错误的判断方法、CPU 架构的确认手段、正确的下载选包与安装流程并理解安装脚本在底层如何按架构校验与注册 Appx 包从而彻底规避此类架构错配问题。一、错误现象执行 Run.bat 时出现 0x80073D10当用户从 WSABuilds 的 Release 页面下载 WSA 预构建包、解压后在文件夹内双击Run.bat尝试安装时安装过程会以0x80073D10错误码失败。0x80073xxx 属于 Windows AppX/应用部署App deployment错误区间说明问题发生在应用包Appx package的部署与注册阶段而不是 WSA 运行时故障。在 WSABuilds 的文档体系中该问题被归入安装前Pre-Install故障类别其典型触发场景是正在尝试为你的 CPU 架构安装错误的 WSA 包。例如在 x64 系统上误装了 arm64 包。即包本身的部署流程没有变变的是包与硬件平台不匹配。二、根因剖析安装包与 CPU 架构不匹配2.1 WSA 预构建包是架构强相关的WSA 底层运行 Android 子系统其 Appx 包内包含与指令集强绑定的二进制内容因此微软官方发布的 WSA 分为x64x86_64与arm64两种架构产物二者不可互换。WSABuilds 仓库在下载与构建层面同样严格区分这两种架构下载脚本 MagiskOnWSA/scripts/generateWSALinks.py 的第一个命令行参数就是archarch sys.argv[1]脚本据此向微软 FE3 交付服务请求对应架构的 WSA.msixbundle以及架构相关的依赖包见下文第四节交互式构建脚本 MagiskOnWSA/scripts/run.sh 在构建前会让用户通过单选列表明确选择x64 (X86_64)或arm64 (AArch64)并将该选择传入构建流程。从 README 的硬件要求表README.md可以看到WSA 对 CPU 的架构要求即为x86_64 或 arm64没有第三种通用包。2.2 安装脚本按架构注册包WSABuilds 的安装目录 MagiskOnWSA/installer 下分别维护了x64/与arm64/两套安装脚本各含Install.ps1与MakePri.ps1进一步印证了安装流程的架构差异化。关键证据在 MagiskOnWSA/installer/Install.ps1脚本解析当前目录下的AppxManifest.xml从中读取包的ProcessorArchitecture属性然后只对与当前架构一致的依赖包执行版本校验与安装[xml]$Xml Get-Content .\AppxManifest.xml; $Name $Xml.Package.Identity.Name; $ProcessorArchitecture $Xml.Package.Identity.ProcessorArchitecture; $Dependencies $Xml.Package.Dependencies.PackageDependency; $Dependencies | ForEach-Object { $InstalledVersion Get-InstalledDependencyVersion -Name $_.Name -ProcessorArchitecture $ProcessorArchitecture; ... Add-AppxPackage -ForceApplicationShutdown -ForceUpdateFromAnyVersion -Path $($_.Name)_$ProcessorArchitecture.appx }也就是说预构建包的架构在打包时就已经固化在AppxManifest.xml中。若你在 x64 系统上拿到了 arm64 包安装器拿到的ProcessorArchitecture是arm64其后续的Add-AppxPackage -Register .\AppxManifest.xml注册步骤就会因平台不符而抛出 0x80073D10 一类的部署错误。三、解决方案三步走以下为官方修复文档给出的标准修复流程完整继承如下。第 1 步回到 Release 页重新核对下载包前往本仓库WSABuilds的Release / 最新版本页面仔细检查你下载的资产Assets是否与自己的电脑环境匹配。这是最容易被忽略的一步——不少用户下载了错误的资产文件而不自知。第 2 步选择与你操作系统OS和 CPU 架构匹配的包在 Release 的 Assets 列表中认准同时满足以下两个条件的文件操作系统Windows 10 还是 Windows 11两者有对应的独立构建产物部分版本对 Win10/Win11 的支持状态不同可参考 Documentation/WSABuilds/Information.md 中的版本兼容性表CPU 架构x64 还是 arm64与你的电脑架构严格一致。注意Source code源码包不是可安装的 WSA 构建请勿下载。第 3 步下载后按安装指南完成安装下载正确的包后按照 Documentation/WSABuilds/Installation.md 的安装流程操作解压.7z归档 → 将解压出的文件夹重命名为WSA长文件夹名可能导致 WSA 无法启动→ 移动至合适位置后续使用期间不能删除该文件夹→ 双击Run.bat完成注册与安装。四、安装流程底层原理从 Run.bat 到 Appx 注册理解修复方案的原理有助于你在架构正确时依然从容排查同类部署错误。WSABuilds 的安装链路如下Run.bat仅作启动器MagiskOnWSA/installer/Run.bat 会先检查同目录是否存在Install.ps1随后以powershell.exe -ExecutionPolicy Bypass -File .\Install.ps1拉起 PowerShell 安装脚本Install.ps1完成整个部署MagiskOnWSA/installer/Install.ps1 依次执行检测管理员权限并自动提权非管理员时以-Verb RunAs重启自身检查filelist.txt所列文件是否齐全可选调用MakePri.ps1合并资源写入AllowDevelopmentWithoutDevLicense开发部署注册表项确保VirtualMachinePlatform功能已启用未启用会提示重启按AppxManifest.xml中的架构信息安装/校验依赖包若检测到已安装的 WSA先询问卸载旧包更新场景会保留用户数据最后执行Add-AppxPackage -ForceApplicationShutdown -ForceUpdateFromAnyVersion -Register .\AppxManifest.xml注册 WSA 主包并打开 Magisk 与 Play 商店。其中依赖包也是按架构分别下载的。从 MagiskOnWSA/scripts/generateWSALinks.py 可见脚本对Microsoft.VCLibs..._{arch}、Microsoft.UI.Xaml..._{arch}等依赖文件名做了架构正则匹配——架构一旦选错依赖包的文件名与内容都会对不上部署自然失败。五、如何确认自己电脑的 CPU 架构在重新下载前请务必先确认本机架构避免再次下载错误的包。以下任选其一PowerShell / CMD执行echo %PROCESSOR_ARCHITECTURE%CMD或$env:PROCESSOR_ARCHITECTUREPowerShell输出AMD64即为 x64 架构输出ARM64即为 arm64 架构设置界面设置 → 系统 → 关于在「系统类型」一栏查看「基于 x64 的处理器」或「基于 ARM 的处理器」WMIC执行wmic cpu get architecture查看处理器架构部分较新系统上该命令可能被弃用可改用 PowerShell 的Get-CimInstance Win32_Processor | Select-Object Architecture。确认架构后再去 Release 页面选择与之一致的资产。六、架构错配的常见诱因与避坑要点结合社区常见反馈0x80073D10 的诱发场景通常包括在x64 台式机/笔记本上误下..._arm64结尾的包反之亦然分不清 Windows 10 与 Windows 11 的构建产物下载了另一系统版本的包从旧版本或第三方渠道获取包未核对包内AppxManifest.xml的ProcessorArchitecture将 Windows 11 的包强行装到 Windows 10或反之导致注册阶段出现其他 0x80073xxx 部署错误。避坑要点只在官方 Release 的 Assets 中选择命名与你的OS 架构完全一致的资产若不确定版本稳定性可参照 Documentation/WSABuilds/Information.md 中的 ✅稳定/ ⚠️不稳定/ ⛔不可用指示避开标红版本保留解压后的WSA文件夹不被删除——Add-AppxPackage -Register注册的是未打包的现有文件删除文件夹将导致 WSA 无法使用。七、架构无误但安装仍失败按此通用流程诊断如果架构已确认匹配、Run.bat依然报 0x80073D10 或其他 0x80073xxx 错误可进入诊断流程需要管理员权限打开管理员 PowerShell切换到 WSA 解压目录执行Add-AppxPackage -ForceApplicationShutdown -ForceUpdateFromAnyVersion -Register .\AppxManifest.xml失败时会输出一个ActivityIDUUID执行Get-AppPackageLog -ActivityID uuid查看失败日志根据日志定位原因。此外仓库还整理了针对不同 0x80073 系列错误的专项修复文档可对照你的错误码查阅Fix Error 0x80073CF0Fix Error 0x80073CF6Fix Error 0x80073CF9Fix Error 0x80073CFBFix Error 0x80073CFD若仍无法解决可参考 Documentation/WSABuilds/Having Issues.md 与 Documentation/WSABuilds/Troubleshooting.md 获取进一步排查指引。八、小结0x80073D10 是 WSA 安装环节中最典型的架构错配型部署错误。修复它的关键不在于改动任何脚本而在于下载阶段选对与 OS 和 CPU 架构匹配的安装包先通过%PROCESSOR_ARCHITECTURE%确认本机架构再到 Release 页核对资产名称最后按安装指南解压并运行Run.bat即可。理解了 MagiskOnWSA/installer/Install.ps1 中按AppxManifest.xml的ProcessorArchitecture注册依赖与主包的机制后你也能举一反三将同样的架构意识应用到后续的 WSA 更新与重装中。【免费下载链接】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 安装报错 0x80073D10 排查指南：WSA 包与 CPU 架构不匹配的识别与修复
WSABuilds 安装报错 0x80073D10 排查指南WSA 包与 CPU 架构不匹配的识别与修复【免费下载链接】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 / MagiskOnWSA 用户在 Windows 10 / Windows 11 上运行Run.bat安装 Windows Subsystem for Android (WSA) 时遇到的0x80073D10错误。该错误的核心根因是下载并安装了与当前 CPU 架构不匹配的 WSA 安装包典型场景在 x64 电脑上误装了 arm64 包。读完本文你将掌握错误的判断方法、CPU 架构的确认手段、正确的下载选包与安装流程并理解安装脚本在底层如何按架构校验与注册 Appx 包从而彻底规避此类架构错配问题。一、错误现象执行 Run.bat 时出现 0x80073D10当用户从 WSABuilds 的 Release 页面下载 WSA 预构建包、解压后在文件夹内双击Run.bat尝试安装时安装过程会以0x80073D10错误码失败。0x80073xxx 属于 Windows AppX/应用部署App deployment错误区间说明问题发生在应用包Appx package的部署与注册阶段而不是 WSA 运行时故障。在 WSABuilds 的文档体系中该问题被归入安装前Pre-Install故障类别其典型触发场景是正在尝试为你的 CPU 架构安装错误的 WSA 包。例如在 x64 系统上误装了 arm64 包。即包本身的部署流程没有变变的是包与硬件平台不匹配。二、根因剖析安装包与 CPU 架构不匹配2.1 WSA 预构建包是架构强相关的WSA 底层运行 Android 子系统其 Appx 包内包含与指令集强绑定的二进制内容因此微软官方发布的 WSA 分为x64x86_64与arm64两种架构产物二者不可互换。WSABuilds 仓库在下载与构建层面同样严格区分这两种架构下载脚本 MagiskOnWSA/scripts/generateWSALinks.py 的第一个命令行参数就是archarch sys.argv[1]脚本据此向微软 FE3 交付服务请求对应架构的 WSA.msixbundle以及架构相关的依赖包见下文第四节交互式构建脚本 MagiskOnWSA/scripts/run.sh 在构建前会让用户通过单选列表明确选择x64 (X86_64)或arm64 (AArch64)并将该选择传入构建流程。从 README 的硬件要求表README.md可以看到WSA 对 CPU 的架构要求即为x86_64 或 arm64没有第三种通用包。2.2 安装脚本按架构注册包WSABuilds 的安装目录 MagiskOnWSA/installer 下分别维护了x64/与arm64/两套安装脚本各含Install.ps1与MakePri.ps1进一步印证了安装流程的架构差异化。关键证据在 MagiskOnWSA/installer/Install.ps1脚本解析当前目录下的AppxManifest.xml从中读取包的ProcessorArchitecture属性然后只对与当前架构一致的依赖包执行版本校验与安装[xml]$Xml Get-Content .\AppxManifest.xml; $Name $Xml.Package.Identity.Name; $ProcessorArchitecture $Xml.Package.Identity.ProcessorArchitecture; $Dependencies $Xml.Package.Dependencies.PackageDependency; $Dependencies | ForEach-Object { $InstalledVersion Get-InstalledDependencyVersion -Name $_.Name -ProcessorArchitecture $ProcessorArchitecture; ... Add-AppxPackage -ForceApplicationShutdown -ForceUpdateFromAnyVersion -Path $($_.Name)_$ProcessorArchitecture.appx }也就是说预构建包的架构在打包时就已经固化在AppxManifest.xml中。若你在 x64 系统上拿到了 arm64 包安装器拿到的ProcessorArchitecture是arm64其后续的Add-AppxPackage -Register .\AppxManifest.xml注册步骤就会因平台不符而抛出 0x80073D10 一类的部署错误。三、解决方案三步走以下为官方修复文档给出的标准修复流程完整继承如下。第 1 步回到 Release 页重新核对下载包前往本仓库WSABuilds的Release / 最新版本页面仔细检查你下载的资产Assets是否与自己的电脑环境匹配。这是最容易被忽略的一步——不少用户下载了错误的资产文件而不自知。第 2 步选择与你操作系统OS和 CPU 架构匹配的包在 Release 的 Assets 列表中认准同时满足以下两个条件的文件操作系统Windows 10 还是 Windows 11两者有对应的独立构建产物部分版本对 Win10/Win11 的支持状态不同可参考 Documentation/WSABuilds/Information.md 中的版本兼容性表CPU 架构x64 还是 arm64与你的电脑架构严格一致。注意Source code源码包不是可安装的 WSA 构建请勿下载。第 3 步下载后按安装指南完成安装下载正确的包后按照 Documentation/WSABuilds/Installation.md 的安装流程操作解压.7z归档 → 将解压出的文件夹重命名为WSA长文件夹名可能导致 WSA 无法启动→ 移动至合适位置后续使用期间不能删除该文件夹→ 双击Run.bat完成注册与安装。四、安装流程底层原理从 Run.bat 到 Appx 注册理解修复方案的原理有助于你在架构正确时依然从容排查同类部署错误。WSABuilds 的安装链路如下Run.bat仅作启动器MagiskOnWSA/installer/Run.bat 会先检查同目录是否存在Install.ps1随后以powershell.exe -ExecutionPolicy Bypass -File .\Install.ps1拉起 PowerShell 安装脚本Install.ps1完成整个部署MagiskOnWSA/installer/Install.ps1 依次执行检测管理员权限并自动提权非管理员时以-Verb RunAs重启自身检查filelist.txt所列文件是否齐全可选调用MakePri.ps1合并资源写入AllowDevelopmentWithoutDevLicense开发部署注册表项确保VirtualMachinePlatform功能已启用未启用会提示重启按AppxManifest.xml中的架构信息安装/校验依赖包若检测到已安装的 WSA先询问卸载旧包更新场景会保留用户数据最后执行Add-AppxPackage -ForceApplicationShutdown -ForceUpdateFromAnyVersion -Register .\AppxManifest.xml注册 WSA 主包并打开 Magisk 与 Play 商店。其中依赖包也是按架构分别下载的。从 MagiskOnWSA/scripts/generateWSALinks.py 可见脚本对Microsoft.VCLibs..._{arch}、Microsoft.UI.Xaml..._{arch}等依赖文件名做了架构正则匹配——架构一旦选错依赖包的文件名与内容都会对不上部署自然失败。五、如何确认自己电脑的 CPU 架构在重新下载前请务必先确认本机架构避免再次下载错误的包。以下任选其一PowerShell / CMD执行echo %PROCESSOR_ARCHITECTURE%CMD或$env:PROCESSOR_ARCHITECTUREPowerShell输出AMD64即为 x64 架构输出ARM64即为 arm64 架构设置界面设置 → 系统 → 关于在「系统类型」一栏查看「基于 x64 的处理器」或「基于 ARM 的处理器」WMIC执行wmic cpu get architecture查看处理器架构部分较新系统上该命令可能被弃用可改用 PowerShell 的Get-CimInstance Win32_Processor | Select-Object Architecture。确认架构后再去 Release 页面选择与之一致的资产。六、架构错配的常见诱因与避坑要点结合社区常见反馈0x80073D10 的诱发场景通常包括在x64 台式机/笔记本上误下..._arm64结尾的包反之亦然分不清 Windows 10 与 Windows 11 的构建产物下载了另一系统版本的包从旧版本或第三方渠道获取包未核对包内AppxManifest.xml的ProcessorArchitecture将 Windows 11 的包强行装到 Windows 10或反之导致注册阶段出现其他 0x80073xxx 部署错误。避坑要点只在官方 Release 的 Assets 中选择命名与你的OS 架构完全一致的资产若不确定版本稳定性可参照 Documentation/WSABuilds/Information.md 中的 ✅稳定/ ⚠️不稳定/ ⛔不可用指示避开标红版本保留解压后的WSA文件夹不被删除——Add-AppxPackage -Register注册的是未打包的现有文件删除文件夹将导致 WSA 无法使用。七、架构无误但安装仍失败按此通用流程诊断如果架构已确认匹配、Run.bat依然报 0x80073D10 或其他 0x80073xxx 错误可进入诊断流程需要管理员权限打开管理员 PowerShell切换到 WSA 解压目录执行Add-AppxPackage -ForceApplicationShutdown -ForceUpdateFromAnyVersion -Register .\AppxManifest.xml失败时会输出一个ActivityIDUUID执行Get-AppPackageLog -ActivityID uuid查看失败日志根据日志定位原因。此外仓库还整理了针对不同 0x80073 系列错误的专项修复文档可对照你的错误码查阅Fix Error 0x80073CF0Fix Error 0x80073CF6Fix Error 0x80073CF9Fix Error 0x80073CFBFix Error 0x80073CFD若仍无法解决可参考 Documentation/WSABuilds/Having Issues.md 与 Documentation/WSABuilds/Troubleshooting.md 获取进一步排查指引。八、小结0x80073D10 是 WSA 安装环节中最典型的架构错配型部署错误。修复它的关键不在于改动任何脚本而在于下载阶段选对与 OS 和 CPU 架构匹配的安装包先通过%PROCESSOR_ARCHITECTURE%确认本机架构再到 Release 页核对资产名称最后按安装指南解压并运行Run.bat即可。理解了 MagiskOnWSA/installer/Install.ps1 中按AppxManifest.xml的ProcessorArchitecture注册依赖与主包的机制后你也能举一反三将同样的架构意识应用到后续的 WSA 更新与重装中。【免费下载链接】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），仅供参考
