一次 WSL2 启动失败的排障复盘：最终发现是 WSL 版本兼容性问题
最近排查了一次比较绕的 WSL2 故障，环境是在一台运行于 ZStack/KVM 上的 Windows 10 虚机里。现象看起来很像宿主机虚拟化能力、Hyper-V 或 HNS 网络出了问题，但最后确认，真正的根因其实是 WSL 新版本兼容性问题。
回退并重装 wsl.2.7.3.0.x64.msi 后，问题恢复。
一、问题现象
故障机器前一天还能正常使用 WSL，第二天突然无法进入 Linux：
PS C:\Windows\system32> wsl
由于超时时间已过，该操作返回。
错误代码: Wsl/Service/CreateInstance/CreateVm/0x800705b4
但是从表面看，WSL 组件本身又是正常的：
PS C:\Windows\system32> wsl --status
默认分发: Ubuntu-24.04
默认版本: 2
PS C:\Windows\system32> wsl --version
WSL 版本: 2.7.8.0
内核版本: 6.18.33.1-1
WSLg 版本: 1.0.73.2
MSRDC 版本: 1.2.6676
Direct3D 版本: 1.611.1-81528511
DXCore 版本: 10.0.26100.1-240331-1435.ge-release
Windows: 10.0.19045.6466
也就是说：
wsl --status正常wsl --version正常- 默认发行版还在
- 默认版本还是 WSL2
但执行 wsl 本身会直接卡死并超时。
二、最开始怀疑的方向
因为这台机器跑在 ZStack/KVM 上，第一反应很自然会怀疑下面几类问题：
- 宿主机迁移后 nested virtualization 没透传好
- Hyper-V 能力异常
- WSL2 轻量虚机创建失败
- HNS / ICS 网络状态损坏
- Ubuntu 的 ext4.vhdx 文件损坏
这些方向都很合理，因为报错点是：
Wsl/Service/CreateInstance/CreateVm/0x800705b4
从字面看就是卡在了 CreateVm 阶段。
三、排查过程
1. 检查 WSL 组件和发行版状态
先看 WSL 基础状态：
wsl --status
wsl --version
wsl -l -v
故障机上发行版仍然存在：
NAME STATE VERSION
* Ubuntu-24.04 Stopped 2
说明不是发行版丢失，也不是 WSL 完全没装上。
同时检查发行版磁盘文件也还在：
Get-Item D:\WSL\Ubuntu-24.04\ext4.vhdx
结果显示 ext4.vhdx 正常存在，所以也不是数据盘文件直接没了。
2. 检查 Windows 服务链路
继续看 WSL/Hyper-V 相关服务：
Get-Service vmcompute,hns,LxssManager,hvhost
故障机上这些服务大多是正常的：
- vmcompute 运行中
- hns 运行中
- hvhost 运行中
- LxssManager 停止，但这是按需启动服务，不一定异常
这说明问题不是简单的”服务没起来”。
3. 检查启动时的进程状态
在启动 WSL 的同时抓进程：
Get-Process wsl,wslservice,vmcompute,vmwp,vmmem -ErrorAction SilentlyContinue
故障机在执行 wsl 时，能看到：
- vmwp
- vmmem
- wslservice
- vmcompute
这说明一件很关键的事：WSL2 的轻量虚机其实已经开始尝试启动了。所以问题并不是根本没有进入 Hyper-V，而是已经开始创建 VM，但在后续初始化过程中超时。
4. 对比正常机器
为了避免在故障机上”脑补根因”，又找了一台正常机器做对比。
正常机器上：
Get-NetAdapter | Select Name,InterfaceDescription,Status
结果里有：
vEthernet (WSL) Hyper-V Virtual Ethernet Adapter Up
并且：
Get-HnsNetwork | Format-List Name,Type,Subnets
返回的是：
Name : WSL
Type : ICS
而故障机器上对应结果是：
Name InterfaceDescription Status
---- -------------------- ------
vEthernet (Default Switch) Hyper-V Virtual Ethernet Adapter Up
以及：
Name : Default Switch
Type : ICS
也就是说：
- 正常机有
vEthernet (WSL) - 故障机只有
vEthernet (Default Switch) - 正常机有 WSL 网络对象
- 故障机只有 Default Switch
这个差异一度让人非常怀疑是 HNS/ICS 网络坏了。
5. 检查 CPU 虚拟化字段
还看过这一组经典字段：
Get-CimInstance Win32_Processor |
Select Name, VirtualizationFirmwareEnabled, VMMonitorModeExtensions, SecondLevelAddressTranslationExtensions
故障机这三项是 False。
但后面对比发现，正常机器上这三项也同样可能全部是 False，而 WSL 却能正常运行。
所以这个经验很重要：在 KVM/ZStack 这类环境里，不能拿这三个字段直接判断 WSL2 是否可用。它们会把人带偏。
四、真正的根因
排查到后面，宿主机迁移、服务状态、HNS 网络、虚拟交换机这些方向都看过了，但都没有形成真正闭环。
最终确认下来，问题并不是：
- 宿主机虚拟化能力彻底消失
- Ubuntu 发行版损坏
- ext4.vhdx 丢失
- Windows 功能没开
而是：WSL 新版本在当前 ZStack/KVM 虚机环境下存在兼容性问题。
故障机器当前版本是：
WSL 版本: 2.7.8.0
回退并重装旧版本 wsl.2.7.3.0.x64.msi 后，WSL 恢复正常。
所以这次问题的最终结论可以很明确：这不是宿主机问题，也不是发行版问题，而是 WSL 版本升级后，在当前虚拟化环境中触发了兼容性故障。
五、最终处理方式
处理方法很简单，就是回退 WSL 版本。
最终可行方案：
- 直接下载旧版本
wsl.2.7.3.0.x64.msi覆盖安装（不需要先卸载当前版本） - 安装完成后重启终端
- 重新验证 wsl 是否能正常进入发行版
回退后 WSL 恢复正常。
六、这次排障的几个经验
1. wsl –status 正常，不代表 WSL2 能启动
这两个命令：
wsl --status
wsl --version
只能说明组件安装存在，不能说明 WSL2 的轻量虚机一定能正常拉起。
2. CreateVm/0x800705b4 说明要盯”启动链路”
这个错误更像是：
- VM 创建流程开始了
- 但某个初始化阶段卡住
- 最终超时返回
它不等于”发行版坏了”，也不等于”wsl.exe 坏了”。
3. 不要过度依赖 Win32_Processor 的 3 个虚拟化字段
在 KVM/ZStack 环境里，这几个值即使是 False，WSL 也依然可能正常工作。
4. 对比一台正常机器非常重要
尤其建议对比这些命令：
Get-Service vmcompute,hns,hvhost,LxssManager
Get-Process wsl,wslservice,vmcompute,vmwp,vmmem -ErrorAction SilentlyContinue
Get-NetAdapter | Select Name,InterfaceDescription,Status
Get-HnsNetwork | Format-List Name,Type,Subnets
wsl -l -v
很多时候，单看故障机很难下结论，但和正常机一对比，异常点会明显很多。
5. 在虚拟机环境里，WSL 版本升级本身就应该纳入排查范围
这次最容易忽略的一点就是：不是环境变了，而是 WSL 自己变了。
如果前一天正常、第二天异常，除了怀疑宿主机、网络、补丁，也要把 WSL 版本更新 放进排查清单。
七、结论
这次 WSL2 启动失败的现象，表面上像是 Hyper-V、宿主机虚拟化或者 HNS 网络故障，实际根因却是 WSL 版本升级后的兼容性问题。
最终通过回退版本到 wsl.2.7.3.0.x64.msi 问题解决。
这个案例最大的教训是：在虚拟化环境里，WSL 出问题时，不要只盯宿主机和发行版，也要优先确认最近 WSL 本身有没有升级。