一次查找并修复 Windows UWP 运行环境问题的曲折经历

本文旨在提供一个排障思路，具体的排障步骤请直接看文末。

部分不必要展现的信息已做模糊处理。

症状呈现

最近我在使用 Windows 11 的时候，遇到了与 UWP 应用相关的一系列很奇怪的问题：

• 已经设置的开机自启失效
• 应用内打开链接时好时坏

一开始我不以为意，觉得可能只是我电脑资源不足导致的。但后来又发现了一些严重的问题，使我开始认真起来：

• UWP 应用不再能够与系统服务通信（具体表现为 Armoury Crate、Intel 显卡控制中心等与硬件驱动程序相关的软件认为相关支持服务未启动，甚至干脆觉得未安装兼容的硬件）
• UWP 应用不再能够写入硬盘（具体表现为 Telegram 的第三方客户端 Unigram 无法将下载的文件保存到用户目录下的标准文件夹内）
• Microsoft Store 等 UWP 应用无法打开其他 UWP 应用，提示“Windows 无法访问指定的设备、路径或文件。你可能没有适当的权限访问该项目。”

问题定位

一开始，我尝试了搜索引擎上能搜到的各种各样的解决方案，包括但不限于：

• 使用 DISM 和 SFC 修复系统
• 重置 Microsoft Store
• 重新部署所有包
• 修改系统分区和 WindowsApps 卷的权限
• ……

所有这些无一生效，反而把系统搞到满目疮痍。不得已，我备份了重要文件和应用列表后开始重装系统。重装完后，将几个数据目录放回原位，winget import 安装之前已安装的软件一气呵成（注意这一点）。然后打开几个 UWP 应用一看，问题依旧。我还以为是我下载的由第三方打包的，内置了最新累积更新包的 Windows 安装镜像有问题，遂前往微软官网下载了原版镜像再次重装，结果除了浪费我半个小时安装更新之外，一切都和上次完全一样。

难道这是 Windows 11 本身的问题？我一度有过这样的疑问，但是很快就否决了这样的想法：我安装的 Windows 11 Build 22612.1848 已经发布了一月有余，且 Build 22612.1992 也于三天前发布。这样重大的系统 Bug 不太可能横跨两个版本而尚未修复。就算有，网上肯定也已经是骂声滔天，但我却没有搜索任何相似的反馈。我一时不知所措。

后来，我闲的没事干水 Arch Linux 群时，看到一位群友向另一位提问题的群友索要 Journald 日志的消息，这使我有了想法——Windows 系统也有类似于 Journald 的日志管理系统，而对应 Journald 的日志查询工具 Journalctl 的则是“事件查看器 eventvwr.msc”。我打开事件查看器，进入“自定义视图”中预设的“管理视图”，一个筛选出所有“信息”级别以上（即“警告”、“错误”和“关键”）日志条目的视图，打开一个需要与外部通信的 UWP 应用，然后点击右侧边栏中的“刷新”，便得到了这样的日志：

0x80070005: 无法将进程 xxxx 添加到程序包 oooo 的桌面 AppX 容器 {ABC-DEF-GHI}，因为遇到了错误。
0x80070005: 无法为程序包 xxxx 创建进程，因为在配置运行时的过程中遇到错误。[LaunchProcess]

下方详细信息窗格中，可以看到两条错误的“日志名称”字段都是 Microsoft-Windows-AppModel-Runtime/Admin，那么接下来便前往左侧边栏目录树，依次展开 应用程序和服务日志/Microsoft/Windows/AppModel-Runtime/Admin，然后寻找第一条此类日志。我看到第一条日志发生于 2023-7-15 11:45:14。那么问题来了，在这之前我做了什么呢？我开始查看 2023-7-15 11:40:00 至 2023-7-15 11:46:00 这六分钟内的系统日志。

再次回到“自定义视图”，点击右侧边栏的“创建自定义视图”，将“记录时间” 设置为“自定义范围”，“从”和“到”均设置为“事件时间”，然后填入 2023-7-15 11:40:00 和 2023-7-15 11:46:00 这两个时间点，点击“确定”保存。；“事件级别”则勾选除了“详细”以外的其他四个（“信息”、“警告”、“错误”和“关键”）。在“事件日志”选项卡内，首先勾选“Windows 日志”和“应用程序和服务日志”，由于这个问题无论如何重启或登录都存在，所以取消勾选“Windows 日志”下的“安全”日志选项，最后点击“确定”，保存该自定义视图。

打开这个自定义视图，便可以看到这两个时间点之间记录的日志。从最早的一条开始一条一条往上翻，当翻到 2023-7-15 11:45:00 时，我注意到了一条由 Program-Compatibility-Assistant 记录的日志：

Exe: C:\Users\User01\AppData\Local\MSEdgeRedirect\MSEdgeRedirect.exe

ResolverName: DetectorShim_KernelDriver

Program-Compatibility-Assistant，即“程序兼容性助手”，在每次打开一个新程序时都会自动运行来检查这个程序是否与当前版本的 Windows 兼容。这条日志仅为“信息”级，本身并没任何问题。但是在此条日志被记录下（即 MSEdgeRedirect 开始运行）以后，AppModel-Runtime 即 UWP 运行环境便开始频繁出现前文所述的两类错误日志。同时 CloudStore 这个用于同步 Windows 设置的服务也开始大量输出错误日志。

问题解决

显然，MSEdgeRedirect 便是造成 UWP 环境受到干扰的源头。但问题又来了，我并不是第一次用这个软件，这个软件最近也未发布版本更新，为什么突然会出现这个问题？我打开 Uninstall Tool，点击 MSEdgeRedirect 条目旁的修改，发现在使用 winget 自动安装后，这个软件会默认工作在无需特权的 Service Mode，而非我之前手动安装时使用的，同时也是官方推荐的 Active Mode。在将软件的工作模式改为 Active Mode 后，甚至都不需要重新启动系统，问题便消失了。相应的，如果把工作模式从 Active Mode 再改为 Service Mode，问题又会卷土重来。从 MSEdgeRedirect 的 GitHub Issues 上看，确实有人遇到了无法从“设置”打开屏幕保护设置的问题（是的，“设置”也是一个需要与系统组件通信的 UWP 应用，它同样受到影响，只是我没发现），开发者也确认了这是一个 Bug。

总结

果然重装并不能解决一切问题，无论在什么环境下，遇到问题看日志才是真正的万金油。

另外少用 winget 装这些特权应用，装之前尽量检查元数据。但凡我不脑子一热去用 winget 装它我也不至于折腾这么久。（我还用 winget 装了个百度网盘，结果它把手动安装时可以取消的 Office 插件也给我装上了。）