WSL2 休眠后无法唤醒，如何强制启动或恢复会话？

Question

WSL2 休眠后无法唤醒（表现为 `wsl -l -v` 显示状态为 `Stopped`，但 `wsl` 命令无响应、端口失效、文件系统不可访问）是常见问题，主因是 Windows 休眠/快速启动机制与 WSL2 虚拟机内核状态不一致导致 vmmem 进程僵死或 Hyper-V 虚拟交换机异常。**无需重装！** 可通过以下方式强制恢复：① 以管理员身份运行 PowerShell，执行 `wsl --shutdown` 清理残留实例；② 若仍卡住，运行 `netsh interface ipv4 set subinterface "vEthernet (WSL)" forwarding=enabled` 修复网络栈；③ 禁用 Windows 快速启动（电源选项 → 选择电源按钮功能 → 更改当前不可用设置 → 取消勾选“启用快速启动”）并重启，从根本上避免状态冲突。验证：`wsl -d Ubuntu`（或你的发行版名）应正常进入终端。建议将 `wsl --shutdown` 加入休眠前脚本，或使用 `wsl --terminate ` 主动管理会话生命周期。

Answer 1

```html

一、现象层：WSL2 休眠后“假死”状态的典型表征

用户执行 wsl -l -v 时可见发行版状态为 Stopped，但实际调用 wsl 命令无响应、localhost:3000 等端口服务不可达、/mnt/wsl/ 或 \\wsl$\ 文件系统访问超时或报错（如 0x80070005）。此非崩溃亦非未启动，而是 WSL2 内核与 Windows 宿主间状态同步断裂所致的“幽灵进程”现象。

二、机制层：Windows 快速启动与 WSL2 vmmem 生命周期冲突

• Windows 快速启动（Hybrid Boot）本质是 hibernation + shutdown 的混合态：内核会保存 session manager 和驱动状态至 hiberfil.sys，但不保存 Hyper-V 虚拟机运行时上下文；
• WSL2 启动后由 vmmem 进程托管轻量级 Linux VM，其网络栈依赖 vEthernet (WSL) 虚拟交换机；
• 休眠时，Windows 未通知 WSL2 安全终止，导致 vmmem 进程残留、虚拟网卡绑定中断、IP forwarding 标志丢失——进而引发 DNS 解析失败、端口转发失效、文件系统挂载阻塞。

三、诊断层：分阶段验证故障根因

检查项	命令/路径	预期健康输出
vmmem 进程存活状态	Get-Process vmmem -ErrorAction SilentlyContinue	无输出（已退出）或 CPU/RSS 显著异常
WSL 虚拟网卡转发能力	netsh interface ipv4 show subinterfaces "vEthernet (WSL)"	Forwarding 列值为 enabled
WSL 实例注册完整性	wsl --list --all --verbose	所有发行版状态为 Stopped 且无 Invalid 标记

四、修复层：三阶递进式恢复方案

1. 强制清理运行时残留：
   以管理员身份运行 PowerShell，执行：
   wsl --shutdown
   此操作终止所有 WSL2 实例并释放 vmmem 占用，是轻量级首选手段。
2. 修复网络栈一致性：
   若 wsl --shutdown 后仍无法启动，执行：
   netsh interface ipv4 set subinterface "vEthernet (WSL)" forwarding=enabled
   该命令重置虚拟网卡的 IPv4 转发标志，解决因快速启动导致的 forwarding 状态丢失问题。
3. 根治状态冲突源头：
   进入「控制面板 → 电源选项 → 选择电源按钮的功能 → 更改当前不可用设置」，取消勾选「启用快速启动」，重启 Windows。此举确保每次关机均为 clean shutdown，使 WSL2 可完整执行终止生命周期钩子。

五、工程化防护：构建可运维的 WSL2 生命周期管理

建议在生产环境或开发工作站中实施以下自动化策略：

# 示例：PowerShell 休眠前钩子（需注册为计划任务）
Register-WmiEvent -Class Win32_PowerManagementEvent -SourceIdentifier "OnSuspend" -Action {
  wsl --shutdown
  Write-EventLog -LogName Application -Source "WSL2" -EntryType Information -EventId 1001 -Message "WSL2 shutdown triggered before system suspend"
}

同时，日常调试可使用 wsl --terminate Ubuntu 精确终止单个发行版，避免全局 shutdown 影响其他正在运行的 WSL2 实例。

六、验证与可观测性：闭环确认恢复效果

graph LR
  A[执行 wsl --shutdown] --> B{wsl -d Ubuntu 是否立即进入 shell？}
  B -->|是| C[检查 localhost:port 是否响应]
  B -->|否| D[运行 netsh 修复命令]
  D --> E[再次执行 wsl -d Ubuntu]
  C --> F[验证 /mnt/c 可读写 & \\wsl$ 可浏览]
  F --> G[成功]

七、延伸思考：WSL2 与 Windows Subsystem for Android（WSA）的协同隐患

当 WSA 与 WSL2 共存时，二者均依赖 Hyper-V 虚拟化层及共享的 vEthernet 网络栈。若快速启动启用，WSA 的 WsaSubSystem 服务可能抢占同一虚拟网卡资源，加剧 WSL2 网络初始化失败概率。此时需额外检查 Get-Service WsaSubSystem 状态，并考虑按需禁用 WSA 以隔离故障域。

```