[!WARNING]
2026年8月23日 追記本記事は、WSLを旧バージョンへ安全にin-place downgradeするための手順をまとめたものです。
筆者環境では、WSL 2.7.11.0 / Kernel 6.18.33.2-2でkernel panicによるWSLの突然停止が複数回発生したため、切り分けの一環としてWSL 2.6.3.0 / Kernel 6.6.87.2-1へin-place downgradeしました。
しかし、2.6.3.0 / 6.6系でもkernel panicが再発したため、ダウングレードによる解決は確認できませんでした。その後、WSLを2.7.12.0 / Kernel 6.18.33.2-2へ戻しましたが、こちらでも
kernel BUG at fs/namei.c:844!の再発を確認しています。そのため、本記事で紹介するWSL 2.6.3.0へのダウングレードを、kernel panicやWSL突然停止の解決策として推奨するものではありません。
本記事は、WSLの特定バージョンへ切り戻す必要がある場合や、バージョン間で問題を切り分けるためのA/Bテストを行う場合の手順として参考にしてください。
また、古いWSLを長期間使用すると、その後に提供された不具合修正やセキュリティ修正を受けられない可能性があります。検証終了後はMicrosoft公式の最新情報を確認し、適切なバージョンへ戻すことを検討してください。
対象: Windows 11 + WSL 2 + Ubuntu
目的: WSL 2の新しいカーネルで不具合が疑われる場合などに、Ubuntuディストリビューションを消さず、バックアップを取得してからWSLを旧バージョンへin-place downgradeする。
重要:wsl --unregister Ubuntuは実行しない。
目次
- はじめに
- 1. 作業前の重要事項
- 2. 現在の環境を記録する
- 3. Docker / VS Code / WSLを停止する
- 4. Ubuntuを丸ごとバックアップする
- 5. バックアップから戻せることを理解しておく
- 6. ダウングレード先を決める
- 7. Microsoft公式GitHubからWSL 2.6.3.0のMSIを取得する
- 8. WSL 2.6.3.0へin-place downgradeする
- 9. Windowsを再起動する
- 10. WSLのバージョンを確認する
- 11. Ubuntuが残っていることを確認する
- 12. Ubuntu内のデータを確認する
- 13. Docker Desktop / Laravel Sailを段階的に確認する
- 14. kernel panicが再発するか確認する
- 15. 診断ログも併用する
- 16. 自動更新で6.18系へ戻らないよう注意する
- 17. 元に戻す場合
- 18. トラブル時の復旧
- まとめ
- 最重要ポイント
- 参考資料
はじめに
WSL 2の更新後、UbuntuそのものではなくWSLカーネル側の不具合によって、次のような症状が発生する場合があります。
- UbuntuのCLIが突然すべて終了する
- VS Code Remote - WSLの接続が突然切れる
- Docker / Laravel Sail利用中にWSL全体が停止する
- 診断ログに
Kernel panic - not syncing: Fatal exception
が記録される
Microsoft公式WSLリポジトリでは、6.18系カーネルで発生する回帰について、同一ワークロードが 6.6.114.1 では正常だったというA/Bテスト報告があります。
この記事では、まずUbuntuを丸ごとバックアップし、その後
Ubuntuを登録解除せずにWSL本体を旧バージョンへin-place downgrade
します。
1. 作業前の重要事項
絶対に実行しないコマンド
wsl --unregister Ubuntu
Microsoft公式ドキュメントでは、wsl --unregister を実行すると、そのディストリビューションに関連付けられたデータ・設定・ソフトウェアが完全に失われると明記されています。
今回の手順では Ubuntuの登録解除は行いません。
2. 現在の環境を記録する
通常のPowerShellで次を実行します。
wsl --version
wsl --status
wsl -l -v
例:
WSL バージョン: 2.7.11.0
カーネル バージョン: 6.18.33.2-2
NAME STATE VERSION
* Ubuntu Running 2
docker-desktop Stopped 2
Ubuntu側でも、現在使用しているWSLカーネルのバージョンを記録します。
uname -r
例:
6.18.33.2-microsoft-standard-WSL2
この値は、ダウングレード後に6.6系カーネルへ切り替わったことを確認するための比較用として残しておきます。
Gitで管理している開発プロジェクトがある場合は、未コミット変更も確認します。
git status
必要な変更はコミット・stash・別途バックアップしておきます。
3. Docker / VS Code / WSLを停止する
Docker Desktop、VS Code、Claude Code、CodexなどWSLを使用するアプリケーションを終了します。
その後、PowerShellで次を実行します。
wsl --shutdown
停止確認:
wsl -l -v
例:
NAME STATE VERSION
* Ubuntu Stopped 2
docker-desktop Stopped 2
Ubuntuが Stopped になっていることを確認してから次へ進みます。
4. Ubuntuを丸ごとバックアップする
バックアップ保存先を作成
例として次のフォルダーを使用します。
New-Item -ItemType Directory -Force C:\WSL-Backup
Ubuntuをtar形式でエクスポート
wsl --export Ubuntu C:\WSL-Backup\Ubuntu-before-wsl-downgrade.tar
容量によっては数分以上かかります。
完了後、ファイルを確認します。
Get-Item C:\WSL-Backup\Ubuntu-before-wsl-downgrade.tar
サイズが0バイトでないことを確認します。
SHA-256も記録する
バックアップファイルの破損検知用にハッシュを取得します。
Get-FileHash C:\WSL-Backup\Ubuntu-before-wsl-downgrade.tar -Algorithm SHA256
表示されたSHA-256をテキストなどへ保存しておきます。
wsl --exportはMicrosoft公式が提供しているWSLディストリビューションのバックアップ方法です。
5. バックアップから戻せることを理解しておく
万一Ubuntuの登録が壊れた場合は、エクスポートしたtarから別名で復元できます。
ただし、復元前にバックアップファイルが作成時から変化・破損していないことを確認します。
バックアップのSHA-256を再確認する
PowerShellで次を実行します。
Get-FileHash C:\WSL-Backup\Ubuntu-before-wsl-downgrade.tar -Algorithm SHA256
表示された Hash が、バックアップ作成時に記録したSHA-256と一致することを確認します。
バックアップ作成時にSHA-256を記録
↓
復元前にSHA-256を再計算
↓
記録しておいたSHA-256と比較
↓
一致することを確認
↓
復元へ進む
SHA-256が一致すれば、バックアップ作成時からファイル内容が変化していないことを確認できます。
一致しない場合は、バックアップファイルが作成時と同一であることを確認できないため、そのまま復元作業へ進まず、ファイルの破損や変更がないか確認します。
バックアップから別名で復元する
SHA-256の一致を確認できたら、必要に応じて次のように別名で復元できます。
wsl --import Ubuntu-Recovery C:\WSL\Ubuntu-Recovery C:\WSL-Backup\Ubuntu-before-wsl-downgrade.tar --version 2
この例では、既存の Ubuntu とは別に Ubuntu-Recovery
という名前で復元します。
通常のdowngradeでは、このコマンドは実行しません。
これは、万一Ubuntuの登録や起動に問題が発生した場合に、取得しておいたバックアップから復旧するための手段です。
元のUbuntuを削除する前に、復元した Ubuntu-Recovery を起動して、必要なデータが正常に読み取れることを必ず確認します。
wsl -d Ubuntu-Recovery
復元したUbuntu内では、ホームディレクトリや開発データなど、必要なファイルが残っていることを確認します。
6. ダウングレード先を決める
今回の目的は「単に古ければよい」ではありません。
Microsoft公式WSL Issueでは、6.18系で異常が発生する環境について、
6.18.33.2-2 affected
6.18.35.2-1 affected
6.6.114.1 clean
というA/Bテスト結果が報告されています。
またMicrosoft公式WSLリリース履歴では、WSLの6.6系カーネルとして 6.6.114.1 が確認できます。
そのため、今回のように6.18系kernel panicの回避を目的とする場合は、単にWSLのバージョン番号だけでなく、インストール後のKernel Versionが6.6系になったことを必ず確認します。
注意
WSL 2.6.3 へのrollbackで復旧した公式Issue報告もありますが、その報告で確認されているKernelは 6.6.87.2-1 です。
したがって、
「2.6.3だから必ず6.6.114.1になる」
とは断定しません。
目的は 6.18系を避けて、Microsoft提供の6.6系カーネルへ戻すこと です。
7. Microsoft公式GitHubからWSL 2.6.3.0のMSIを取得する
ダウンロード元は、必ずMicrosoft公式のWSL Releasesを使用します。
公式リリース:
今回の検証では、現在使用している
WSL : 2.7.11.0
Kernel : 6.18.33.2-2
から、Microsoft公式の
WSL : 2.6.3.0
へin-place downgradeします。
そのため、Microsoft公式WSL Releasesから WSL 2.6.3.0 のリリースを開き、Assetsから自分のCPUアーキテクチャに対応するMSIを取得します。
x64 Windows PCの場合
一般的なx64 Windows PCでは、次のMSIを使用します。
wsl.2.6.3.0.x64.msi
ARM64 Windows PCの場合
ARM64 PCでは、同じWSL 2.6.3.0リリースのARM64版MSIを使用します。
使用しているWindows PCのCPUアーキテクチャが不明な場合は、Windowsの「設定」→「システム」→「バージョン情報」で確認してからダウンロードします。
今回WSL 2.6.3.0を使用する理由
今回の目的は、単にWSLのバージョンを古くすることではありません。
現在の環境では、WSL Kernel 6.18.33.2-2でkernel panicが複数回発生しています。
そのため、6.18系カーネルを避け、Microsoft提供の6.6系カーネルへ戻した状態で同じ開発作業を行い、kernel panicが再発するかA/Bテストします。
変更前
WSL 2.7.11.0
Kernel 6.18.33.2-2
↓
WSL 2.6.3.0のMSIを取得
↓
Section 8でin-place downgrade
↓
変更後
WSL 2.6.3.0
Kernel 6.6系であることを確認
なお、WSL 2.6.3.0をインストールした場合に、必ず特定の6.6.xカーネルになるとは扱いません。
実際のKernel Versionは、インストール後に次のコマンドで確認します。
PowerShell:
wsl --version
Ubuntu:
uname -r
セキュリティ上の注意
MSIは必ずMicrosoft公式GitHubのWSL Releasesから取得します。
第三者配布サイトや、出所を確認できないミラーサイトからMSIをダウンロードしないでください。
ダウンロード後は、Section 8で wsl.2.6.3.0.x64.msi を使用してin-place downgradeを実施します。
8. WSL 2.6.3.0へin-place downgradeする
今回ダウングレードするバージョン
今回の検証では、現在使用している
WSL : 2.7.11.0
Kernel : 6.18.33.2-2
から、Microsoft公式の
WSL : 2.6.3.0
へin-place downgradeします。
使用するMSIは、Microsoft公式WSL Releasesから取得したx64版です。
wsl.2.6.3.0.x64.msi
今回の目的は、単にWSLのバージョンを古くすることではありません。
現在kernel panicが繰り返し発生している6.18系カーネルを避け、Microsoft提供の6.6系カーネルへ戻した状態で同じ開発作業を行い、kernel panicが再発するかA/Bテストすることが目的です。
変更前
WSL 2.7.11.0
Kernel 6.18.33.2-2
↓
in-place downgrade
↓
変更後
WSL 2.6.3.0
Kernel 6.6.x
なお、WSL 2.6.3.0をインストールした場合のKernel Versionは、実際のインストール後に確認します。
そのため、
「WSL 2.6.3.0をインストールすれば必ず特定の6.6.xになる」
とは扱いません。
インストール後に wsl --version とUbuntu側の uname -r を実行し、実際に6.6系カーネルへ切り替わったことを確認します。
Ubuntuはアンインストールしない
今回行うのは、
WSL 2.7.11.0 / Kernel 6.18.33.2-2
↓
Microsoft公式 wsl.2.6.3.0.x64.msi
↓
WSL 2.6.3.0 / Kernel 6.6系
↓
既存Ubuntu / VHDXはそのまま維持
というin-place downgradeです。
Ubuntu自体の再インストールや登録解除は行いません。
Microsoft WSLの公式GitHub
Discussionでは、Microsoftメンテナーが旧バージョンについて「2.6のMSIをインストール」と案内しており、実際に
wsl.2.6.3.0.x64.msi
を既存WSLへ上書きインストールし、既存ディストリビューション/VHDを維持したrollback事例があります。
MSIをGUIで実行する場合
Section 7でダウンロードしたMicrosoft公式の
wsl.2.6.3.0.x64.msi
を実行してインストールします。
UbuntuをMicrosoft Storeからアンインストールしたり、次のコマンドを実行したりする必要はありません。
wsl --unregister Ubuntu
wsl --unregister Ubuntu はUbuntuのデータを削除するため、今回の手順では実行しません。
msiexecを使用する場合
管理者PowerShellから、ダウンロードしたMSIの実際のパスを指定します。
例:
msiexec /i "C:\Users\<ユーザー名>\Downloads\wsl.2.6.3.0.x64.msi"
<ユーザー名> は実際のWindowsユーザー名に置き換えます。
最初は /quiet を付けず、インストーラーの表示を確認しながら実行する方が安全です。
インストール完了後は、次のSectionでWindowsを再起動し、実際のWSL VersionとKernel Versionを確認します。
9. Windowsを再起動する
MSIのインストールが完了したら、Windowsを再起動します。
再起動後、PowerShellを開きます。
10. WSLのバージョンを確認する
wsl --version
確認する項目:
WSL バージョン
カーネル バージョン
今回特に重要なのは カーネルバージョン です。
6.18系回帰を避ける検証なら、
6.6.x
になっていることを確認します。
11. Ubuntuが残っていることを確認する
PowerShellで次を実行します。
wsl -l -v
例:
NAME STATE VERSION
* Ubuntu Stopped 2
docker-desktop Stopped 2
Ubuntuが一覧に残っていれば、既存ディストリビューションの登録は維持されています。
Ubuntuを起動します。
wsl -d Ubuntu
正常に起動すると、PowerShellからUbuntuのシェルへ切り替わります。
例えば、PowerShellで次の場所から実行した場合、
PS C:\Users\ユーザ名> wsl -d Ubuntu
次のように表示されることがあります。
ユーザ名@PC名:/mnt/c/Users/ユーザ名$
これは起動失敗ではありません。
Ubuntuは正常に起動しています。
wsl -d Ubuntu
をWindows側のカレントディレクトリから実行すると、その場所をWSL側のパスとして引き継いで起動することがあります。
今回の場合、
C:\Users\ユーザ名
がWSL側では、
/mnt/c/Users/ユーザ名
として表示されています。
Ubuntuのホームディレクトリへ移動する場合は、次を実行します。
cd ~
現在位置を確認します。
pwd
例:
/home/ユーザ名
この状態になれば、普段使用しているUbuntu側のホームディレクトリへ移動できています。
続いて、Ubuntu側でも実際に使用されているカーネルを確認します。
uname -r
今回のWSL 2.6.3.0へのin-place downgrade後は、6.6系カーネルへ切り替わっていることを確認します。
12. Ubuntu内のデータを確認する
Ubuntuで次を確認します。
whoami
pwd
ls ~
開発プロジェクト:
ls ~/projects
対象リポジトリ:
cd ~/projects/<project-name>
git status
さらにカーネルを確認します。
uname -r
目的の6.6系になっているか確認します。
13. Docker Desktop / Laravel Sailを段階的に確認する
いきなり全部起動せず、段階的に確認します。
Ubuntu単独
uptime
free -h
VS Code
WSL Remoteでプロジェクトを開きます。
Docker Desktop
Docker Desktopを起動します。
PowerShell:
wsl -l -v
Laravel Sail
プロジェクトで:
./vendor/bin/sail up -d
Vite
必要なら:
./vendor/bin/sail npm run dev
その後、通常の開発作業を行います。
14. kernel panicが再発するか確認する
今回の目的は、WSL 2.7.11.0 / Kernel 6.18.33.2-2で発生していたkernel panicが、WSL 2.6.3.0 / Kernel 6.6系へ切り戻した場合に再発するか確認するA/Bテストです。
変更前:
WSL 2.7.11.0
Kernel 6.18.33.2-2
→ kernel panicが複数回発生
変更後:
WSL 2.6.3.0
Kernel 6.6.87.2-1
→ 同じ開発環境で検証
実機での検証結果
筆者環境では、WSL 2.6.3.0 / Kernel 6.6.87.2-1へin-place downgradeした後もkernel panicが再発しました。
そのため、今回の環境では、
6.18系から6.6系へ切り戻す
↓
kernel panicが解消する
という結果にはなりませんでした。
さらに、その後WSL 2.7.12.0 / Kernel 6.18.33.2-2へ戻して検証したところ、こちらでも次のkernel BUGが再発しました。
kernel BUG at fs/namei.c:844!
したがって、本記事のダウングレード手順はkernel panicの解決策としてではなく、WSLの特定バージョンへ切り戻す必要がある場合や、バージョン間で問題を切り分けるための手順として利用してください。
15. 診断ログも併用する
downgrade後も、しばらくMicrosoft公式の collect-wsl-logs.ps1 を使って監視すると、6.18系と6.6系でWSLの挙動を比較しやすくなります。
今回のように、
- UbuntuのCLIが突然終了する
- Claude Code / CodexのCLIも同時に終了する
- VS Code Remote - WSLの接続が切断される
- 気付いた時にはWSL自体が再起動している
という症状では、落ちた瞬間にUbuntu側でコマンドを実行することはできません。
そこで、Windows側の管理者PowerShellで先に診断ログ収集を開始しておき、普段どおり作業して、WSLが落ちた後にログを保存する方法を使います。
15-1. 管理者PowerShellを起動する
Windowsで PowerShellを「管理者として実行」 します。
診断中は、このPowerShellを閉じずにそのまま残しておきます。
15-2. Microsoft公式の診断スクリプトを取得する
管理者PowerShellで次を実行します。
Invoke-WebRequest -UseBasicParsing "https://raw.githubusercontent.com/microsoft/WSL/master/diagnostics/collect-wsl-logs.ps1" -OutFile collect-wsl-logs.ps1
取得元はMicrosoft公式GitHubリポジトリ microsoft/WSL の以下のファイルです。
diagnostics/collect-wsl-logs.ps1
第三者サイトから同名のスクリプトを取得しないようにします。
15-3. このPowerShellプロセスだけスクリプト実行を許可する
Set-ExecutionPolicy Bypass -Scope Process -Force
-Scope Process のため、設定は現在開いているPowerShellプロセスだけに適用されます。
PowerShellを終了すれば、この設定は残りません。
15-4. 診断ログの収集を開始する
.\collect-wsl-logs.ps1
正常に開始すると、次のようなメッセージが表示されます。
Log collection is running. Please reproduce the problem and once done press any key to save the logs.
意味は次のとおりです。
ログ収集中です。問題を再現してください。終了したら何かキーを押してログを保存してください。
15-5. PowerShellはそのままにして通常作業する
この時点ではキーを押さず、診断用PowerShellも閉じません。
そのまま普段どおり、例えば次の環境を使用します。
- VS Code + WSL Remote
- Docker Desktop
- Laravel Sail
- Vite (
sail npm run dev) - Composer
- Claude Code
- Codex
WSLが突然停止するまで、診断用PowerShellを監視し続ける必要はありません。
イメージとしては、落ちる瞬間を手動で捕まえるのではなく、Windows側で先に「監視カメラ」を回しておく形です。
診断ログ収集開始
↓
通常どおり開発
↓
WSL突然停止
↓
Ubuntu / CLI / VS Code Remoteが切断
↓
Windows側の診断PowerShellは残る
↓
診断PowerShellで何かキーを押す
↓
ログ保存
15-6. WSLが落ちたらログを保存する
次のような症状が再発したら、Windows側で開いておいた診断用PowerShellへ戻ります。
- Ubuntu CLIが終了した
- Claude Code / Codexも終了した
- VS CodeのWSL Remote接続が切断された
- VS CodeがWSLへ再接続しようとしている
そこで 何かキーを1回押します。
診断スクリプトがログ収集を終了し、WslLogs-YYYY-MM-DD_HH-MM-SS.tar.gz のような診断ログを保存します。
保存されたアーカイブには、環境によって次のような情報が含まれます。
logs.etl
wslservice.txt
windows-version.txt
bcdedit.txt
Winsock2.txt
...
特に logs.etl はWindows Event Tracing for Windows（ETW）のトレースで、WSL / Hyper-V / VMの異常を調べる際の重要な診断材料になります。
15-7. ログを公開する前に内容を確認する
診断ログには、WSL・Windows・ネットワーク・Hyper-Vなど、PC環境に関する情報が含まれる可能性があります。
そのため、
生成された tar.gz を内容確認せず、公開GitHub IssueやSNSへそのままアップロードしないようにします。
MicrosoftへIssue報告する場合でも、まず収集内容を確認してから添付する方が安全です。
15-8. uptime でWSLが再起動したか確認する
Ubuntuを起動し直した後、次を実行します。
uptime
例:
19:54:29 up 4:26, 2 users, load average: 0.11, 0.10, 0.09
今回の調査で特に重要なのは up の部分です。
up 4:26
なら、Ubuntu / WSLが起動してから4時間26分経過しています。
長時間作業していたはずなのに、
up 1 min
となっていれば、WSL / Ubuntuが直近で再起動したことを確認する材料になります。
15-9. free -h でメモリ不足か確認する
Ubuntuで次を実行します。
free -h
例:
total used free shared buff/cache available
Mem: 15Gi 3.5Gi 10Gi 54Mi 1.6Gi 12Gi
Swap: 4.0Gi 0B 4.0Gi
特に確認するのは次の3点です。
used
available
Swap used
Linuxは未使用RAMをファイルキャッシュとして積極的に利用するため、単純な free の値だけでメモリ不足とは判断しません。
例えば、
total 15Gi
used 3.5Gi
available 12Gi
Swap used 0B
なら、まだ十分な余裕があります。
今回の障害調査でも、Docker Desktop、Laravel Sail、Vite、Claude Code、Codexなどを起動した状態で available に十分な余裕があり、Swapもほとんど使用されていませんでした。
そのため、少なくとも観測した各時点では、通常時の単純なメモリ不足がWSL突然停止の原因とは確認できませんでした。
16. 自動更新で6.18系へ戻らないよう注意する
動作確認中に、
wsl --update
を実行すると、新しいWSL/Kernelへ再更新される可能性があります。
A/Bテスト期間中は、意図せず更新しないよう注意します。
ただし、セキュリティ修正もWSL更新に含まれるため、永久に古いバージョンへ固定する運用は推奨しません。
検証が終了したら、Microsoft公式のWSL ReleasesやIssuesで最新情報を確認し、必要に応じて現行の適切なバージョンへ戻すことを検討します。
17. 元に戻す場合
Microsoftが修正版を公開し、最新版へ戻す場合は、PowerShellで:
wsl --update
更新後:
wsl --shutdown
wsl --version
必要に応じてWindowsを再起動します。
18. トラブル時の復旧
Ubuntuが起動しない
慌てて次を実行しない:
wsl --unregister Ubuntu
まず:
wsl --shutdown
wsl -l -v
wsl --status
wsl --version
を確認します。
最終手段としてバックアップを別名で復元
wsl --import Ubuntu-Recovery C:\WSL\Ubuntu-Recovery C:\WSL-Backup\Ubuntu-before-wsl-downgrade.tar --version 2
復旧用Ubuntuを起動:
wsl -d Ubuntu-Recovery
元のUbuntuを消す前に、復旧側でデータが正常に読めることを必ず確認します。
まとめ
安全な順序は次の通りです。
現在のバージョンを記録
↓
Gitの未保存作業を確認
↓
Docker / VS Code等を終了
↓
wsl --shutdown
↓
wsl --export でUbuntuをバックアップ
↓
バックアップファイル + SHA-256確認
↓
Microsoft公式WSL Releasesから旧MSI取得
↓
既存WSLへin-place install
↓
Windows再起動
↓
wsl --version / uname -r
↓
Ubuntuデータ確認
↓
Docker / Sail等を段階的に起動
↓
6.6系でkernel panicが再発するかA/Bテスト
最重要ポイント
-
wsl --unregister Ubuntuは実行しない - Ubuntuをアンインストールしない
- downgrade前に
wsl --exportを取得する - MSIはMicrosoft公式GitHub Releasesから取得する
- WSLバージョンだけでなく
uname -rでKernel Versionを確認する - 6.6系へのrollbackは解決策と断定せず、切り分け・検証手段として扱う
- 修正版が出たらセキュリティ面も考慮して最新版への復帰を検討する
参考資料
-
Microsoft Learn: WSL の基本的なコマンド
https://learn.microsoft.com/ja-jp/windows/wsl/basic-commands -
Microsoft公式 WSL Releases
https://github.com/microsoft/WSL/releases -
Microsoft WSL Discussion #40318 --- 旧MSIを用いたin-place
downgrade事例
https://github.com/microsoft/WSL/discussions/40318 -
Microsoft WSL Issue #40488 --- WSL 2.6.3へのrollbackで復旧した報告
https://github.com/microsoft/WSL/issues/40488 -
Microsoft WSL Issue #41019 ---
6.18系で再現し、6.6.114.1でA/Bテストが正常だった報告
https://github.com/microsoft/WSL/issues/41019
免責:
本記事は、Microsoft公式ドキュメント・公式WSLリポジトリの情報と実際の障害切り分けを基にした手順です。in-place
downgradeでも環境依存の障害が起きる可能性はあるため、重要データは必ず別媒体にもバックアップしてください。