ちらりんブログ ロゴ ちらりんブログ
TECH · WSL · WSL2

WSL E_UNEXPECTED エラーからの完全復旧記録 -- ext4破損からデータ救出まで

PC再起動後にWSLがE_UNEXPECTEDエラーで起動不能に。ext4ファイルシステム破損が原因でした。wsl --mount --vhd --bareでデータを救出し、新規インストールで完全復旧するまでの全記録です。

tech 2026-04-13 41 min read by ちらりん
cover · 1024×1024

はじめに

PC再起動後、WSLが二度と起動しなくなりました。

2026年4月9日。いつも通りの再起動のつもりでした。しかしVSCodeからWSLに接続しようとすると沈黙。ターミナルから wsl を叩くと返ってきたのは Wsl/Service/E_UNEXPECTED という、見たこともないエラーでした。

結論から言うと、ext4ファイルシステムの破損が原因で、ディストロの修復は不可能でした。しかし wsl --mount --vhd --bare でデータを救出し、新規インストールからの完全復旧に成功しました。

この記事では、原因特定からデータ救出、環境再構築までの全工程を時系列で記録しています。同じエラーに遭遇した方の助けになれば幸いです。

Phase 1: 状態確認 – 何が起きているのか

まずWSL自体の状態を確認しました。

snippet 
PS> wsl --status
既定のディストリビューション: Ubuntu-24.04
既定のバージョン: 2

WSL2として認識されており、既定ディストロも正しい状態です。ディストロの稼働状態を見ます。

snippet 
PS> wsl -l -v
  NAME            STATE           VERSION
* Ubuntu-24.04    Stopped         2

Stopped。起動を試みます。

snippet 
PS> wsl
致命的なエラーです。
エラー コード: Wsl/Service/E_UNEXPECTED

起動自体が失敗しています。 Stoppedなだけではなく、起動プロセスのどこかで致命的なエラーが発生しています。この時点では原因が全く分かりませんでした。

Phase 2: サービス・コンポーネント修復試行

「WSL E_UNEXPECTED」で検索すると、多くの記事が「WSLサービスの再起動」や「WSLの再インストール」を勧めています。一通り試しました。

WSLサービスの再起動

まずWindowsサービスの確認から。LxssManager は古いWSL1時代のサービス名で、もう存在しません。

snippet 
PS> net stop LxssManager
無効なサービス名です。

正式なサービス名を検索します。

snippet 
PS> Get-Service | Where-Object { $_.DisplayName -like "*WSL*" -or $_.DisplayName -like "*Linux*" }
Status   Name               DisplayName
------   ----               -----------
Running  WSLService         WSL Service

WSLServiceはRunning。サービス自体は動いています。念のため再起動しました。

snippet 
PS> Restart-Service WSLService
PS> wsl
致命的なエラーです。
エラー コード: Wsl/Service/E_UNEXPECTED

変化なし。問題はWSLサービスレベルではありません。

仮想化基盤の確認

WSL2はHyper-Vベースの軽量VMで動作します。仮想化関連の機能を確認しました。

snippet 
PS> dism /online /get-featureinfo /featurename:Microsoft-Hyper-V
エラー: 0x800f080c
機能名 Microsoft-Hyper-V は不明です。
snippet 
PS> dism /online /get-featureinfo /featurename:VirtualMachinePlatform
状態 : 有効

Microsoft-Hyper-VはWindows Home Editionのため存在しません。これは正常です。VirtualMachinePlatformは有効済み。仮想化基盤に問題はありません。

WSLコンポーネントの更新・再インストール

snippet 
PS> wsl --update --pre-release
Linux 用 Windows サブシステムをバージョン 2.7.1 に更新しています。

更新後も同じエラーでした。WSLコンポーネント自体の再インストールも試しました。

snippet 
PS> wsl --install --no-distribution
この操作を正しく終了しました。

PC再起動。結果は同じ E_UNEXPECTED です。

ここまでで分かったこと: WSLサービスは正常に動いています。仮想化基盤も問題ありません。WSLコンポーネントの更新・再インストールも効果なし。つまり、WSL基盤側の問題ではない可能性が高いです。

Phase 3: 問題の切り分け – VM層かディストロ層か

ここで転機になったのが wsl --debug-shell です。このコマンドはディストロを介さずWSL VMに直接接続します。WSL2の構造を「VM層」と「ディストロ層」に分離して考えることができます。

snippet 
PS> wsl --debug-shell
Welcome to Microsoft Azure Linux 3.0 (x86_64) - (hvc2)
Chillaptop login: root (automatic login)

WSL VMは正常に起動しました。 ただし直後に切断されました。

snippet 
エラー コード: Wsl/DebugShell/ERROR_PIPE_NOT_CONNECTED

これで問題の所在が明確になりました。VM層（WSL基盤）は正常に動いています。問題はディストロ内部にあります。

イベントログの確認

念のためWindowsのイベントログも確認しました。

snippet 
PS> Get-WinEvent -LogName System -MaxEvents 20 | Where-Object { $_.Message -like "*WSL*" }

WSL（Hyper-V firewall）のネットワーク初期化はすべて正常に完了していました。ネットワーク層の問題でもありません。

Phase 4: データバックアップ – まず逃がす

ディストロ内部の問題と分かった時点で、方針を切り替えました。修復よりもまずデータの確保が最優先です。

vhdxファイルの場所を探す

WSLのディスクイメージ（ext4.vhdx）を探す必要があります。デフォルトの AppData\Local\Packages 配下を探しましたが見つかりません。Cドライブ全体を検索しても出てきませんでした。

snippet 
PS> Get-ChildItem -Path "C:\" -Filter "*.vhdx" -Recurse -ErrorAction SilentlyContinue
（結果なし）

WSLストア版は、従来とは異なるパスに保存されています。 レジストリから正確なパスを取得しました。

snippet 
PS> Get-ChildItem "HKCU:\Software\Microsoft\Windows\CurrentVersion\Lxss" -Recurse |
    Get-ItemProperty | Select-Object DistributionName, BasePath

DistributionName BasePath
---------------- --------
Ubuntu-24.04     C:\Users\<ユーザー名>\AppData\Local\wsl\{xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}

このパス配下に ext4.vhdx がありました。ここでひとつ注意点があります。WSLストア版のvhdxは AppData\Local\Packages ではなく AppData\Local\wsl\{GUID} に保存されます。ネット上の古い情報に惑わされないようにしてください。

vhdxのバックアップ

まずvhdxファイルをそのままコピーしました。

snippet 
PS> Copy-Item "C:\Users\<ユーザー名>\AppData\Local\wsl\{...}\ext4.vhdx" -Destination "C:\temp\wsl_backup.vhdx"

コピー後、元ファイルとサイズが一致していることを確認。バックアップ完了です。

wsl –export の試行（失敗）

tar形式でのエクスポートも試みましたが、これは失敗しました。

snippet 
PS> wsl --export Ubuntu-24.04 C:\temp\wsl_export.tar
エクスポートが進行中です。これには数分かかる場合があります。 (290 MB)
bsdtar: Can't open `final.target': Input/output error
エラー コード: Wsl/Service/WSL_E_EXPORT_FAILED

final.target（systemdのターゲットファイル）でI/Oエラー。この時点でファイルシステム破損の可能性が浮上しました。

Phase 5: 修復試行と断念

バックアップ済みのvhdxを使って、ディストロを再登録してみました。

snippet 
PS> wsl --unregister Ubuntu-24.04
登録解除。

PS> wsl --import Ubuntu-24.04 "C:\Users\<ユーザー名>\AppData\Local\wsl\Ubuntu-24.04" "C:\temp\wsl_backup.vhdx" --vhd
この操作を正しく終了しました。

PS> wsl -d Ubuntu-24.04
致命的なエラーです。
エラー コード: Wsl/Service/E_UNEXPECTED

同じvhdxを再登録しても同じエラーです。これで確定しました。vhdx内のファイルシステム自体が壊れています。 WSLの設定やレジストリの問題ではなく、ディスクイメージの中身が原因です。

Phase 6: 新規インストールとデータ救出

修復は諦めて、新規インストール + 旧vhdxからのデータ救出に切り替えました。

新規ディストロのインストール

snippet 
PS> winget install --id Canonical.Ubuntu.2404 --source winget
インストールが完了しました

wsl -l -v ではまだ表示されませんでしたが、スタートメニューから「Ubuntu 24.04」を起動して初回セットアップ（ユーザー名・パスワードの設定）を完了させました。

snippet 
PS> wsl -l -v
  NAME            STATE           VERSION
* Ubuntu-24.04    Running         2

新しいディストロが正常に起動しました。ここまで来ればあとはデータを戻すだけです。

旧vhdxからのデータ救出

ここが今回の復旧で最も重要なポイントです。壊れたvhdxを、新しいWSLからブロックデバイスとしてマウントします。

snippet 
PS> wsl --mount "C:\temp\wsl_backup.vhdx" --vhd --bare
この操作を正しく終了しました。

--bare オプションは、vhdxをWSL内のブロックデバイスとして接続するが自動マウントはしない、という意味です。破損したファイルシステムをいきなりマウントするのは危険なので、まず手動で確認します。

WSL内でブロックデバイスを確認します。

snippet 
$ lsblk
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
sda      8:0    0 364.8M  1 disk
sdb      8:16   0 144.5M  1 disk
sdc      8:32   0     2G  0 disk [SWAP]
sdd      8:48   0     1T  0 disk /
sde      8:64   0     1T  0 disk       ← 旧vhdx
sdf      8:80   0     1T  0 disk

sdeが旧vhdxです。読み取り専用でマウントしました。

snippet 
$ sudo mount -o ro /dev/sde /mnt/backup
$ ls /mnt/backup/home/
chillarin

マウントに成功しました。 ext4のジャーナルリカバリが自動で走り、読み取り専用でのマウントが可能になりました。起動はできなくても、ファイル単位での読み取りはできます。これがext4ジャーナリングの恩恵です。

データ復元

rsyncで旧ホームディレクトリの内容をまるごと復元しました。

snippet 
$ sudo rsync -ah --progress /mnt/backup/home/chillarin/ /home/chillarin/

新規ディストロではUIDが異なるため、パーミッションを修正します。

snippet 
$ sudo chown -R chillarin:chillarin /home/chillarin/

復旧確認です。

snippet 
$ ls ~/.ssh/
config  id_ait  id_ait.pub  id_ait_cisco  id_ait_cisco.pub  known_hosts  known_hosts.old

$ ls ~/
ansible  ansible-venv  go  go-dist  projects  protoc  terraform  work

SSH鍵、Ansibleのプレイブック、Terraformの定義、プロジェクトファイル。すべて帰ってきました。VSCodeからのWSL接続も正常に動作しました。

一安心。そう思いました。

Phase 7: データの復旧は環境の復旧ではない

安心したのも束の間でした。開発作業を再開しようとプロジェクトディレクトリに移動し、git status を叩いた瞬間。

snippet 
$ git status
Command 'git' not found, but can be installed with:
sudo apt install git

gitが入っていません。

冷静に考えれば当然です。rsyncで復元したのは /home/chillarin/ 配下のユーザーデータだけ。gitやその他の開発ツールはシステムパッケージとしてインストールされていたもので、ホームディレクトリにはありません。新規インストールしたUbuntuは、まっさらな状態です。

Ubuntu 24.04はデフォルトでgitがプリインストールされていません。手動でインストールが必要でした。

snippet 
$ sudo apt update && sudo apt install -y git

gitを入れたら次はGitHub CLI。認証が必要なリポジトリへのpushにはghが要ります。

snippet 
$ sudo apt install -y gh
$ gh auth login

他にも、開発に必要なパッケージを洗い出して入れ直す作業が続きました。Python仮想環境の再構築、Go関連ツールの確認、各種CLIツールのインストール。ファイルは全部戻っていても、それを動かす「道具」がすべて消えていました。

「データの復旧」と「環境の復旧」は別物です。 ファイルが戻れば復旧完了ではありません。開発環境には、aptでインストールしたパッケージ群、シェルの設定、言語ランタイム、各種CLIツールなど、ホームディレクトリの外にあるものが大量にあります。これらは rsync では戻りません。

Phase 8: 原因の特定（事後調査）

復旧作業がひと段落した後、旧vhdxをマウントした状態で dmesg を確認し、根本原因を特定しました。

snippet 
EXT4-fs (sde): INFO: recovery required on readonly filesystem
EXT4-fs (sde): write access will be enabled during recovery
EXT4-fs warning (device sde): ext4_clear_journal_err:6312:
  Filesystem error recorded from previous mount: IO failure
EXT4-fs warning (device sde): ext4_clear_journal_err:6320:
  Marked fs in need of filesystem check.
EXT4-fs (sde): recovery complete
EXT4-fs (sde): mounted filesystem ro with ordered data mode.
snippet 
EXT4-fs (sde): error count since last fsck: 16
EXT4-fs (sde): initial error at time 1775663638: ext4_validate_block_bitmap:421
EXT4-fs (sde): last error at time 1775666188: ext4_validate_block_bitmap:421

ブロックビットマップの破損が16箇所。 PC再起動時にWSLが正常にシャットダウンされず、ext4のメタデータが不整合な状態で放置された結果です。

旧ディストロの起動試行時のエラーログも残っていました。

snippet 
WSL (2 - init-systemd) ERROR: /sbin/ldconfig failed with status 0x100
WSL (2 - init-systemd) ERROR: Processing ldconfig failed
WSL (2 - init-systemd) ERROR: symlink(/mnt/wsl/resolv.conf, /etc/resolv.conf) failed 17
WSL (2 - init-systemd) ERROR: creat /etc/hostname failed: 5
WSL (2 - init-systemd) ERROR: creat /etc/hosts failed 5
WSL (1 - init-systemd) ERROR: execvpe(/sbin/init) failed 5
WSL (1 - init()) ERROR: Init has exited. Terminating distribution

エラーコード5はすべてEIO（Input/output error）です。ファイルシステム破損により、ディストロ初期化処理のどのステップもI/Oエラーで失敗しています。ldconfig、resolv.conf、hostname、hostsの生成、そして最終的に /sbin/init の実行まで、すべてが連鎖的に失敗して起動を断念しました – これが E_UNEXPECTED の正体でした。

教訓

今回の復旧から得た学びをまとめます。

  • WSLのvhdxは定期バックアップすべきです。 wsl --export またはvhdxファイルの直接コピーで構いません。PCの突然の再起動でファイルシステムが壊れるリスクは現実にあります
  • vhdxが壊れていても wsl --mount --vhd --bare でデータ救出が可能です。 ext4ジャーナルリカバリのおかげで、起動できないディストロからでもファイルを読み取れました
  • wsl --debug-shell でVM層とディストロ層の問題を切り分けられます。 VMが起動するならWSL基盤は正常。問題はディストロ内部にあります
  • WSLストア版のvhdxは AppData\Local\wsl\{GUID} に保存されます。 レジストリ HKCU:\...\Lxss のBasePathで場所を特定できます。ネット上の古い情報（AppData\Local\Packages 配下）にはご注意ください
  • PC再起動前に wsl --shutdown を実行する習慣をつけましょう。 明示的なシャットダウンでファイルシステム破損のリスクを下げられます
  • データの復旧は環境の復旧ではありません。 ホームディレクトリを丸ごと戻しても、gitすら入っていない状態です。aptパッケージ一覧のエクスポートやセットアップスクリプトの用意も検討してください

最後の教訓は意外と見落としがちです。バックアップというとファイルの保全に意識が向きますが、開発環境は「ファイル + ツール + 設定」の三位一体で成り立っています。どれか一つが欠けても、すぐには仕事に戻れません。

今回はClaudeと二人三脚で復旧に当たりましたが、パニックに陥らず体系的に切り分けを進められたのは大きかったです。WSLが壊れた時、まず必要なのは冷静さと、データを逃がす判断力です。

· · ·
Related Stories
tech
監視VMのディスクフル原因4重奏 — Splunk・journald・Prometheus・VFreeを一気に直して NAS 段階退避まで設計し直した話
2026-05-15
tech
VMが起動しない日の話 -- Proxmoxクラスタで e1000e・NFS・監視ギャップが同時に刺さった複合障害
2026-05-13

コメント