简介：Windows系统下Microsoft Store缺失或无法正常使用时，可在PowerShell中搜索不到商店或打开报错，此压缩包即为此类故障提供离线修复方案，适合普通用户与运维人员快速还原商店功能。压缩包共17个文件，大小65.87MB，包含WindowsStore与系统依赖组件的appx、appxbundle安装包，可配合Install.cmd等cmd脚本完成批量部署；xml文件为应用配置，txt与url则提供安装指引和极速软件下载入口。目前已有17831人学习下载，资源内附安装说明，避免用户自行查找各依赖项，按脚本执行即可完成安装。该包还集成了VCLibs、NET Native、Desktop AppInstaller等必要运行库，可解决因组件缺失导致的商店白屏或无法启动问题，同时提供计算器等其他商店应用包，便于一次性恢复常用UWP应用，整体实用性较强。

1. microsoft store 安装包不是一种东西：先分清你要的是商店本体还是商店应用

日常搜索“microsoft store安装包”的人，手里握着的其实有完全不同的三件事：商店本体被搞坏了想重装、公司内网要离线部署商店里的某个应用、应用装完想把数据挪到 D 盘。这三件事解决路径差异很大，但指向同一个核心——找到并处理 .msix / .appx 离线包。我在给客户做离线部署时，遇到的第一个翻车点就是用户把“商店应用安装包”和“商店本体的安装包”混为一谈，后面所有命令都跟着错了。这篇按“抓包、装包、排错、转移路径、验证”的顺序讲，适合桌面运维、企业批量装机工程师，也适合自己电脑商店崩了想手动恢复的人。

2. 用 rg-adguard 抓商店离线安装包：从 CDN 链接到签名校验

商店里的应用没有一个“下载安装包”按钮，所以拿不到离线的 .msix 是很多人的第一道坎。常见做法是借助第三方链接生成器 rg-adguard：把商店应用页面的链接粘进去，它会列出微软 CDN 上的包地址，生成的文件仍保有微软官方数字签名。下面几小节分别是生成、识别、下载和排错。

2.1 粘贴商店应用地址，生成完整的 CDN 文件列表

在能访问微软 CDN 的电脑上打开 rg-adguard 站点，左侧输入框粘贴商店应用的详情页链接。链接有两种取法：在商店里搜索应用，点“共享”按钮复制链接；或者在浏览器里打开商店网页版，把地址栏 URL 直接粘过来。粘贴后，在通道下拉框选“Retail”，不要选“Insiders Fast/Slow”。测试通道的包带有预发布签名框架，装到正式系统上会报版本不匹配，而且后续商店不会自动识别为同一条线。

点击生成后，页面会列出几十条文件记录。记录不是单纯按字母排列，而是把主包、依赖、可选资源包混在一起。我一般按 Ctrl+F 搜索包全名的关键词，比如装商店本体就搜Microsoft.WindowsStore，装某个工具就搜它的 PackageFamilyName。列表里的每一行都是一条 CDN 直链，可以用浏览器直接下载，也可以复制到命令行工具里批量拉取。

有一点容易误判：rg-adguard 本身不重新打包，它只是把微软 CDN 上存在的包地址过滤出来，所有包的数字签名仍是微软的。这意味着离线部署之后，系统依然认为应用来自官方来源，不需要临时打开开发者模式。如果你在某个工具站下载了重打包的 .appx，那性质和这里说的方法完全不同，也不建议用，因为签名被改过，装完很容易闪退。

2.2 看懂包名和版本：挑选主包、依赖包和架构后缀

离线包文件命名不是随便写的，能读懂文件名，比盲目把所有文件都下载下来再试装要高效得多。典型的商店主包名长这样：

Microsoft.WindowsStore_22310.1401.2.0_x64__8wekyb3d8bbwe.msixbundle

拆开看，Microsoft.WindowsStore是包的注册名，22310.1401.2.0是四段版本号，x64是架构，8wekyb3d8bbwe是发布者哈希后缀。版本号里重点看前两段，后两段大多是维护号，对离线部署影响不大。架构字段只会有x64、x86、arm64、neutral四种，其中neutral表示架构无关。最常见的选择是带_neutral_的 bundle，一个包覆盖所有架构。

依赖包的选择原则是和主包同版本体系、同架构。比如列表里同时出现VCLibs.x64.14.00.Desktop.appx和VCLibs.x64.14.00.UWPDesktop.appx，优先取 Desktop 版，它更适合传统桌面环境。不要顺手装 Debug 版，那是给开发调试用的，装到正式系统不但占空间，还可能干扰后续更新。

2.3 用 curl.exe 下载离线包，再做签名和哈希校验

从列表抄下链接后，不要用浏览器直接另存为，后期脚本化会很麻烦。Windows 10 自带 curl.exe，但 PowerShell 里的curl是个别名，指向Invoke-WebRequest，参数完全不兼容。所以在 PowerShell 里要写curl.exe，否则你会发现-L参数直接报错。

curl.exe -L -o "C:\store-offline\Microsoft.WindowsStore_22310.1401.2.0_x64__8wekyb3d8bbwe.msixbundle" "https://tlu.dl.delivery.mp.microsoft.com/filestreamingservice/files/生产环境拉到的直链写在这里"

-L负责跟随 CDN 跳转，-o指定保存文件名。文件名我一般不改，保留原始包名，方便后续日志对照版本和架构。如果是一次拉多个包，可以把多行curl.exe写进一个.bat逐行执行，CDN 链接不依赖商店登录态。

下载后的第一个动作是校验签名，而不是急着安装。签名校验能提前拦掉来源不明的安装包：

Get-AuthenticodeSignature "C:\store-offline\*.msixbundle" | Select-Object Status, SignerCertificate

正常结果里Status是Valid，签名者证书主题能看到Microsoft Windows或Microsoft Corporation。如果Status是NotTrusted或HashMismatch，直接删掉重下，不要尝试强制安装。还可以补一个 SHA256 校验：

Get-FileHash C:\store-offline\*.msixbundle -Algorithm SHA256 | Format-List

这个哈希值并不需要和某张官方表比对，它的作用是：当你把包传到一个杀毒软件比较敏感的内网机器上时，如果安装后文件被拦截，对比哈希就能立刻发现文件被动过。

2.4 抓包页面空白或列表为空时的排查方向

rg-adguard 偶尔会生成失败，页面一片空白，或者列表只有几条无关记录。最常见原因有三个：浏览器拦截了第三方脚本、目标商店地址本身在网页端显示不正常、生成器所在通道暂时无法从你当前网络回源到 CDN。排查时先开浏览器无痕窗口重新粘贴一次；不行就换一个商店应用链接试试，确认是不是单个页面的问题。

如果所有页面都生成不出来，问题大概率在网络出口。公司防火墙或安全代理会过滤非浏览器 user-agent 的请求，导致生成器只拿到半截响应。这种情况不要改成手动构造 CDN 链接，成功率很低，更现实的做法是让用户把商店网页版链接发给你，带回家里的普通网络环境生成好，再把包放到 U 盘带到内网。离线包本身不绑定机器，在哪台电脑抓都行，只要架构和版本范围对得上。

3. 本地安装商店离线包：Add-AppxPackage 参数、依赖顺序和批量脚本

拿到离线包之后的部署，在 Windows 上只有一条正道：Add-AppxPackage。很多教程会让人双击 .msix 来装，但双击只适合全新安装且依赖齐全的简单场景；覆盖老版本、批量分发、指定不卸载旧包，全都要走命令行。这一章从最小命令讲到批量脚本，照着执行即可。

3.1 最小可用命令：一次装齐主包和依赖

假设主包和依赖都放在C:\store-offline目录下，最稳妥的一条安装命令如下：

Add-AppxPackage -Path "C:\store-offline\App.msixbundle" ` -DependencyPath "C:\store-offline\Microsoft.VCLibs.x64.14.00.Desktop.appx", ` "C:\store-offline\Microsoft.NET.Native.Framework.2.2.appx" ` -ForceUpdateFromAnyVersion -ForceApplicationShutdown

这个命令必须在管理员身份的 PowerShell 里执行，普通窗口会直接报权限错误。-Path指向主包；-DependencyPath接受多个依赖包路径，用英文逗号分隔，一条命令同时处理；-ForceUpdateFromAnyVersion用来覆盖已经安装的旧版本，没有这个参数时，如果已装版本比离线包还要新，系统会拒绝降级；-ForceApplicationShutdown会在安装前强制关闭占用应用文件的进程，比如商店本体正开着的时候装商店离线包，这个参数能省去手动退出。

命令执行完没有任何红色输出就是成功。如果报错，把错误码原样记下来，后续章节按错误码排查。有一点要注意：命令行里反引号是续行符，复制时如果丢了反引号，整个命令会被拼成一行，参数解析会乱。我习惯把参数写在同一行，只要不太长就尽量避免依赖续行符。

3.2 依赖为什么总要“先装”：连锁依赖与架构匹配

-DependencyPath本身会“一并注册”，但在实际部署中，我仍然习惯先把依赖包逐个装好，再装主包。原因有两层。

第一，依赖包之间存在隐式的版本要求。举例来说，某个应用需要 .NET Native Framework 2.2，而 2.2 框架又依赖 UI.Xaml 2.8。你只把 2.2 放进-DependencyPath，系统找不到底层依赖时照样报 0x80073CF3。分开装，日志能直接定位到是哪一个框架出了问题。

第二，商店离线包里的依赖包经常好几个月不更新，同一个包可能出现在多个 bundle 里。先装依赖，再装主包，能避免一次性注册多个同家族包时偶发的“某个包部署失败但不知道为什么”。依赖预装命令我一般这样写：

$deps = @( "C:\store-offline\Microsoft.VCLibs.x64.14.00.Desktop.appx", "C:\store-offline\Microsoft.NET.Native.Framework.2.2.appx", "C:\store-offline\Microsoft.UI.Xaml.2.8.x64.appx" ) foreach ($d in $deps) { if (Test-Path $d) { Add-AppxPackage -Path $d -ForceUpdateFromAnyVersion } } Add-AppxPackage -Path "C:\store-offline\Main.msixbundle" -ForceUpdateFromAnyVersion

这段代码先遍历依赖数组，每个依赖单独安装并忽略已存在版本，最后装主包。依赖装完回头看输出，如果某个依赖报“更高版本已安装”，说明机器的框架版本已经领先，不必强行降级；如果报的是架构不匹配，比如 x64 系统装 x86 依赖，那么包列表里一定还有对应 x64 版本，重新下载即可。

3.3 批量静默部署：目录分拣加结果日志

内网几十台机器要装同一批商店应用时，一条条敲命令不现实。我更推荐把离线包目录整理成“依赖先装、主包后装”的约定，再用脚本统一处理。目录结构这样安排：

C:\store-offline\deps\ # 只放依赖包 C:\store-offline\apps\ # 只放主包

部署脚本如下：

$src = "C:\store-offline" $log = "$src\deploy-$(Get-Date -Format yyyyMMdd-HHmmss).log" Get-ChildItem "$src\deps\*" -Include *.appx,*.msix,*.msixbundle | ForEach-Object { try { Add-AppxPackage -Path $_.FullName -ForceUpdateFromAnyVersion -ErrorAction Stop Add-Content $log "$($_.Name) => $(Get-Date -Format s)" } catch { Add-Content $log "$($_.Name) => $($_.Exception.Message)" } } Get-ChildItem "$src\apps\*" -Include *.msixbundle,*.msix,*.appx | ForEach-Object { try { Add-AppxPackage -Path $_.FullName -ForceUpdateFromAnyVersion -ErrorAction Stop Add-Content $log "$($_.Name) => $(Get-Date -Format s)" } catch { Add-Content $log "$($_.Name) => $($_.Exception.Message)" } }

-Include要和Get-ChildItem搭配，只对文件通配有效，所以前一个-Path "$src\deps\*"不能用文件夹本身。-ErrorAction Stop让每个包的失败都能被catch捕获，否则 PowerShell 遇到非终止错误会继续跑，日志里抓不到问题。脚本执行完查看deploy-*.log，失败的包名和错误信息都在里面。首次运行前先确认策略允许执行脚本：

Set-ExecutionPolicy -Scope Process RemoteSigned

这个设置只在当前 PowerShell 窗口生效，不改系统全局策略，适合临时跑内部脚本。

3.4 装坏了怎么回滚：Remove-AppxPackage 与残留清理

离线包装错版本后，系统的“应用”设置里有时会有卸载按钮，但更稳妥的是命令行直接卸载。命令形式如下：

Get-AppxPackage -Name "Microsoft.WindowsStore" | Remove-AppxPackage

卸载商店本体要谨慎，卸载后设置页面里不会再显示商店，只能通过离线包重新安装。如果你只是想回滚某个误装的普通应用，先查一下当前包名：

Get-AppxPackage | Where-Object { $_.Name -like "*VCLibs*" }

确认后再卸载。卸载后有些残留文件依然在C:\Program Files\WindowsApps里，这是系统保护目录，不要手工删。正常情况下重新安装同版本包会覆盖残留；如果重装时报“包已存在”，可以先去应用设置里看该应用是否还在，把“高级选项 → 重置”先跑一遍，再重新安装。清理残留这件事，Windows 自带的部署服务做得比人可靠，越少手工干预越好。

4. 避坑排查：商店安装包最常见的四个部署错误

离线包部署的错误码很吓人，但根因往往就几类：权限、依赖、版本、签名。下面按“现象 → 原因 → 解决”写，方便你对着错误码直接查。

4.1 0x80070005 权限拒绝：先查部署服务，再清临时目录

现象：PowerShell 执行 Add-AppxPackage 时报0x80070005，日志写Access is denied，常见于给商店本体更新或安装第三方应用。原因多数不是“当前用户不是管理员”，而是 AppX 部署服务没有运行，或安全软件锁了临时目录。解决分三步：

Get-Service AppXSvc Set-Service -Name AppXSvc -StartupType Manual Start-Service AppXSvc

然后清理 C:\Windows\Temp 下明显残留的旧 .msix、.appx 临时副本，注意不要动 WindowsApps 目录里的已安装文件。最后重新用管理员身份打开 PowerShell 执行安装命令。如果还报，检查组策略里有没有“允许所有受信任的应用安装”，有则改为“未配置”，并确认当前用户确实在 Administrators 组里。

4.2 0x80073CF3 缺依赖：不要反复重装主包，补框架就行

现象：安装主包时报0x80073CF3，部署日志里能看到The package requires one or more frameworks。原因就是依赖缺失。解决不是换个版本重下主包，而是回去下载匹配的 VCLibs、.NET Native Framework 或 UI.Xaml，按 3.2 节的方式先装依赖。如果依赖包已经放在-DependencyPath里仍报同样错误，检查依赖包架构：x64 系统配上 x86 依赖包，照样报这个错误。把依赖换成 x64 或 neutral 后重试。

4.3 0x80073D0F 版本或架构不匹配：核对系统版次和包名后缀

现象：安装时提示Package could not be registered，日志出现0x80073D0F。原因通常是包要求的系统版本比当前 Windows 高，或者架构不对。商店在线安装时有系统“最低版本”过滤，不会让你装上不兼容的包；但离线包没有这层过滤，你可能抓到的是 Windows 11 专属包，再装到 Windows 10 上。解决：抓包时看文件名中的版本号，对照当前系统的winver结果。拿不准时选列表里较早的版本，不要追新。另一个常见来源是开发者通道包，正式系统不认识其签名结构，也会报类似错。

4.4 0x80080109 签名与信任：部署前先查签名，拦下一批坏包

现象：部署日志出现The package is unsigned或Publisher cannot be verified，部分机器弹窗提示需要开启“旁加载”或“开发者模式”。原因：包来源不是微软 CDN，而是二次打包过，签名被覆盖。解决：执行Get-AuthenticodeSignature确认Status=Valid，签名者必须是 Microsoft。如果系统开了 AppLocker 或 WDAC，即使签名有效也可能因策略没放行而失败。这时不要图省事关闭整个策略，正确做法是把对应发布者证书加入允许规则。证书指纹可以在Get-AuthenticodeSignature返回的SignerCertificate对象里找到。

4.5 装完依然打不开：重置应用数据和商店缓存

现象：商店或某个应用安装成功，图标也在，但点击后一直转圈，或闪退回桌面。原因可能是旧缓存数据没有随安装包清理干净，或商店本体组件注册状态异常。解决先做应用级重置：在“设置 → 应用 → 已安装的应用 → 高级选项 → 重置”里点一次重置；重置不删除安装包，只清缓存和数据。商店本体还可以额外跑一次wsreset.exe，它是 Windows 自带的商店缓存清理工具，不会卸载商店。如果重置后仍打不开，再考虑用离线包覆盖安装一遍，让部署服务重新注册一次包清单。

5. 安装路径和换盘：把商店应用从 C 盘挪到 D 盘的边界

总有人搜索“microsoft store下载的软件设置到其他盘”，并期待安装包支持--install-dir。遗憾的是，MSIX 安装包本身没有路径参数，系统默认装到 C 盘 WindowsApps。这一章讲清楚路径约束，以及已安装应用换盘的两种姿势。

5.1 商店安装包没有“安装目录”参数，别找 --dir

UWP / MSIX 应用由系统托管，安装目标卷由“包卷”机制决定，而不是安装器里的选项。无论你用Add-AppxPackage还是双击安装包，都不会出现让你选目录的界面。如果一定要把应用装到其他盘，唯一能影响的是系统“新内容保存位置”。这个设置在“设置 → 系统 → 存储 → 高级存储设置 → 新的内容保存位置”，把“新的应用将保存到”改成 D 盘。改完之后，后续用Add-AppxPackage安装的新应用会落到 D 盘的系统级 WindowsApps 目录，这是官方支持的做法。

5.2 已装应用换盘：系统“移动”按钮比手工软链接可靠

对已经装好的应用，不要手工复制 WindowsApps 目录，也不要用mklink做符号链接，这会破坏包注册关系，下次商店更新必然翻车。系统原生的做法是在“已安装的应用”里找到目标应用，点“高级选项”，里面有“移动”按钮，可以把应用搬到你在“新的内容保存位置”里指定的盘。这块由部署服务自己处理文件迁移和注册信息，迁移完成后重启一次应用商店，确认图标不再转圈。

如果“移动”按钮是灰色，说明该应用注册了不允许移动的属性，此时任何手工强行搬迁都不建议。网上流传的“复制到 D 盘再删 C 盘 + mklink /J”做法，只适合少数不依赖系统服务的应用，而且你需要执行mklink /J "C:\目标目录" "D:\实际目录"绕过 WindowsApps 的 ACL，稍有不慎会触发“应用似乎已损坏”。我的态度很明确：宁可重新用离线包安装到 D 盘，也别对已装商店应用做软链接。

5.3 哪些应用能迁移，哪些动了就翻车

大型游戏、视频剪辑、非系统级的效率工具通常可以迁移；商店本体、Xbox Game Bar、手机连接助手这类系统集成组件绝对不要移动。即使“移动”按钮能用，下一次系统更新也可能把它们恢复到 C 盘，或直接触发修复流程。迁移后如果应用打不开，可以在“高级选项”里点“重置”，让系统把配置恢复到默认。但“重置”只恢复应用数据，不重新下载安装包，所以损坏严重的话，还是用离线包卸载重装一次更彻底。

5.4 迁移后的验证与误操作恢复

迁移完成后用第 6 章的验证命令查看InstallLocation，确认路径已经变成 D 盘对应目录。如果发现安装位置仍然在 C 盘，多半是因为目标卷没有被系统识别为可用应用卷，回“高级存储设置”确认 D 盘被勾选为内容保存位置。误迁移导致的打不开，可以在“高级选项”里先点“移动”挪回 C 盘，再尝试“重置”。这套流程虽然绕，但每一步都在系统机制内，不会留下隐患。

6. 验证安装结果：用状态字段和部署日志确认没装歪

安装命令没报错，不等于应用能用。我的习惯是任何一次离线包部署后，都跑一遍验证命令，确认 Version、Status 和 InstallLocation 都对得上才收工：

Get-AppxPackage -Name "Microsoft.WindowsStore" | Select-Object Name, Version, InstallLocation, Status

Status 显示 OK 是正常；如果显示InstallAttempted，表示上次安装没有成功，需要回头查部署日志。部署日志可以这样捞：

Get-AppxLog -All | Where-Object { $_.Message -match "error|failed" } | Select-Object -First 10

这条命令会把 AppX 部署服务记录的最近错误列出来，错误码和你在安装窗口看到的 0x80070005、0x80073CF3 一一对应，按第 4 章去处理即可。对于批量脚本，我会额外把每台机器的Get-AppxPackage输出导出成 CSV，比对离线包目录里的版本号，确保没有漏装：

Get-AppxPackage | Select-Object Name, Version, InstallLocation, Status | Export-Csv "C:\store-offline\result.csv"

最后一个进阶技巧：在部署前给离线包目录生成哈希清单，部署后对比应用文件哈希，可以在应用“安装成功但启动即闪退”时快速判断文件有没有被安全软件拦截替换：

Get-FileHash C:\store-offline\*.msixbundle -Algorithm SHA256 | Export-Csv C:\store-offline\hash.csv

这个技巧不是必须的，但我在内网部署时靠它排查过两次依赖包被杀软误删的问题，避免了一条条翻文件夹的重复劳动。如果你也经常和商店离线包打交道，建议把“先查签名，再看依赖，最后装主包”养成肌肉记忆，能省下一大半排错时间。希望帮到你。

本文还有配套的精品资源，点击获取