一次完整的 WSL2 安装排障：从 BIOS、TPM 判断到 Windows 11 修复安装

Date 2026-07-07 · Category blog · Status finished · Confidence likely
系统排障, 工程实践

最近为了在本地准备 Linux 开发环境，我打算在 Windows 11 上安装 WSL2。原本以为这只是一个常规操作，结果实际折腾下来，发现问题并不是单点故障，而是一条连续链路：一开始怀疑是 TPM 2.0，后来发现是 BIOS 虚拟化、Windows 组件状态，以及系统组件仓库损坏叠加导致的。

这篇文章记录一下我这次完整的排障过程，也给后面遇到类似问题的人一个可复用的思路。

一、问题现象：WSL2 一直安装不上

最开始的症状很直接：

  • WSL2 无法正常启动。
  • Windows 提示相关组件不完整。
  • 过程中一度怀疑是 TPM 2.0 导致的问题。
  • 即使尝试修复，安装过程还是会卡住。

为了确认问题到底出在哪，我先做了几组基础检查。

先看 WSL 本体是否已经存在：

wsl --version
wsl --status

如果 wsl --version 能正常输出版本，而 wsl --status 提示虚拟化未启用，那么说明问题往往不在 wsl.exe 本身，而是在它依赖的底层环境上。

二、先排除误区：这次不是 TPM 2.0 的锅

当时之所以会怀疑 TPM 2.0，是因为 Windows 11 对安全组件要求比较高，而且很多报错信息容易把人往 TPM 方向带偏。

但实际检查后，TPM 状态是正常的。至少在我这次排障里，它并不是当前阻塞点。

这一步很重要，因为它帮我排除了一个常见误判：不是所有 WSL2 安装失败都和 TPM 有关。

三、真正的第一层问题：BIOS 与虚拟化链路

既然不是 TPM，那就继续往下看虚拟化环境。

WSL2 依赖的不只是 Windows 组件本身，还依赖 BIOS 或 UEFI 层已经开启虚拟化支持。这个检查可以通过下面几条命令辅助确认：

systeminfo

或者更直接一点：

Get-CimInstance Win32_Processor | Select-Object Name, SecondLevelAddressTranslationExtensions, VirtualizationFirmwareEnabled, VMMonitorModeExtensions

如果这里看到 VirtualizationFirmwareEnabled 不是启用状态，那么就要回到 BIOS 继续排查。

我后来更新并检查了 BIOS，确认版本已经升级到了 B1.9G。这一步的意义在于：先把主板固件和虚拟化基础打通。

如果 BIOS 层没有启用 Intel Virtualization Technology、VT-x、VMX、VT-d 之类的选项，那么 Windows 里的 WSL2 再怎么开也开不起来。

四、BIOS 解决之后，问题还没完

按理说，BIOS 处理完之后，后面应该就是正常启用组件了。于是我继续在管理员 PowerShell 里执行：

dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart
dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart
bcdedit /set hypervisorlaunchtype auto
shutdown /r /t 0

但事情没有这么顺利。

在启用 Microsoft-Windows-Subsystem-Linux 时，系统直接报错：

错误: 0x800f0900

这时候就说明问题已经不只是“虚拟化没开”这么简单了，而是 Windows 自己的组件链路也出了问题。

五、真正的核心问题：Windows 组件仓库损坏

当 DISM 报 0x800f0900 时，我继续做了系统组件修复检查：

sfc /scannow
DISM /Online /Cleanup-Image /ScanHealth
DISM /Online /Cleanup-Image /RestoreHealth

这一步非常关键。

因为很多时候，大家会以为 “WSL2 装不上” 就继续死磕 wsl --install，但如果底层 WinSxS/CBS 组件仓库已经损坏，那你在功能开关上反复重试，其实是没有意义的。

这次排查里，日志最终指向的是典型的组件存储损坏问题，比如：

  • Manifest hash mismatch
  • CorruptCatalog
  • FileHashMismatch
  • unexpected internal XML parser error

换句话说，这不是 WSL 本身坏了，而是 Windows 系统组件仓库不健康，导致 WSL 相关功能无法被正常启用。

六、到这里，最稳的做法不是继续硬修，而是直接修复安装 Windows 11

既然系统组件已经损坏，那继续在命令行里硬扛，收益很低。更稳的路线，是直接做一次 Windows 11 修复安装。

注意，这里说的不是重装系统，而是：

  • 下载官方 Windows 11 ISO
  • 在当前系统里双击挂载
  • 运行 setup.exe
  • 选择 保留个人文件和应用
  • 用“就地修复安装”的方式重建系统文件和组件链路

这里有几个经验点值得单独记一下：

  1. 不要从 U 盘启动去做全新安装，那样很容易走成真正重装。
  2. 一定要在当前 Windows 里直接运行 setup.exe，这是“修复安装”和“重装”的分界线。
  3. 如果安装程序卡在“检查更新”，可以优先选择“不是现在”或“暂不”，先完成修复安装，等进系统后再更新。

七、修复安装后，再回头启用 WSL2

修复安装完成后，系统底层链路基本恢复，这时候再回头做 WSL2 安装，逻辑就顺很多了。

先启用组件：

dism /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart
dism /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart
bcdedit /set hypervisorlaunchtype auto
shutdown /r /t 0

重启之后检查状态：

wsl --status

如果状态正常，再安装发行版：

wsl --install -d Ubuntu

如果在线安装超时，比如出现下面这种问题：

无法从 'https://raw.githubusercontent.com/microsoft/WSL/master/distributions/DistributionInfo.json' 提取通讯组列表
错误代码: Wsl/InstallDistro/WININET_E_TIMEOUT

那就改成：

wsl --install --web-download -d Ubuntu

如果还不稳定，也可以直接走 Microsoft Store 安装 Ubuntu，这样通常更省事。

八、这次排障最大的经验

这次最值得总结的，不是某一条命令，而是排查顺序。

很多人一遇到 WSL2 安装失败，就会直接反复执行：

wsl --install

但如果底层问题没解决，这样做只会一直绕圈。

更合理的顺序应该是：

  1. 先确认 TPM 是否真的是问题。
  2. 再确认 BIOS 虚拟化是否开启。
  3. 再检查 Windows 可选功能状态。
  4. 如果 DISM 报错，就进一步判断是不是组件仓库损坏。
  5. 如果系统组件已经坏了，直接做 Windows 修复安装，不要继续死磕单个组件。

九、本文里用到的关键命令汇总

检查 WSL 状态：

wsl --version
wsl --status
wsl -l -v

检查虚拟化与系统状态：

systeminfo
Get-CimInstance Win32_Processor | Select-Object Name, SecondLevelAddressTranslationExtensions, VirtualizationFirmwareEnabled, VMMonitorModeExtensions

检查 Windows 功能：

dism /online /get-featureinfo /featurename:Microsoft-Windows-Subsystem-Linux
dism /online /get-featureinfo /featurename:VirtualMachinePlatform

启用 WSL 相关功能：

dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart
dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart
bcdedit /set hypervisorlaunchtype auto
shutdown /r /t 0

修复系统组件：

sfc /scannow
DISM /Online /Cleanup-Image /ScanHealth
DISM /Online /Cleanup-Image /RestoreHealth

安装 Ubuntu：

wsl --install -d Ubuntu
wsl --install --web-download -d Ubuntu

十、结语

这次折腾下来，我对 WSL2 安装这件事有了一个更直观的认识：它看起来像一个简单的软件安装任务，但实际上依赖的是一整条系统链路，包括 BIOS 虚拟化、Windows 可选功能、组件仓库完整性，以及网络下载环境。

如果你的电脑也出现了类似情况，不要急着把锅甩给 TPM，也不要只盯着某一条报错。很多时候，真正的问题在更底层。

我这次最终走通的路线可以概括成一句话：

升级并确认 BIOS 虚拟化正常 -> 修复 Windows 组件链路 -> 再安装 WSL2 和 Ubuntu。

See also