拓冰网站定制 
简介Windows 10 LTSC版本因追求精简稳定默认不包含Microsoft Store导致便笺、计算器等现代应用无法安装企业用户虽获得长期服务却在应用生态上受限。本资源正是面向这类用户通过内置组件包为系统添加Microsoft Store恢复应用商店及必要运行环境。包内共16个文件以Appx与AppxBundle应用包为主涵盖.NET Native框架、Visual C运行时、WindowsStore安装包、商店购买应用及Xbox身份验证等必需组件并附有XML配置文件、使用说明和Add-Store.cmd一键部署脚本整体大小67.23MB。脚本化方式降低手动配置门槛配合XML与README说明用户无需逐条执行命令即可完成安装也便于后续排查。该资源已有1551人学习下载适合需要兼顾系统精简性与常用应用可用性的企业或个人选用对于需要在稳定环境中按需扩展功能的运维人员也具备较高的实用价值。1. LTSC-Add-MicrosoftStore-2019先弄明白这个 7z 为什么存在一台刚装完 Windows 10 企业版 LTSC 2019 的机器任务栏没有商店图标开始菜单搜不到 Microsoft Store双击任何 UWP 安装包都没反应——这就是 LTSC 脱离半年通道后最直接的代价。LTSC-Add-MicrosoftStore-2019.7z 解决的就是这个“能不能装回来”的问题。它不是激活工具不是系统镜像替代品而是给 LTSC 2019 补回商店组件的一个离线包集合。适合所有跑 LTSC 2019 又想用商店应用的场景。想知道这东西能不能用、怎么做、坑在哪跟着下面的部署路径走一遍比来回搜零散帖子靠谱得多。2. LTSC 2019 与 Microsoft Store 的依赖关系这个包怎么下手2.1 LTSC 出厂时拆掉了哪几块Windows 10 企业版 LTSC 2019 的内核是 1809build 17763跟同期的专业版、企业版是同一代内核。专业版能直接跑商店不是因为商店只是个普通 Appx而是系统里常驻了一整套配套组件。LTSC 在镜像准备阶段拿掉了这些组件所以你在 LTSC 里打开设置、搜索“商店”看到的不是“被隐藏”而是“压根不存在”。缺的主要是四块。第一块是 Microsoft.WindowsStore 本体包这是商店的 Appx 主程序负责界面、账户登录、应用下载和更新调度。第二块是 AppX 部署服务AppXSvc和 StateRepository 服务前者负责 Appx 包的安装、卸载和权限管理后者维护包注册状态。专业版里这两个服务默认存在但 LTSC 2019 里它们经常是缺失或者被禁用状态。第三块是商店运行时依赖常见的是 Microsoft.VCLibs.140.00 和 Microsoft.NET.Native.Framework 这组框架包。商店的主包在启动和下载时都要调用这些运行时缺了它们主包即使强行部署成功打开也会闪退或者转圈。第四块是许可证与证书链。商店在下载应用时要做许可证校验部分定制镜像把根证书也一并清掉了这就导致后面部署时出现 0x80073CF9 这类签名信任报错。所以问题不是“少了一个软件”而是“少了一条链”。这也是为什么有些人直接去别的机器拷一个商店装进 LTSC 会失败——装进去的只是一个壳底层服务和依赖都没就位。2.2 这个 7z 包常见的内容与动作拆解手头这个 LTSC-Add-MicrosoftStore-2019.7z从命名看是面向 2019 版1809 内核的离线补齐包。这种包解压后通常由三部分构成一个批处理脚本常见名字是 Add-Store.cmd 或 Install.bat、一个或多个商店主包.Appx / .AppxBundle以及一个依赖目录里面是 VCLibs、.NET Runtime 等框架包。有的还会带一份 .reg 注册表文件用来恢复 AppXSvc 和 StateRepository 服务的启动状态。我不太建议直接双击那个批处理脚本。因为批处理把“装依赖、建服务、部署主包、清理”全封装在一起如果中间某一步失败窗口一闪而过你根本看不到报错在哪。我一般会把脚本打开先读一遍看它到底调了哪些命令然后手动分步执行。这么做的好处是每一步的失败点都清晰可见坏处是花的时间多一点但第一次做的话这个时间省不得。3. 把商店装进 LTSC 2019最小可复现的操作路径3.1 操作前的环境核查动手之前先做三分钟检查能筛掉一大半后续问题。先确认系统确实是 LTSC 2019。用winver弹窗看版本号或者直接跑注册表查询reg query HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion /v DisplayVersion reg query HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion /v CurrentBuildLTSC 2019 的对外版本号是 1809内部版本号是 17763。如果查出来是 19044 或 22631那这是 LTSC 2021 或者 Win11 的定制镜像不适合用 2019 的商店包后面会展开说。这一步错了后面再折腾都是白费力气。接着看一下商店本体和依赖在系统里目前是什么状态Get-AppxPackage -Name Microsoft.WindowsStore Get-AppxPackage -Name Microsoft.VCLibs.140.00 Get-AppxPackage -Name Microsoft.NET.Native.Framework正常状态下前一条应该没有任何输出后两条可能也没有。如果输出里有版本号说明这个系统不是原汁原味的 LTSC可能被精简过也可能本身是半成品镜像那后面部署策略要做调整。最后看一眼部署服务和状态服务sc query appxsvc sc query stateRepository注意LTSC 2019 里stateRepository服务名的写法比较特殊有的定制镜像里服务名可能叫StateRepository大小写不同不影响查询但服务不存在时会直接报“指定的服务未安装”。这一步的目的是确认部署主包前的底层服务是否就位没有的话后面Add-AppxPackage会死在半路。3.2 三段式部署命令与参数说明把 7z 解压后目录里应该有主包和依赖子目录。先在“设置 - 更新和安全 - 恢复”里创建一个系统还原点再继续。这一步很多人跳过等到装完商店导致系统组件状态异常时才后悔这是这类操作最值得花的三十秒。以管理员身份打开 PowerShell先装依赖包。依赖目录里通常有 x64、x86、ARM 几个子目录根据你系统的架构选绝大多数人是 x64Add-AppxPackage -Path C:\tools\LTSC-Add-MicrosoftStore-2019\Dependencies\x64\Microsoft.VCLibs.140.00_14.0.30704.0_x64__8wekyb3d8bbwe.Appx Add-AppxPackage -Path C:\tools\LTSC-Add-MicrosoftStore-2019\Dependencies\x64\Microsoft.NET.Native.Framework.2.2_2.2.29512.0_x64__8wekyb3d8bbwe.Appx这里用的是Add-AppxPackage单包安装。它会把 Appx 包注册到当前用户上下文中不需要额外提权服务器的参与。VCLibs 和 NET.Native 是商店主包的运行时底座顺序上必须先装。如果依赖文件名跟这不一样以实际解压出来的文件名为准不要照抄命令里的文件名。接着部署商店主包。主包通常是 .AppxBundle 或 .Appx 格式一个文件里可能包含多个架构的子包直接传主包文件即可Add-AppxPackage -Path C:\tools\LTSC-Add-MicrosoftStore-2019\Microsoft.WindowsStore_11910.1001.1.0_x64__8wekyb3d8bbwe.AppxBundle -ForceApplicationShutdown-ForceApplicationShutdown的作用是强制关停正在占用包文件的进程如果之前有过失败的安装残留这个参数能避免“文件被占用”的报错。如果主包部署后界面正常但打开闪退多半是依赖没装全或者是主包版本与 1809 内核不匹配不要急着找主包问题先回头看依赖。部分包还会要求你先注册到系统级对所有用户生效这时候要区分两个命令。Add-AppxPackage是给当前用户装的Add-AppxProvisionedPackage是把包预置到系统镜像里新建用户自动生效。多用户共用的机器建议用后者Add-AppxPackage -Path C:\tools\Microsoft.WindowsStore.AppxBundle -DependencyPath C:\tools\Dependencies -ForceApplicationShutdown -AllowDeploymentFallback-DependencyPath参数一次性把依赖目录里所有可用的依赖包一起解析安装省去手动逐条执行的繁琐。-AllowDeploymentFallback是允许部署引擎在严格策略失败时回退到宽松模式在遇到签名策略导致安装被拒时可以加上试一把。下表是部署时几个常用参数的速记参数作用建议-DependencyPath指定依赖包目录自动解析依赖主包和依赖混放时必用-ForceApplicationShutdown强制关闭占用包文件的进程有安装残留时必用-AllowDeploymentFallback允许回退部署策略信任校验报错时尝试-Scope AllUsers对所有用户安装多用户机器上使用-SkipLicense跳过许可证检查离线部署时可加3.3 首次启动与两个必调项商店包部署完之后先别急着打开。“开始菜单”里搜索“Store”如果能搜到图标说明包注册成功。首次打开时常见两个问题一是转圈半小时进不去二是提示“此应用无法在此设备上运行”。转圈的原因多半是商店在后台尝试连接更新服务而 LTSC 2019 的组件存储里没有足够的系统应用基底。不用等太久等两分钟后强制关掉商店再打开一次。如果还是转圈回到依赖安装那一步重点检查 VCLibs 是否装到了正确的架构上——x64 系统装了 x86 的 VCLibs 就会出现这类问题。“无法在此设备上运行”的原因大概率是服务没起来。到服务管理器里找到AppX Deployment Service (AppXSvc)确认启动类型是“手动”且状态是“已启动”。另外把Windows Update服务的启动类型设置为“手动”因为商店的许可证校验和下载调度依赖它。这两个服务调好后重启一次商店就好。4. 从 2019 到 2021LTSC 版本间商店包怎么选先说结论不同 LTSC 版本之间商店包不能随便混用。LTSC 2019build 17763、LTSC 2021build 19044、IoT 企业版 LTSC 2021这三者的商店 Appx 包从理论上讲不能跨版本互换原因在于商店包内部版本号跟系统内核的 API 集合是对齐的。一个为 17763 编译的商店包跑到 19044 的系统上轻则部署报错重则装上后商店任何页面都白屏。拿三者的默认状态做一个对比系统版本内核版本默认商店状态补装方式企业版 LTSC 201917763完全没有本 7z 方案或手动部署 1809 商店包企业版 LTSC 202119044完全移除设置 - 应用 - 可选功能中添加或手动部署 21H2 商店包IoT 企业版 LTSC 202119044部分版本可选启用镜像可选项或手动部署 21H2 商店包如果你的机器是 LTSC 2021网上搜“win10 ltsc 2021 添加商店”会看到不少结果常见做法是先试系统自带的“可选功能”入口设置 - 应用 - 可选功能 - 添加功能 - 应用商店。这一步比任何手动部署都稳因为走的是组件存储原生路径。只有这个方法失败时才考虑手动拿 21H2 的商店包部署而不是反过来先手动装。“投影到此电脑”这类功能不要指望商店包顺手解决。它是独立的无线显示组件在系统里属于“功能按需加载FoD”体系跟应用商店是两个完全不同的安装路径。网上有人给 LTSC 2021 添加投影功能做法是去“可选功能”里加“无线显示”或者用 DISM 从原版镜像的 FoD 目录里回填。这个需求和“添加商店”混在一起搜索的人不少但两个话题不能互相替代。另外提醒一句Office LTSC ISO 和这个商店工具包完全是两回事。Office LTSC 装的是经典 Win32 应用不依赖 Appx 运行时。不要因为下载了 Office LTSC 的 ISO 就以为里面带的证书、许可文件能用来解决商店的信任报错协议体系不同。5. 添加 Microsoft Store 的避坑记录现象、原因、解决5.1 商店装好了但一直转圈进不去这个现象在 LTSC 2019 上特别多。安装完成后点击图标页面一直转圈过几分钟后提示“请检查网络连接”。原因通常是两类一是依赖包不完整VCLibs 或 .NET Runtime 缺了某一个商店启动后做完整初始化时卡住二是 AppXSvc 服务状态不对被设定为禁用后商店主程序无法完成自身的激活请求。解决方法是先停掉商店进程到服务管理器确认AppXSvc已启动并把启动类型改为“手动”然后从开始菜单重新打开商店。如果依旧转圈回看依赖安装结果逐项执行一遍Get-AppxPackage -AllUsers | Where-Object {$_.Name -like Microsoft.VCLibs* -or $_.Name -like Microsoft.NET.Native*} | Select-Object Name, Version这里能直接看出依赖包是否真的装上了。转圈问题里十有八九是 vclibs 返回为空。装好之后顺手重启一次系统再开商店。5.2 wsappx 进程 CPU 占用居高不下商店装好后的第二天任务管理器里 wsappx 一直占 CPU二三十起步有时候冲到五六十。wsappx 是 Appx 部署服务AppXSvc关联的进程它做的是包部署和系统组件评估。在 LTSC 2019 上这个进程常驻占用高原因是系统里缺了不少商店相关的可选组件wsappx 启动后反复尝试做全量应用清单扫描每次都扫不到完整目标于是陷入循环重试。先别急着禁用它。禁用 AppXSvc 虽然能让 CPU 掉下来但商店后续会无法安装任何应用等于功能白加了。正确做法是让它把活干完检查一次应用清单等几分钟看它是否自动回落。如果持续高占用超过十分钟就执行商店自带的“重置”功能设置 - 应用 - 应用商店 - 高级选项 - 重置。重置后 wsappx 会重新做一次完整评估占用率会明显下降。这一步是少有的“等它自己好”的场景不要急着删除服务或改注册表。5.3 部署时报 0x80073CF9 或 0x80073CF30x80073CF9 是“包已存在但状态损坏”的典型报错。常见于之前有过一次失败的安装系统里残留了半注册状态的商店包。0x80073CF3 则是依赖缺失部署引擎找不到主包所需的框架。先说 0x80073CF3。这个不用换主包回头把依赖装全再重新部署主包。注意依赖包也有架构之分x64 系统装了 x86 的 VCLibs部署引擎不一定报错但后续运行时会闪退所以装之前看一眼包名里的架构后缀。0x80073CF9 的处理是先卸载残留再重新部署。用下面的命令找出系统里残留的商店包记录Get-AppxPackage -AllUsers -Name Microsoft.WindowsStore | Remove-AppxPackage执行完后再跑一次部署。如果卸载时报错说包不存在但主包部署时又说包已存在这时候要考虑是包注册记录残留在注册表里。用 PowerShell 吧 StateRepository 数据库打开清理不现实最省事的办法是换个路径重新解压 7z 再部署因为常见情况是安装记录指向上一次解压目录那个目录已经被删了。5.4 双击批处理一闪而过没有任何输出这种翻车场景是最让人头疼的因为没有任何报错信息。原因一般是两种情况脚本里用了管理员提权指令而系统 UAC 被组策略关掉导致runas调用失败或者是脚本在含中文的路径下执行批处理解析路径出错直接退出。解决方法是别双击改成手动逐条执行把路径全部改到纯英文目录下。解压后的完整路径尽量不要有中文和空格C:\tools\这种简单路径最稳妥。另外有些杀毒软件会拦截批处理里写注册表或修改服务的操作导致脚本执行到一半退出解除拦截后重新执行。5.5 装了包但商店闪退一查是包版本跨系统混用把 2019 的商店包硬装到 LTSC 2021或者反过来表现就是“能装上但是打开闪退”。闪退是 Appx 包在初始化时调用了当前系统里不存在的 API 接口导致的属于硬不兼容。闪退比部署报错更难排查因为事件查看器里只会留一条“应用程序崩溃”记录细节信息有限。排查步骤是先确认系统版本确实匹配包名里的年份标签再用事件查看器里的“应用程序”日志查看崩溃模块路径。如果崩溃模块指向商店主包自身那基本可以确定是版本不匹配去下载对应内核版本的包即可。6. 装完后的验证方法与迭代习惯装完商店不意味着收工我会花三分钟做验证确认它不是“看起来正常”。验证分三步。第一步检查包是否完整注册Get-AppxPackage -Name Microsoft.WindowsStore | Select-Object Name, Version, Status输出的 Status 必须是 Ok。如果显示 NotPresent 或 DependencyIssue说明注册有问题需要重新部署。第二步从商店里下载一个轻量 UWP 应用做实际测试首选“微软待办”这类纯 UWP 应用。下载能成功、安装能跑起来才说明商店的下载通道、许可证校验、部署回调全链路正常。如果你只是打开了商店但什么都不装一些隐患会藏在后面。第三步确认关键服务没有异常重启。在事件查看器里看Microsoft-Windows-AppXDeploymentServer/Operational日志筛选错误级别事件确认没有反复刷新的报错条目。我的个人习惯是把这些步骤沉淀成一个文本文件跟解压出来的包放在一起记录当时的系统版本、build 号、部署命令、依赖包的版本号。这样做的原因是这类工具包往往被下载后存在硬盘里半年后再拿出来用时会忘记当时是怎么装成功的某个参数不一样就可能导致部署失败。有这份记录重装系统后照着走一遍就行不用重新摸索。顺便说一句Office LTSC 的 ISO 和商店的 Appx 包不要混放混淆前者是微软 Office 产品线后者是系统组件两者在文件格式和部署路径上没有任何交叉。这算是我踩过几次坑之后留下来的习惯。现在每次拿到这类补商店的压缩包我第一件事是看目录结构和系统版本第二件事就是先看服务状态而不是先双击脚本。希望这次写到的部署路径和排查顺序能帮你少走几趟弯路。本文还有配套的精品资源点击获取 Windows 10 LTSC 2019 如何添加 Microsoft Store：离线包部署与故障排查
简介Windows 10 LTSC版本因追求精简稳定默认不包含Microsoft Store导致便笺、计算器等现代应用无法安装企业用户虽获得长期服务却在应用生态上受限。本资源正是面向这类用户通过内置组件包为系统添加Microsoft Store恢复应用商店及必要运行环境。包内共16个文件以Appx与AppxBundle应用包为主涵盖.NET Native框架、Visual C运行时、WindowsStore安装包、商店购买应用及Xbox身份验证等必需组件并附有XML配置文件、使用说明和Add-Store.cmd一键部署脚本整体大小67.23MB。脚本化方式降低手动配置门槛配合XML与README说明用户无需逐条执行命令即可完成安装也便于后续排查。该资源已有1551人学习下载适合需要兼顾系统精简性与常用应用可用性的企业或个人选用对于需要在稳定环境中按需扩展功能的运维人员也具备较高的实用价值。1. LTSC-Add-MicrosoftStore-2019先弄明白这个 7z 为什么存在一台刚装完 Windows 10 企业版 LTSC 2019 的机器任务栏没有商店图标开始菜单搜不到 Microsoft Store双击任何 UWP 安装包都没反应——这就是 LTSC 脱离半年通道后最直接的代价。LTSC-Add-MicrosoftStore-2019.7z 解决的就是这个“能不能装回来”的问题。它不是激活工具不是系统镜像替代品而是给 LTSC 2019 补回商店组件的一个离线包集合。适合所有跑 LTSC 2019 又想用商店应用的场景。想知道这东西能不能用、怎么做、坑在哪跟着下面的部署路径走一遍比来回搜零散帖子靠谱得多。2. LTSC 2019 与 Microsoft Store 的依赖关系这个包怎么下手2.1 LTSC 出厂时拆掉了哪几块Windows 10 企业版 LTSC 2019 的内核是 1809build 17763跟同期的专业版、企业版是同一代内核。专业版能直接跑商店不是因为商店只是个普通 Appx而是系统里常驻了一整套配套组件。LTSC 在镜像准备阶段拿掉了这些组件所以你在 LTSC 里打开设置、搜索“商店”看到的不是“被隐藏”而是“压根不存在”。缺的主要是四块。第一块是 Microsoft.WindowsStore 本体包这是商店的 Appx 主程序负责界面、账户登录、应用下载和更新调度。第二块是 AppX 部署服务AppXSvc和 StateRepository 服务前者负责 Appx 包的安装、卸载和权限管理后者维护包注册状态。专业版里这两个服务默认存在但 LTSC 2019 里它们经常是缺失或者被禁用状态。第三块是商店运行时依赖常见的是 Microsoft.VCLibs.140.00 和 Microsoft.NET.Native.Framework 这组框架包。商店的主包在启动和下载时都要调用这些运行时缺了它们主包即使强行部署成功打开也会闪退或者转圈。第四块是许可证与证书链。商店在下载应用时要做许可证校验部分定制镜像把根证书也一并清掉了这就导致后面部署时出现 0x80073CF9 这类签名信任报错。所以问题不是“少了一个软件”而是“少了一条链”。这也是为什么有些人直接去别的机器拷一个商店装进 LTSC 会失败——装进去的只是一个壳底层服务和依赖都没就位。2.2 这个 7z 包常见的内容与动作拆解手头这个 LTSC-Add-MicrosoftStore-2019.7z从命名看是面向 2019 版1809 内核的离线补齐包。这种包解压后通常由三部分构成一个批处理脚本常见名字是 Add-Store.cmd 或 Install.bat、一个或多个商店主包.Appx / .AppxBundle以及一个依赖目录里面是 VCLibs、.NET Runtime 等框架包。有的还会带一份 .reg 注册表文件用来恢复 AppXSvc 和 StateRepository 服务的启动状态。我不太建议直接双击那个批处理脚本。因为批处理把“装依赖、建服务、部署主包、清理”全封装在一起如果中间某一步失败窗口一闪而过你根本看不到报错在哪。我一般会把脚本打开先读一遍看它到底调了哪些命令然后手动分步执行。这么做的好处是每一步的失败点都清晰可见坏处是花的时间多一点但第一次做的话这个时间省不得。3. 把商店装进 LTSC 2019最小可复现的操作路径3.1 操作前的环境核查动手之前先做三分钟检查能筛掉一大半后续问题。先确认系统确实是 LTSC 2019。用winver弹窗看版本号或者直接跑注册表查询reg query HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion /v DisplayVersion reg query HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion /v CurrentBuildLTSC 2019 的对外版本号是 1809内部版本号是 17763。如果查出来是 19044 或 22631那这是 LTSC 2021 或者 Win11 的定制镜像不适合用 2019 的商店包后面会展开说。这一步错了后面再折腾都是白费力气。接着看一下商店本体和依赖在系统里目前是什么状态Get-AppxPackage -Name Microsoft.WindowsStore Get-AppxPackage -Name Microsoft.VCLibs.140.00 Get-AppxPackage -Name Microsoft.NET.Native.Framework正常状态下前一条应该没有任何输出后两条可能也没有。如果输出里有版本号说明这个系统不是原汁原味的 LTSC可能被精简过也可能本身是半成品镜像那后面部署策略要做调整。最后看一眼部署服务和状态服务sc query appxsvc sc query stateRepository注意LTSC 2019 里stateRepository服务名的写法比较特殊有的定制镜像里服务名可能叫StateRepository大小写不同不影响查询但服务不存在时会直接报“指定的服务未安装”。这一步的目的是确认部署主包前的底层服务是否就位没有的话后面Add-AppxPackage会死在半路。3.2 三段式部署命令与参数说明把 7z 解压后目录里应该有主包和依赖子目录。先在“设置 - 更新和安全 - 恢复”里创建一个系统还原点再继续。这一步很多人跳过等到装完商店导致系统组件状态异常时才后悔这是这类操作最值得花的三十秒。以管理员身份打开 PowerShell先装依赖包。依赖目录里通常有 x64、x86、ARM 几个子目录根据你系统的架构选绝大多数人是 x64Add-AppxPackage -Path C:\tools\LTSC-Add-MicrosoftStore-2019\Dependencies\x64\Microsoft.VCLibs.140.00_14.0.30704.0_x64__8wekyb3d8bbwe.Appx Add-AppxPackage -Path C:\tools\LTSC-Add-MicrosoftStore-2019\Dependencies\x64\Microsoft.NET.Native.Framework.2.2_2.2.29512.0_x64__8wekyb3d8bbwe.Appx这里用的是Add-AppxPackage单包安装。它会把 Appx 包注册到当前用户上下文中不需要额外提权服务器的参与。VCLibs 和 NET.Native 是商店主包的运行时底座顺序上必须先装。如果依赖文件名跟这不一样以实际解压出来的文件名为准不要照抄命令里的文件名。接着部署商店主包。主包通常是 .AppxBundle 或 .Appx 格式一个文件里可能包含多个架构的子包直接传主包文件即可Add-AppxPackage -Path C:\tools\LTSC-Add-MicrosoftStore-2019\Microsoft.WindowsStore_11910.1001.1.0_x64__8wekyb3d8bbwe.AppxBundle -ForceApplicationShutdown-ForceApplicationShutdown的作用是强制关停正在占用包文件的进程如果之前有过失败的安装残留这个参数能避免“文件被占用”的报错。如果主包部署后界面正常但打开闪退多半是依赖没装全或者是主包版本与 1809 内核不匹配不要急着找主包问题先回头看依赖。部分包还会要求你先注册到系统级对所有用户生效这时候要区分两个命令。Add-AppxPackage是给当前用户装的Add-AppxProvisionedPackage是把包预置到系统镜像里新建用户自动生效。多用户共用的机器建议用后者Add-AppxPackage -Path C:\tools\Microsoft.WindowsStore.AppxBundle -DependencyPath C:\tools\Dependencies -ForceApplicationShutdown -AllowDeploymentFallback-DependencyPath参数一次性把依赖目录里所有可用的依赖包一起解析安装省去手动逐条执行的繁琐。-AllowDeploymentFallback是允许部署引擎在严格策略失败时回退到宽松模式在遇到签名策略导致安装被拒时可以加上试一把。下表是部署时几个常用参数的速记参数作用建议-DependencyPath指定依赖包目录自动解析依赖主包和依赖混放时必用-ForceApplicationShutdown强制关闭占用包文件的进程有安装残留时必用-AllowDeploymentFallback允许回退部署策略信任校验报错时尝试-Scope AllUsers对所有用户安装多用户机器上使用-SkipLicense跳过许可证检查离线部署时可加3.3 首次启动与两个必调项商店包部署完之后先别急着打开。“开始菜单”里搜索“Store”如果能搜到图标说明包注册成功。首次打开时常见两个问题一是转圈半小时进不去二是提示“此应用无法在此设备上运行”。转圈的原因多半是商店在后台尝试连接更新服务而 LTSC 2019 的组件存储里没有足够的系统应用基底。不用等太久等两分钟后强制关掉商店再打开一次。如果还是转圈回到依赖安装那一步重点检查 VCLibs 是否装到了正确的架构上——x64 系统装了 x86 的 VCLibs 就会出现这类问题。“无法在此设备上运行”的原因大概率是服务没起来。到服务管理器里找到AppX Deployment Service (AppXSvc)确认启动类型是“手动”且状态是“已启动”。另外把Windows Update服务的启动类型设置为“手动”因为商店的许可证校验和下载调度依赖它。这两个服务调好后重启一次商店就好。4. 从 2019 到 2021LTSC 版本间商店包怎么选先说结论不同 LTSC 版本之间商店包不能随便混用。LTSC 2019build 17763、LTSC 2021build 19044、IoT 企业版 LTSC 2021这三者的商店 Appx 包从理论上讲不能跨版本互换原因在于商店包内部版本号跟系统内核的 API 集合是对齐的。一个为 17763 编译的商店包跑到 19044 的系统上轻则部署报错重则装上后商店任何页面都白屏。拿三者的默认状态做一个对比系统版本内核版本默认商店状态补装方式企业版 LTSC 201917763完全没有本 7z 方案或手动部署 1809 商店包企业版 LTSC 202119044完全移除设置 - 应用 - 可选功能中添加或手动部署 21H2 商店包IoT 企业版 LTSC 202119044部分版本可选启用镜像可选项或手动部署 21H2 商店包如果你的机器是 LTSC 2021网上搜“win10 ltsc 2021 添加商店”会看到不少结果常见做法是先试系统自带的“可选功能”入口设置 - 应用 - 可选功能 - 添加功能 - 应用商店。这一步比任何手动部署都稳因为走的是组件存储原生路径。只有这个方法失败时才考虑手动拿 21H2 的商店包部署而不是反过来先手动装。“投影到此电脑”这类功能不要指望商店包顺手解决。它是独立的无线显示组件在系统里属于“功能按需加载FoD”体系跟应用商店是两个完全不同的安装路径。网上有人给 LTSC 2021 添加投影功能做法是去“可选功能”里加“无线显示”或者用 DISM 从原版镜像的 FoD 目录里回填。这个需求和“添加商店”混在一起搜索的人不少但两个话题不能互相替代。另外提醒一句Office LTSC ISO 和这个商店工具包完全是两回事。Office LTSC 装的是经典 Win32 应用不依赖 Appx 运行时。不要因为下载了 Office LTSC 的 ISO 就以为里面带的证书、许可文件能用来解决商店的信任报错协议体系不同。5. 添加 Microsoft Store 的避坑记录现象、原因、解决5.1 商店装好了但一直转圈进不去这个现象在 LTSC 2019 上特别多。安装完成后点击图标页面一直转圈过几分钟后提示“请检查网络连接”。原因通常是两类一是依赖包不完整VCLibs 或 .NET Runtime 缺了某一个商店启动后做完整初始化时卡住二是 AppXSvc 服务状态不对被设定为禁用后商店主程序无法完成自身的激活请求。解决方法是先停掉商店进程到服务管理器确认AppXSvc已启动并把启动类型改为“手动”然后从开始菜单重新打开商店。如果依旧转圈回看依赖安装结果逐项执行一遍Get-AppxPackage -AllUsers | Where-Object {$_.Name -like Microsoft.VCLibs* -or $_.Name -like Microsoft.NET.Native*} | Select-Object Name, Version这里能直接看出依赖包是否真的装上了。转圈问题里十有八九是 vclibs 返回为空。装好之后顺手重启一次系统再开商店。5.2 wsappx 进程 CPU 占用居高不下商店装好后的第二天任务管理器里 wsappx 一直占 CPU二三十起步有时候冲到五六十。wsappx 是 Appx 部署服务AppXSvc关联的进程它做的是包部署和系统组件评估。在 LTSC 2019 上这个进程常驻占用高原因是系统里缺了不少商店相关的可选组件wsappx 启动后反复尝试做全量应用清单扫描每次都扫不到完整目标于是陷入循环重试。先别急着禁用它。禁用 AppXSvc 虽然能让 CPU 掉下来但商店后续会无法安装任何应用等于功能白加了。正确做法是让它把活干完检查一次应用清单等几分钟看它是否自动回落。如果持续高占用超过十分钟就执行商店自带的“重置”功能设置 - 应用 - 应用商店 - 高级选项 - 重置。重置后 wsappx 会重新做一次完整评估占用率会明显下降。这一步是少有的“等它自己好”的场景不要急着删除服务或改注册表。5.3 部署时报 0x80073CF9 或 0x80073CF30x80073CF9 是“包已存在但状态损坏”的典型报错。常见于之前有过一次失败的安装系统里残留了半注册状态的商店包。0x80073CF3 则是依赖缺失部署引擎找不到主包所需的框架。先说 0x80073CF3。这个不用换主包回头把依赖装全再重新部署主包。注意依赖包也有架构之分x64 系统装了 x86 的 VCLibs部署引擎不一定报错但后续运行时会闪退所以装之前看一眼包名里的架构后缀。0x80073CF9 的处理是先卸载残留再重新部署。用下面的命令找出系统里残留的商店包记录Get-AppxPackage -AllUsers -Name Microsoft.WindowsStore | Remove-AppxPackage执行完后再跑一次部署。如果卸载时报错说包不存在但主包部署时又说包已存在这时候要考虑是包注册记录残留在注册表里。用 PowerShell 吧 StateRepository 数据库打开清理不现实最省事的办法是换个路径重新解压 7z 再部署因为常见情况是安装记录指向上一次解压目录那个目录已经被删了。5.4 双击批处理一闪而过没有任何输出这种翻车场景是最让人头疼的因为没有任何报错信息。原因一般是两种情况脚本里用了管理员提权指令而系统 UAC 被组策略关掉导致runas调用失败或者是脚本在含中文的路径下执行批处理解析路径出错直接退出。解决方法是别双击改成手动逐条执行把路径全部改到纯英文目录下。解压后的完整路径尽量不要有中文和空格C:\tools\这种简单路径最稳妥。另外有些杀毒软件会拦截批处理里写注册表或修改服务的操作导致脚本执行到一半退出解除拦截后重新执行。5.5 装了包但商店闪退一查是包版本跨系统混用把 2019 的商店包硬装到 LTSC 2021或者反过来表现就是“能装上但是打开闪退”。闪退是 Appx 包在初始化时调用了当前系统里不存在的 API 接口导致的属于硬不兼容。闪退比部署报错更难排查因为事件查看器里只会留一条“应用程序崩溃”记录细节信息有限。排查步骤是先确认系统版本确实匹配包名里的年份标签再用事件查看器里的“应用程序”日志查看崩溃模块路径。如果崩溃模块指向商店主包自身那基本可以确定是版本不匹配去下载对应内核版本的包即可。6. 装完后的验证方法与迭代习惯装完商店不意味着收工我会花三分钟做验证确认它不是“看起来正常”。验证分三步。第一步检查包是否完整注册Get-AppxPackage -Name Microsoft.WindowsStore | Select-Object Name, Version, Status输出的 Status 必须是 Ok。如果显示 NotPresent 或 DependencyIssue说明注册有问题需要重新部署。第二步从商店里下载一个轻量 UWP 应用做实际测试首选“微软待办”这类纯 UWP 应用。下载能成功、安装能跑起来才说明商店的下载通道、许可证校验、部署回调全链路正常。如果你只是打开了商店但什么都不装一些隐患会藏在后面。第三步确认关键服务没有异常重启。在事件查看器里看Microsoft-Windows-AppXDeploymentServer/Operational日志筛选错误级别事件确认没有反复刷新的报错条目。我的个人习惯是把这些步骤沉淀成一个文本文件跟解压出来的包放在一起记录当时的系统版本、build 号、部署命令、依赖包的版本号。这样做的原因是这类工具包往往被下载后存在硬盘里半年后再拿出来用时会忘记当时是怎么装成功的某个参数不一样就可能导致部署失败。有这份记录重装系统后照着走一遍就行不用重新摸索。顺便说一句Office LTSC 的 ISO 和商店的 Appx 包不要混放混淆前者是微软 Office 产品线后者是系统组件两者在文件格式和部署路径上没有任何交叉。这算是我踩过几次坑之后留下来的习惯。现在每次拿到这类补商店的压缩包我第一件事是看目录结构和系统版本第二件事就是先看服务状态而不是先双击脚本。希望这次写到的部署路径和排查顺序能帮你少走几趟弯路。本文还有配套的精品资源点击获取