记一次WSL2周末关机后彻底罢工的惨痛修复经历

大家好啊，又到了每月产出文章的时间了。这次不聊高深的技术原理，就想跟大家分享一个这两天把我折磨得死去活来的真实事故——我亲爱的 WSL2 (Ubuntu-20.04) 在周末关个机之后，突然就罢工了。

周一早上，迎面痛击

本以为周末充满电，周一能直接高效产出。结果一打开电脑，习惯性地打开项目文件夹，迎面就是一个红色的报错：
\\wsl.localhost\Ubuntu-20.04 无法访问。你可能有权限使用网络资源...

当时还没当回事，想着重启一下就好。结果打开 PowerShell 输入 wsl --shutdown 也没用。更离谱的是，点击 Ubuntu 终端，它闪一下就没了，连个报错的机会都不给我。

陷入绝望的排查之旅

由于我是直接登录的 root 用户，项目数据都挂在 WSL 里，当时心态已经有点崩了。我按照常规思路尝试了 wsl --update，结果显示已是最新。想着可能是注册表被锁了，于是准备去修改 Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Drive\shell\WSL 这些文件夹，结果系统无情地提示：“无法保存对 WSL 权限所作的更改。拒绝访问。”

这就很尴尬了，连系统都不让我改自己家的注册表？这感觉就像是自己的家门钥匙被自己弄丢了，还死活配不上一把新的。

接着尝试导出数据 wsl --export 想紧急抢救一下，结果直接报错：错误代码: Wsl/Service/CreateVm/HCS/ERROR_FILE_NOT_FOUND。这下真的慌了，系统提示找不到文件，以为是虚拟硬盘丢了。

柳暗花明，暴力强装

后来查了一下，判断大概率是核心组件（比如 system.vhd）在关机时损坏了，导致虚拟机创建失败，从而触发了各种奇怪的权限和找不到文件的报错。

常规手段行不通，只能尝试手动安装新的 MSI 安装包。尴尬的是，GitHub 直接访问很慢，动不动就显示要下载两个小时。好不容易找到国内分流站下好了 wsl.2.7.12.0.x64.msi，结果双击安装也是闪一下就没了，根本不知道它有没有运行。

既然 GUI 不行，我直接打开管理员权限的 PowerShell，手动执行了强制安装命令：
msiexec /i wsl.2.7.12.0.x64.msi

虽然这个命令执行后终端依然显示闪退了，但抱着死马当活马医的心态，我去看了一眼版本号。输入 wsl --version，屏幕居然打印出了完整的版本信息！原来它刚才在后台偷偷装好了！

绝处逢生

紧接着，我赶紧输入了 wsl -d Ubuntu-20.04。熟悉的 Welcome to Ubuntu 界面跃然屏上！数据居然完好无损（因为之前那个找不着的文件 ext4.vhdx 其实只是没被挂载，新引擎加载后它又活了）。

虽然默认进到了 root 用户，而且停在 C 盘的路径里，但只要在终端敲一下 ls /home，看到我熟悉的项目文件夹还在，那一刻悬着的心终于放下了。最后设置一下默认用户，项目完全恢复正常。

总结经验

这次经历告诉大家一个道理：

1. 遇到 WSL 连不上且终端闪退，先别急着卸载或重装，大概率是引擎坏了，可以尝试手动强制安装最新的 MSI 覆盖一遍。
2. 重要数据一定要定期备份！ 尤其是那个位于 C:\Users\...\AppData\Local\Packages\...\ext4.vhdx 的文件，只要它在，希望就在。
3. 微软的 WSL 虽然好用，但遇到周末关机这种非正常断电/休眠的情况，偶尔会“抽风”。安装新引擎强制覆盖是最后的救命稻草。

希望这篇踩坑记录能帮到同样被 WSL 折磨的兄弟们，如果你们也遇到了类似问题，千万别轻易删数据，先试试更新内核！