はじめに
ComfyUI Desktopを起動したところ、自動アップデートの途中でアプリが終了し、そのまま起動しなくなりました。
最終的には、公式サイトからComfy Desktopのインストーラーを再度ダウンロードし、既存環境へ上書きインストールすることで復旧できました。
本記事では、原因を切り分けるために確認したログや、拡張機能・保存済みワークフローを失わないために行ったバックアップ、復旧後の確認内容をまとめます。
本記事は2026年8月時点の記録です。
ComfyUIおよびComfy Desktopは頻繁に更新されているため、将来も同じファイルパスや更新方式が使われるとは限りません。
発生した症状
ComfyUI Desktopを起動するとアップデート処理が始まりましたが、途中でアプリが終了しました。
その後、以下の状態になりました。
- Comfy Desktopが自動的に再起動しない
- ComfyUI本体の当日ログが作成されない
- Windowsのイベントビューアーにエラーがない
- Crashpadにもクラッシュレポートが残っていない
- 再度起動しても、アップデート途中で同じように終了する
この時点では、ComfyUI本体がクラッシュしているのか、Desktopアプリの更新処理に失敗しているのか判断できませんでした。
環境
今回確認できたバージョンは以下です。
Comfy Desktop：1.0.29
更新予定：1.0.34
ComfyUI本体：0.28.2
ここで重要なのは、Comfy DesktopとComfyUI本体は別々のバージョンを持っているという点です。
Comfy Desktop
└─ ComfyUI環境
Comfy Desktopは、ComfyUI環境の起動や更新を管理する外側のアプリです。
今回失敗していたのは、ComfyUI本体の 0.28.2 からの更新ではなく、Comfy Desktopの 1.0.29 から 1.0.34 への更新でした。
最初に確認したComfyUI本体のログ
最初に、ComfyUI本体のログフォルダを確認しました。
私の環境では以下でした。
D:\AI\ComfyUI\ComfyUI\logs
しかし、問題が発生した当日のログは作成されていませんでした。
このことから、ComfyUI本体のPythonプロセスが起動する前に、Desktopアプリ側で処理が終了している可能性が高いと考えました。
Comfy Desktop側のログを確認する
Comfy Desktop側のログは、私の環境では以下にありました。
%APPDATA%\Comfy Desktop
その中の app.log を確認すると、以下のような起動記録が残っていました。
[INFO] App started v1.0.29
[INFO] [user-tier] init
[INFO] [git] bootstrap pygit2 configured
[INFO] [ipc] Using bootstrap pygit2 for git operations
[INFO] [cloud-capacity] init
アプリの起動処理は開始されていましたが、明示的なエラーは記録されていませんでした。
ログも初期化処理の途中で終わっており、ComfyUI環境の起動処理までは到達していないように見えました。
Crashpadを確認する
app.log の先頭には、クラッシュダンプの保存先も記録されていました。
%APPDATA%\Comfy Desktop\Crashpad
以下のフォルダを確認しました。
Crashpad\reports
Crashpad\attachments
しかし、reports フォルダには何も入っていませんでした。
そのため、少なくともCrashpad上では、今回の終了はクラッシュとして記録されていませんでした。
Windowsイベントビューアーを確認する
Windowsのイベントビューアーも確認しました。
Win + R
eventvwr.msc
確認した場所は以下です。
Windows ログ
└─ Application
問題が発生した時刻付近について、以下のようなイベントを探しました。
Application Error
Windows Error Reporting
Comfy Desktop
electron.exe
しかし、該当するエラーはありませんでした。
この時点で、OSによる異常終了ではなく、Desktopアプリが更新処理のために終了した後、アップデーター側の処理が完了していない可能性を疑いました。
アップデーターのキャッシュを確認する
ローカルのAppDataを確認すると、以下のフォルダがありました。
%LOCALAPPDATA%\comfyui-desktop-2-updater
さらに、その中の pending フォルダに更新用と思われるファイルが生成されていました。
%LOCALAPPDATA%\comfyui-desktop-2-updater\pending
中には以下のファイルがありました。
current.blockmap
temp-Comfy Desktop Setup 1.0.34 - Build XXXXX-x64.exe
ファイル名から、Comfy Desktop 1.0.34 の更新ファイルを取得しようとしていたことが分かりました。
ただし、インストーラーには temp- が付いたままでした。
最初の試行では約27MB、再試行では約25MBの状態で止まりました。
差分アップデートの場合、ファイルサイズだけで正常・異常を断定することはできません。しかし、以下の状態から、更新処理が完了していないと判断しました。
- ファイル名に
temp-が残っている - Desktopアプリが再起動しない
- 再試行しても同じように終了する
- Desktop側ログに更新完了の記録がない
- Crashpadやイベントビューアーにもエラーがない
原因について
今回、アップデーター内部で何が失敗したのかまでは特定できませんでした。
確認できた事実は以下です。
- Comfy Desktop
1.0.29は起動していた - ComfyUI本体が起動する前に処理が止まっていた
- Comfy Desktop
1.0.34用の更新ファイルがpendingに生成されていた - 更新ファイルは
temp-付きのままだった - Desktopアプリ終了後、アップデートが完了しなかった
- クラッシュログやWindowsイベントログは残っていなかった
したがって、今回の原因は、Comfy Desktopの自動アップデート処理が正常に完了せず、アプリ終了後の更新または再起動に失敗した可能性が高いと考えています。
ただし、通信、セキュリティソフト、差分更新処理、アップデーター自体の不具合など、具体的な原因までは確認できていません。
上書きインストール前にバックアップする
公式インストーラーで上書きする前に、追加したカスタムノードや保存済みワークフローが消えないようにバックアップしました。
私の環境では、ComfyUI本体が以下にありました。
D:\AI\ComfyUI\ComfyUI\ComfyUI
バックアップしたフォルダは以下の2つです。
D:\AI\ComfyUI\ComfyUI\ComfyUI\custom_nodes
D:\AI\ComfyUI\ComfyUI\ComfyUI\user
custom_nodes
追加したカスタムノードが保存されています。
<ComfyUI本体>\custom_nodes
user
保存済みワークフローやユーザー設定が保存されています。
<ComfyUI本体>\user
環境によっては、保存済みワークフローが以下にある場合があるみたいです。
<ComfyUI本体>\user\default\workflows
ComfyUIの配置場所は環境によって異なります。
エクスプローラーで、以下のフォルダが並んでいる場所を探すと分かりやすいです。
custom_nodes
models
output
user
今回は custom_nodes と user を、それぞれ別の場所へフォルダごとコピーしました。
実施した解決方法
自動アップデートを繰り返しても完了しなかったため、公式サイトからComfy Desktopのインストーラーを改めてダウンロードしました。
その後、既存のComfyUI環境を削除せず、そのまま上書きインストールしました。
実施時には、以下を避けました。
- ComfyUI本体フォルダの削除
-
custom_nodesの削除 -
userの削除 - ユーザーデータを削除するクリーンインストール
- 既存環境とは別の場所への新規環境作成
今回のインストールでは、既存環境を維持したままComfy Desktopだけが更新されました。
更新後のバージョン確認
上書きインストール後、Comfy Desktopの設定画面を確認しました。
Desktop Settings
└─ Updates
以下の表示になっていました。
Comfy Desktop is up to date
Installed v1.0.34
これにより、Comfy Desktopが 1.0.34 に更新されたことを確認できました。
一方、環境一覧には以下のように表示されていました。
ComfyUI
Stable・v0.28.2
これは異常ではありません。
Comfy Desktop：1.0.34
ComfyUI本体：0.28.2
という別々のバージョンが表示されています。
復旧後に確認したこと
起動後、以下を確認しました。
- Comfy Desktopが正常に起動する
- ComfyUI環境が正常に起動する
- 追加済みのカスタムノードが読み込まれる
- 保存済みのワークフローが表示される
- 使用していたモデルが再読み込みされる
- 既存のモデルパスが維持されている
今回の環境では、公式インストーラーによる上書き後も、以下のデータはそのまま残っていました。
custom_nodes
user
models
バックアップからの復元は不要でした。
今回の対応手順まとめ
今回実施した手順をまとめると、以下になります。
- ComfyUI本体のログを確認する
- 当日のログがなければ、Desktop側のログを確認する
-
%APPDATA%\Comfy Desktopのapp.logを確認する -
%APPDATA%\Comfy Desktop\Crashpadを確認する - Windowsイベントビューアーを確認する
-
%LOCALAPPDATA%配下のアップデーターを探す -
pendingに未完了の更新ファイルがないか確認する -
custom_nodesとuserをバックアップする - 公式インストーラーでComfy Desktopを上書きする
- DesktopとComfyUI本体、それぞれのバージョンを確認する
- カスタムノード、ワークフロー、モデルを確認する
おわりに
今回の問題は、ComfyUI本体のクラッシュではなく、Comfy Desktopの自動更新処理が完了しないことで発生していた可能性が高いものでした。
最終的には、以下の対応で復旧しました。
custom_nodesとuserをバックアップ
↓
公式インストーラーでComfy Desktopを上書き
↓
カスタムノード・ワークフロー・モデルを確認
ComfyUI本体とComfy Desktopのバージョンが別であることを理解していなかったため、途中で 0.28.2 と 1.0.34 のどちらが更新対象なのか混乱しました。
同じように、起動時アップデートでアプリが終了し、ログにも明確なエラーが残らない場合は、ComfyUI本体だけでなく、Desktop側のログとアップデーターのキャッシュを確認すると切り分けやすいと思います。