There was a problem with WSL アプリ移動でDockerが停止

Windowsの設定からChatGPTを別ドライブへ移す途中で、DockerがWSLエラーで停止しました。ログに残っていたのは、アプリ保存先の準備中に起きたドライブ全体のアンマウントでした。Docker単体の再起動でエンジンは復旧しました。

表示されたWSLエラー

ChatGPTの移動後、Docker Desktopに次のエラーが表示されました。詳しい内容には、DockerのWSL起動処理が終了コード135で終わったことも含まれていました。

There was a problem with WSL
An error occurred while running a WSL command.
Please check your WSL configuration and try again.

exit status 135

Docker Desktopは4.95.0、WSLは2.7.14.0でした。Dockerのデータ用VHDXは、この移行作業より前からDドライブに置いてあり、論理サイズは約273GBでした。今回ChatGPTアプリと一緒にDockerのデータを移したわけではありません。

エラーの長い詳細には、前夜の起動時のログも含まれていました。冒頭のcomponentsVersion.jsonがない警告は、その後Dockerが約11時間動いていた時点より前のものです。目立つ最初の警告をそのまま直接原因にせず、実際に停止した時刻の前後を見直しました。

この区別は対処の選び方を変えます。単に「WSLの構成を確認して」と表示されても、今回の中心はWSL設定の誤りではなく、稼働中の仮想ディスクへのアクセスが失われたことでした。設定を変更したりWSLを登録し直したりする前に、時間をそろえてWindows側のイベントを確認しました。

移動先の準備中にDドライブ全体がアンマウント

決め手は、通常のSystemログに加えて、NTFS、AppXDeploymentServer、VHDMPのログを並べたことでした。次は保存したイベント時刻を、日本時間のミリ秒単位へ丸めた表です。

Dドライブのアンマウントは、ChatGPTパッケージそのものの移動開始より前でした。DドライブをWindowsのアプリ保存先として使えるようにする準備中に、Dドライブ全体が対象になっています。移すアプリを閉じていても、同じドライブ上でDockerの仮想ディスクを開いたままなら影響を受ける経路がありました。

NTFSの要求元はsvchost.exeでした。イベントのプロセスIDを、障害前から継続していた同じプロセスとWindowsサービスの情報に照らすと、StorSvc、つまりStorage Serviceに対応しました。アプリ保存先を登録するAppX側のプロセスとは別であり、2つのプロセスを同じものとして扱ってはいません。

アンマウント開始から再マウント完了までは約3.3秒でした。一方、アンマウント成功から再マウント完了までは約0.17秒です。このため「Dドライブが完全に消えていた時間が3.3秒」とは書けません。短い処理でも、使用中ファイルの接続が失われれば、その後のアプリ処理が継続できないことが今回の問題でした。

0xC000026Eから分かったこと

MicrosoftのNTSTATUSの定義で、0xC000026EはSTATUS_VOLUME_DISMOUNTEDです。アンマウントされたボリュームに操作を試みたことを示します。今回のDocker VHDXの読み取り失敗にも、この値が記録されていました。

WSLカーネルの記録にも、仮想ストレージのREAD失敗、デバイスのオフライン化、containerdのsignal 7による異常終了がありました。Windows側の仮想ディスクの記録と、WSL側の停止までが、同じ時刻の流れとしてつながりました。

Microsoftのボリュームのアンマウントに関する説明には、使用中のボリュームでもアンマウントを試み、利用中のプロセスへ予測できない結果を与え得ることが書かれています。今回の挙動はこの一般的な性質と整合します。ただし、当該APIを実際に呼び出したスタックを採取したわけではなく、Windows内部の特定の呼び出し経路まで確認した結果ではありません。

イベントの理由欄はUser requestでした。これを見て「人間がUSBの取り外しを押した」とは判断していません。要求元のサービスと時系列を調べた結果、Windowsがアプリ保存先を準備していた間の処理と結び付いたためです。

同じ時間帯について調べたUSBやPnPなどのログには、物理的な抜去・再接続を裏付ける記録は見つかりませんでした。調査時のドライブ状態もHealthyでした。この結果からSSDを無条件に無故障とすることはできませんが、今回見つかった直接の障害経路は、Storage Serviceによるアンマウントと、それに続くVHDXのアクセス失敗です。

Microsoftが説明するPackageVolumeは正規のアプリ保存先の仕組みです。それでも、標準機能で移すことと、同じドライブを使う別アプリが無停止で継続できることは同じではありませんでした。

Unityにも同じ時刻のI/O障害

同じドライブにはUnityのプロジェクトもあり、Unity Bug Reporterが表示されました。Application Errorの記録では、Dockerを再起動するより前の13:20:47〜49にUnity Data Storeが異常終了しています。例外は0xC0000006、下位のI/Oステータスは0xC000026Eでした。

Microsoftの定義では、0xC0000006はSTATUS_IN_PAGE_ERRORで、必要なデータをI/Oエラーによりメモリへ配置できなかったことを示します。下位のステータスに、Dockerと同じアンマウントの値がありました。同じドライブの利用不能に巻き込まれたことを支持する結果です。

ただし、このイベントのファイル名欄は空で、Unityが失敗した個別ファイルを特定したわけではありません。後のクラッシュ記録にUnity.dllが現れることだけを理由に、DLLの破損や再インストールが必要とは判断しませんでした。

Unityはその場で再起動せず、既存のシーンバックアップ、ログ、ダンプなど5ファイル、合計約8MBを別に保全しました。シーンのバックアップ時刻は当日08:31で、クラッシュ直前の未保存作業まで残る証明にはなりません。保全ファイルを元のプロジェクトへ上書きする操作は、この調査ではしていません。

この経緯からも、Dockerの再起動が先にUnityを壊したという順序にはなりません。最初のUnity Data Storeの異常終了はDockerの再起動より前であり、障害を調べるときは、画面が表示された順番だけでなくログの発生時刻を確認する必要がありました。

Docker単体の再起動でエンジンは復旧

原因を追える最低限のログをローカルに残し、Dドライブが再び利用できることを確認してから、Docker Desktopだけを1回再起動しました。使ったのはDocker公式CLIです。次のコマンドは稼働中のDocker作業へ影響するため、実行前に保存・停止が必要な処理を確認してください。

docker desktop restart --timeout 45

Docker公式のrestartの説明では、--timeoutはコマンドの待機時間を制限するオプションです。「45秒で必ず復旧する」という意味ではありません。今回の実行は終了コード0で完了しました。

続けてdocker versionでServerの応答を確認し、Engine 29.8.2を取得しました。WSLの一覧でもdocker-desktopはRunningへ戻りました。新しいバックエンド起動は13:27台です。

取得できたコンテナ一覧は108件で、稼働1件、停止106件、作成済み1件でした。停止中のコンテナを一括で起動することはしていません。エンジンが応答することと、各プロジェクトのDBやサービスが以前どおりに動くことは別なので、必要なサービスの機能確認は担当側で行う扱いにしました。

この復旧では工場出荷状態へのリセット、データ削除、WSL登録解除、再インストールはしていません。Docker以外にも影響するWSL全体のshutdownや、診断データ一式の外部アップロードも使いませんでした。エラー画面が出た直後に、保存データを失う対処へ進まなかったことが重要です。

原因調査で役立ったログ

最初にSystemログだけを見た段階では、決め手となるアンマウントの記録に到達できませんでした。Systemログに見当たらないことと、Windowsに記録がないことは違います。今回は次の記録を時間で並べることで、アプリ移動の準備と、別アプリのI/O失敗がつながりました。

読者が同じ症状を調べる場合も、操作した時刻、移動先、Dockerの仮想ディスクの場所、エラー文を先に控えておくと、必要な範囲を絞れます。ログ名は端末ごとに利用可能かを確認し、既存の記録を読むことから始めます。今回の追加調査では、診断設定の有効化や、障害を起こした操作の再現はしていません。

記事には利用者名、ユーザーSID、機器のシリアル、認証情報、コンテナの環境変数を掲載していません。ログを公開するときは、必要な時刻・エラーコード・処理名だけを抜き出す方が、原因も読み取りやすくなります。

別ドライブへ移す前に決めること

今回の反省は、ChatGPTの停止とバックアップに注意を向ける一方、Dドライブ上ですでに動いていたDockerやUnityへの影響を、移動前の案内で十分に扱えていなかったことです。次に同じ種類の作業を計画するなら、停止する範囲をドライブ単位で確認します。

1. 移動先の利用者を洗い出します。DockerやVMの仮想ディスク、DB、エディタのプロジェクトなど、Dドライブ上のファイルを開き続けているものを確認します。
2. 未保存作業と復元に必要なデータを保全します。アプリ本体のコピーだけでなく、作業中のデータを戻せる状態にします。
3. 対象ドライブを使う処理を止められる時間を選びます。他チャットや別担当で動いている処理も含め、移動中に新しく起動しないようにします。
4. Windowsの正規の移動機能を使います。WindowsAppsやWpSystemの所有権・権限を変え、フォルダだけを手で動かす方法は採りません。
5. 移動結果と周辺アプリを別々に確認します。アプリの起動、保存項目、ブラウザ、Dockerエンジン、必要なサービスという順で、実際に使う機能まで確認します。

今回Dドライブが初めてアプリ保存先に登録されたことはログで確認できました。しかし、登録が済んだから今後同じ障害は絶対に起きない、とまでは分かりません。実運用のDドライブで再登録やアンマウントを繰り返す試験は行わず、現在動いている構成を維持しました。

また、アプリをDドライブへ移せば関連ファイルがすべてDドライブにまとまるわけではありません。今回はアプリ本体と主要データはDドライブ、使用中のCLIなどはCドライブに残しました。容量と保存先の全体像はChatGPT・Codexの別ドライブ移行記録を参照してください。

移動成功と周辺アプリの無事は別

ChatGPTアプリ自体のDドライブへの移動は成功し、移動後のブラウザ操作と保存項目も確認できました。その一方で、保存先の準備中にDドライブ全体がアンマウントされ、同じドライブの仮想ディスクを使うDockerなどに障害が出ました。移動の成功イベントだけでは、周囲のアプリまで無事だったとは言えません。

今回の直接の障害経路はログから説明できます。Windows内部のどの呼び出し分岐がアンマウントを要求したのか、別の端末やWindows版でも同じ現象が起きるのかは確認していません。この実例から採れる具体的な対策は、移すアプリだけでなく、Dドライブの稼働中処理も止めてから作業することです。

よくある疑問

「There was a problem with WSL」はWSLを入れ直せば直りますか？

今回の原因経路は仮想ディスクのアクセス失敗でした。Docker単体の再起動でエンジンは復旧し、WSLの再インストールや登録解除は使っていません。まず停止時刻のログを確認する方が、保存データを守りやすい対処になります。

DドライブのSSDが壊れたということですか？

今回見つかったのは、Storage ServiceがDドライブをアンマウントした直接の記録です。同時刻の物理的な抜去を示す記録は見つかっていません。この事例をSSD故障と決めつける根拠はありません。

Windows標準のアプリ移動は使わない方がよいですか？

別ボリュームへのパッケージ移動はWindowsの正規機能です。今回の経験からは、同じ移動先を使う別アプリを稼働させたまま進めず、停止・バックアップ・動作確認の時間を確保する必要があると考えています。

Dockerが起動したなら、すべて復旧したと考えてよいですか？

エンジンの応答と、各コンテナのサービスやDBの内容は別です。今回確認できたのはエンジンの復旧と一覧取得までで、必要なプロジェクトの機能確認は別に残しています。