目录

刚更新完 Claude Desktop（Windows）后尝试启动应用，会弹出一个写着 "另一个程序正在使用此文件" 的对话框，应用无法启动——而且在重启电脑之前一直无法修复。这是 Microsoft Store（MSIX）版 Claude Desktop 上报告的一个已知缺陷（GitHub #53247 等）。

先说结论。并不一定需要完全重启电脑。很多情况下，只要注销 Windows 再重新登录即可恢复（不是重启电脑，也不是退出 Claude 的登录）。下面把有效的手段、无效的手段，以及错误的真正面目，按已确认／推测／未确定分门别类地梳理清楚。本文基于一台实机（Windows 11 Home，10.0.26200）上的调查日志，并与 GitHub 上的已知 issue 相互印证。

⚠️ 本文的置信度标签：✅已确认＝在实机日志或 issue 中直接确认／🟡推测＝根据旁证做出的解读／🔴未确定＝尚无法判断。对于"原因＝文件锁"之类无法断定的事情，我们不做断言。

0x80070020 · APPMODEL-RUNTIME 215 / 208

应优先尝试的恢复顺序

① 注销 Windows → 重新登录
开始菜单 → 用户图标 → "注销"。最快，且有时无需重启整台电脑（#53247）
② 重启电脑
可靠但代价大。当 ① 无法恢复时使用
③ 改用 Squirrel 版
杜绝复发的长久之策（#57221 报告者）

1. 结论——先注销 Windows 即可恢复

这个缺陷的实际危害是"无法启动"，但恢复它并不一定需要完全重启电脑。根据 #53247 的分析，问题背后的"孤立句柄"是按 Windows 用户会话为单位残留的，因此只要注销 Windows 再重新登录就能将其清除。多数人会条件反射地重启整台电脑，而这么做可以省下那段时间。

"注销"指的是 Windows——不是重启电脑，也不是退出 Claude 的登录

这里说的注销，是指从 Windows 用户账户注销（开始菜单 → 左下角的用户图标 → "注销"）。打开着的应用会暂时关闭，但电脑不会关机，而且比重启更快。它不是退出 Claude 应用／账户的登录，也不是重新启动应用——那些做法都无法修复。

  • ✅ 想立刻修好：注销 → 重新登录。有报告称这样应用就能再次启动（#53247）。
  • ✅ 想稳妥修好：重启电脑。代价大，但可靠。
  • ✅ 想杜绝复发：弃用 MSIX 版，改用 Squirrel（安装程序）版（详见下文，出自 #57221 报告者）。

2. 症状——更新后启动时出现

典型的流程是这样：Claude Desktop 的更新应用完成后，尝试打开应用时会弹出一个 Windows 资源管理器风格的对话框，写着"另一个程序正在使用此文件"，应用无法启动。关掉再打开也是一样，直到重启电脑（或注销）才能恢复。

关键在于，这个对话框的措辞并没有准确反映实际发生的情况（详见 §4）。此外，更新本身是成功的——失败的不是更新，而是"应用的启动"。受影响的是 Microsoft Store（MSIX）版的 Claude Desktop。

3. 处理办法——有效的手段与无效的手段

这里是最大的坑。网上会看到"停掉服务就能修好"之类的说法，但对于这个缺陷，有报告称那些做法无效。我们把有效的手段和无效的手段清清楚楚地区分开。

✅ 有效（有报告）
  • 注销 Windows → 重新登录（最快；有时无需重启电脑）
  • 重启电脑（可靠）
  • 改用 Squirrel 版（长久之策；防止复发）
🔴 有报告称无效（不推荐）
  • Stop-Service CoworkVMService（会重启并复发）
  • 用 taskkill 结束所有 Claude/Cowork 进程
  • Reset-AppxPackage / Add-AppxPackage -Register
  • 重启 AppXSvc、ClipSVC、vmcompute 等服务

右侧的手段在 #48003 和 #53247 中都被记录为试过并且失败了。它们容易白白浪费时间，所以先尝试注销才是合理的做法。

长久之策：改用 Squirrel（安装程序）版

如果无法忍受每次更新都踩这个坑，#57221 的报告者称，卸载 MSIX 版、改用安装程序（Squirrel）版后，更新和启动两方面的问题都得到了解决。步骤要点：

  1. 彻底卸载 Store（MSIX）版的 Claude Desktop。
  2. 从 Claude 官方下载页，或通过 winget（例如 winget install Anthropic.Claude）安装安装程序版。
  3. 之后由自动更新升到最新版本。

🟡 给出的理由是，这样便可跳出 C:\Program Files\WindowsApps 目录及 AppX 容器层的约束。不同环境下行为可能不同，所以切换前请确认自己的使用场景（企业分发策略等）。

4. 错误的真相——并非文件锁（已确认）

对话框读起来像是"文件正在被使用"，但从实机日志来看，失败发生在别处。事件日志 Microsoft-Windows-AppModel-Runtime/Admin 中记录了以下内容（✅实机确认）：

Event ID 215:
0x80070020: Cannot create the Desktop AppX container for package
            Claude_..._x64__pzs8sxrjxfjjc
            because an error was encountered converting the job.

Event ID 208:
0x80070020: Cannot create the process for package ... [LaunchProcess]
要素含义
0x80070020ERROR_SHARING_VIOLATION。Windows 通常会将这个代码文案化为"进程无法访问文件，因为它正被另一个进程使用"。对话框的真正来源就是它。
[LaunchProcess]是启动失败，而非更新失败（更新已经成功）。
失败位置创建 Desktop AppX 容器——具体来说是把 Job Object 转换为 Silo 的那一步。

而且✅已经通过验证确认"不存在文件锁"。在 #53247 中，用 handle.exe 和 Process Explorer 检查后，显示不存在用户空间的文件锁。也就是说"因为别的程序占着文件"这个说法，至少作为用户空间的锁来讲是错误的。真正的问题出在 AppX/Desktop Bridge 的容器层（Job/Silo）。

5. 两种相互对立的解释，尚无定论

"容器层的问题"这一点已经确定，但关于其触发原因存在两种见解，仍未有定论。我们避免断言，两种说法并列呈现。

说法 A：服务占用了 Job Object（#57221）

随包附带的 CoworkVMService（SYSTEM 权限、自动启动）握住了软件包的 Job Object，妨碍了新软件包的容器创建。在实机上，错误与服务重新安装发生在同一秒，与这一说法相符（🟡旁证）。

说法 B：启动时崩溃导致清理未执行（#53247）

如果 Claude 进程在启动时崩溃，内核侧的 Silo/Job 清理就不会执行，孤立句柄会残留下来。此后的启动就会在转换同一软件包的 job 时失败。注销能修好这一事实与该说法相符。

需要注意其中的张力：如果说法 A（服务占用）成立，那么"停掉服务应该能修好"——但实际上有报告称无效（§3）。由于存在这个矛盾，哪一种才是主因尚无定论。🔴 目前来看，两种说法并列才是诚实的态度。

另外，这一症状已在多种语言下得到确认。#53247 的报告者使用葡萄牙语环境，对话框显示为 "Há um outro programa usando este arquivo no momento"（另一个程序此刻正在使用此文件）——与英语／日语措辞下的症状完全相同。

🔴 官方修复的状况：在调查时点，官方尚未发布长久性修复。核心 issue #53247 仍处于 Open 状态（无负责人）。在该 issue 中，有人提出了一些长久修复方案——把 CoworkVMService 从自动启动改为按需（Manual）启动，或把服务二进制文件移出 WindowsApps——但都还停留在提案阶段。

6. 在自己的机器上确认（PowerShell）

你可以确认自己的故障是否与本文所述相同（无需管理员权限）。如果出现事件 215/208 和 0x80070020，那就是同一个问题。

Get-WinEvent -LogName 'Microsoft-Windows-AppModel-Runtime/Admin' |
  Where-Object { $_.Message -match 'Claude' } |
  Select-Object TimeCreated, Id, Message | Format-List

如果想与更新历史相互对照，以及查看随包服务的当前设置：

Get-WinEvent -LogName 'Microsoft-Windows-AppXDeploymentServer/Operational' |
  Where-Object { $_.Message -match 'Claude' } |
  Select-Object TimeCreated, Id, LevelDisplayName, Message | Format-List

Get-CimInstance Win32_Service -Filter "Name='CoworkVMService'" |
  Select-Object Name, StartMode, State, PathName

7. 容易混淆的其他问题

Claude Desktop（Windows）还有一些代码相近、容易被混淆的其他缺陷。它们与本文的 0x80070020（启动失败）是两回事，需要区分开来。

症状代码与本问题的区别
本文：更新后无法启动0x80070020—
更新失败（#49655）0x80073CF6是更新失败，而非启动失败。代码不同。
重新安装卡在"Servicing"（#51132）0x80073D28 等是部署处理卡住。代码不同。

此外，在 Claude Code CLI（桌面应用所管理的 claude.exe）更新时，可能会出现 EPERM: operation not permitted, unlink ... claude.exe，但那只是删除旧版本失败而已——新版本已经装好了——与本问题无关。

总结

  • ✅ 先注销 Windows → 重新登录：恢复不一定需要重启整台电脑（#53247）。如果不行再重启电脑。
  • 🔴 有报告称停掉／重新注册服务无效：容易白白浪费时间，应避免。
  • ✅ 真正的原因并非"文件锁"：是 AppX 容器层（Job→Silo 转换）的失败。对话框措辞并未反映实际情况。
  • 🔴 触发原因有两种说法，尚无定论：服务占用说（#57221）／启动时崩溃→孤立句柄说（#53247）。官方修复尚未提供。
  • ✅ 长久之策是改用 Squirrel 版：有报告称更新和启动的问题都得到了解决（#57221）。

本文基于一台实机（Windows 11 Home 10.0.26200）的调查日志与 GitHub issue 的相互印证。并非所有用户都会以完全相同的方式复现，且原因的细节仍无定论——请诚实地了解这些前提后再加以参考。

FAQ

Q1. 最快的修复方法是什么？

把 Windows 注销一次再重新登录是最快的（开始菜单 → 用户图标 → "注销"）。它不是重启电脑，也不是退出 Claude 应用／账户的登录。根据 #53247，背后的孤立句柄是按 Windows 用户会话为单位残留的，所以有时无需重启整台电脑。如果仍无法恢复，再重启电脑。

Q2. 我看到有人说"停掉服务就行"——这管用吗？

对于这个缺陷，有报告称无效（#48003、#53247）。Stop-Service CoworkVMService 会让服务重启并使错误复发，Reset-AppxPackage 以及重启各种服务也都没能解决。先尝试注销更为合理。

Q3. 文件真的被锁住了吗？

没有。对话框读起来像是"文件正在被使用"，但经验证（handle.exe / Process Explorer）确认不存在用户空间的文件锁（#53247）。真正的问题是 AppX/Desktop Bridge 的容器层（Job Object → Silo 转换）失败，只是通用代码 0x80070020（ERROR_SHARING_VIOLATION） 被那样文案化了而已。

Q4. 那原因到底是什么？

容器层的问题已经确定，但触发原因有两种说法，尚无定论：（1）CoworkVMService（自动启动）占用 Job Object（#57221）；（2）启动时崩溃导致 Silo/Job 清理未执行、孤立句柄残留（#53247）。由于停掉服务修不好，这与（1）相矛盾，因此目前无法断定。

Q5. 有官方修复吗？

在调查时点，官方尚未发布长久性修复。核心 issue #53247 仍处于 Open 状态。在该 issue 中，"把服务改为按需（Manual）启动"等长久修复还停留在提案阶段。

Q6. 是不是每次更新都会发生？

🔴 无法断定。在实机上有一种"每次更新都会发生"的体感，但事件日志中能确认到的只有 6 次更新中的 2 次（旧记录可能因日志大小上限而被清除，所以无法判别）。发生频率可能因机器而异。

Q7. 怎样才能不再复发？

有报告称，弃用 MSIX（Store）版、改用 Squirrel（安装程序）版后，更新和启动两方面的问题都得到了解决（#57221）。做法是先彻底卸载 Store 版，再从官方网站或通过 winget 安装安装程序版。如果有企业分发策略等约束，请事先确认。

相关文章