Claude Desktop が 0x80070020 で起動しない時の対処

Last updated at 2026-05-11Posted at 2026-05-11

Claude Desktop更新後に0x80070020で起動しない場合、AppX/Desktop AppX containerの生成失敗が原因のことがあります。今回は調査の結果、Windows再起動で復旧しました。

2026年5月時点の検証内容です。Windows 11 上の Claude Desktop 1.6608.2.0 で確認しています。

Claude Desktop が更新後に起動しなくなり、AppModel-Runtime の Event ID 208/215 と 0x80070020 が出ている場合、少なくとも私の環境では単なる残留プロセスだけでは説明しきれませんでした。プロセス掃除や関連サービス停止では直らず、Desktop AppX container 側の競合やセッション汚染を含めて考えた方が自然で、最終的には Windows 再起動で復旧しました。

更新後に Claude Desktop が起動しなくなりました。

見えていた症状は単純で、GUI を開こうとしても何も出ず、Windows 側では「他のプログラムで使用されているため」系の共有違反だけが残る、というものです。最初は Electron 系の残留プロセスだと思ったのですが、切り分けを進めるともう少し厄介でした。

実際に出ていたダイアログはこれです。

この記事では、実際に確認したログ、やって効かなかったこと、最終的に効いたことを時系列でまとめます。結論だけ知りたい人向けに先に書くと、0x80070020 + Desktop AppX container まで出ているなら、同一セッション内の掃除だけでは足りない可能性が高いです。

先に結論を言うと、何が起きて何が効いたのか？

claude.exe の残留を消すだけでは直らないケースがある
AppModel-Runtime の Event ID 208/215 で 0x80070020 が出るなら、Desktop AppX container の生成失敗まで見に行くべき
CoworkVMService や VSCode 側の claude.exe helper は競合候補として確認価値がある
ただし、それらを止めても直らないなら、Windows セッション側の汚染を疑う方が自然
私の環境では 再起動で復旧 した

どんな症状だったのか？

発端は Claude Desktop の更新後です。アプリを再起動しようとすると、GUI が出ません。

このとき見えていたのは、たとえば次のような状況です。

Claude Desktop の古い親プロセスが長く残っている
claude-code の子プロセスが多数ぶら下がる
VSCode 拡張版の claude.exe も別に常駐している
CoworkVMService が起動試行のたびに start/stop を繰り返す

最初は「残留 claude.exe を全部落とせば直る」と考えました。実際、古い親プロセスや子プロセスを掃除すると、メモリ使用量はかなり下がります。ですが、今回の本題はそこではありませんでした。

何を見れば「ただの残留プロセスではない」と分かるのか？

今回いちばん重要だったのは、Microsoft-Windows-AppModel-Runtime/Admin のイベントログです。

実際に出ていたのは、次の 2 つでした。

Event ID 208
0x80070020: ランタイムの構成中にエラーが発生したため、パッケージ Claude_... のプロセスを作成できません。[LaunchProcess]

Event ID 215
0x80070020: ジョブの変換中にエラーが発生したため、パッケージ Claude_... の Desktop AppX コンテナーを作成できません。

ここまで出ていると、単に「GUI プロセスが残っていた」より一段深い問題です。

つまり、MSIX / AppX の起動レイヤで、Desktop AppX container の生成自体が失敗している ことになります。私の理解では、この時点で見るべき対象は Electron アプリ単体ではなく、Windows のアプリコンテナー管理側です。

まず何から切り分けたのか？

今回、実際に順番に潰したのは次の 4 系統です。

1. Claude Desktop 本体の残留プロセス

まず、WindowsApps 配下の Claude Desktop 本体と、その配下の claude-code 子プロセスをすべて落としました。

これは一定の意味がありました。更新前の古い親プロセスが残っていると、新しいパッケージの起動と混線しやすいからです。

ただし、これだけでは復旧しませんでした。

2. VSCode 拡張版の `claude.exe`

私の環境では、VSCode 拡張版の Claude helper が複数残っていました。しかもバージョン違いの拡張が併存しており、古い 2.1.126 系と新しい 2.1.133 系が混ざっていました。

これも競合候補なので、いったん全部停止しました。

それでも Claude Desktop の GUI は起動しませんでした。

3. `CoworkVMService`

Claude Desktop 側の機能として CoworkVMService が存在し、起動試行ごとに service start/stop を繰り返していました。

このサービスを止めた状態でも再試行しましたが、やはり 0x80070020 は消えませんでした。

4. `claudedashboard.exe`

もう 1 つ、ローカルの claudedashboard.exe という自動起動サービスも見つかりました。これは Anthropic 公式成分とは断定できず、ローカルの別サービスとして動いていました。

競合候補ではあるので停止・無効化しましたが、これでも再現は止まりませんでした。

つまり何が分かったのか？

ここまでで分かったのは、少なくとも私のケースでは次の 2 点です。

claude.exe 残留だけが原因ではない
サービス停止までやっても 208/215 + 0x80070020 が残る

なので、原因の中心は「まだ見えていない 1 つの犯人プロセス」よりも、Windows セッション内に残った AppX / container 状態そのもの にあると判断しました。

この判断は、Anthropic の既知 issue とかなり近いです。特に GitHub issue #53247 は、0x80070020、Desktop AppX container、クラッシュ後に orphaned Silo / Job Object が残る、という説明まで含んでいて、今回の症状にかなり似ていました。

実際に効かなかったのは何か？

今回「やったが直らなかった」ものは、少なくとも次です。

Claude Desktop の通常終了
残留 claude.exe の一括停止
claude-code 子プロセスの停止
VSCode 側 Claude helper の停止
CoworkVMService の停止
claudedashboard.exe の停止・無効化

最終的に効いたのは何だったのか？

最終的に復旧したのは、Windows 再起動 でした。

再起動後は Claude Desktop が正常に起動しました。
この結果から見ても、今回の本丸は Electron プロセスの掃除ではなく、ログオンセッションをまたいでしか消えない AppX / container 汚染 だった可能性が高いと見ています。

「まず logoff、だめなら reboot」という順序はありえますが、今回のケースでは最終的に reboot で復旧しました。

次に同じ症状が出たら何をするか？

私なら次はこの順番で動きます。

1. まずイベントログを見る

Microsoft-Windows-AppModel-Runtime/Admin で 208/215 を確認します。

ここで 0x80070020 と Desktop AppX container まで出ていれば、ただの残留プロセスとは切り分けて考えます。

2. 残留プロセスと関連サービスを一度掃除する

これは無駄ではありません。少なくとも「表層の競合」を消す意味はあります。

Claude Desktop 本体
claude-code 子プロセス
VSCode 側 claude.exe
CoworkVMService
非公式の常駐サービスがあればそれも

3. それでも `208/215` が続くなら、セッション切り直しに寄せる

この段階では、同一セッションでの粘りは期待値が下がります。

可能なら logoff
直らなければ reboot

4. それでも直らなければ Cowork 周辺の状態破損を疑う

公開事例では、local-agent-mode-sessions 退避や Cowork 状態クリアで直った例も見つかりました。今回の私はそこまで進む前に再起動で復旧したので、ここは次の候補です。

まとめると、どこを疑うべきなのか？

今回の件でいちばん重要だったのは、0x80070020 を「まだプロセスが残っているだけ」と雑に解釈しないことでした。

AppModel-Runtime の Event ID 208/215 で Desktop AppX container 失敗まで出ているなら、問題はもう一段深いです。関連プロセスやサービスを掃除しても直らないなら、Windows セッション側の汚染を疑った方が早いです。

私の環境では、最終的な復旧策は再起動でした。

同じログを踏んだ人の探索コストが少しでも下がれば十分です。もし将来もう一度再発したら、次は local-agent-mode-sessions や Cowork 状態クリアまで含めて追記しようと思います。

参考リンク

Claude Code を使った AI 開発環境の整え方は、Zenn Book『Claude Code AI Ops実践ガイド』にもまとめています。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up