はじめに

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側のログとアップデーターのキャッシュを確認すると切り分けやすいと思います。