[Notice]WSL VM 冷启动异常缓慢/WSL VM Cold Boot Extremely Slow

[owu]

Note: This report is posted in two comments for bilingual accessibility.

• Comment 1 (this one): Simplified Chinese（简体中文）
• Comment 2 (the reply below): English
  Please read the English version in the reply below if needed.

适用范围：wsldashboard 项目说明
更新日期：2026-08-21

一、危害（对 wsldashboard 的影响）

以下问题都集中在 Windows 刚开机后（WSL VM 尚未预热、处于冷启动阶段）触发；VM 一旦热起来，即恢复正常。

1. 打开软件看不到发行版列表

最直观的影响：Windows 刚开机时，打开软件，界面上的「发行版列表」看不到任何已安装的发行版。

原因：wsldashboard 的发行版列表通过 wsl -l -v 枚举（info.rs 中 list_distros）。在 VM 冷启动缓慢期间，wsl -l -v 同样会进入「排队等待 VM 就绪」的状态（详见下文『概述』中的对照表），导致：

• 界面长时间空白，看不到任何已安装的发行版；
• 依赖该列表的后续操作（启动/停止、端口代理同步、USB 挂载、状态刷新）随之无法正常进行；
• 用户可能误以为「发行版丢失」或「软件异常」，实际只是查询不到状态，并非数据丢失。

等 VM 冷启动完成后，重新刷新或重启软件通常即可恢复。

2. /scheduler 启动任务整体变慢（但最终会完成）

/scheduler 负责开机时的后台任务：发行版开机自动启动、USB 自动连接、端口转发激活。在 VM 冷启动缓慢期间，这些任务的每一步都需要等待 VM 就绪，导致：

• 整体流程耗时从「秒级」拉长到「分钟级」（与本机实测约 4.5 分钟一致）；
• 表现上像「卡住不动」，但并非失败——只要 VM 最终就绪，这些任务一定会完成（发行版会被拉起、USB 会挂载、端口转发会落地）。

因此除非长时间（远超 VM 冷启动上限）仍未完成，否则无需干预，本质是在等 WSL 环境预热。

二、如何自查是否中招

核心思路：制造一次真正的冷启动，然后给「第一次拉起发行版」计时。

方法 A：重启 Windows 后立刻测试（推荐）

1. 重启 Windows 11。
2. 重启完成后，立即打开 PowerShell（管理员或普通均可）。
3. 执行：

Measure-Command { wsl -d Ubuntu -u root echo ok }

把 Ubuntu 换成你实际的发行版名（可用 wsl -l -q 查看）。

方法 B：wsl --shutdown 后冷启动测试

无需重启系统，但效果等同冷启动：

wsl --shutdown
Measure-Command { wsl -d Ubuntu -u root echo ok }

结果判定

耗时	结论
< 30 秒（通常 5~10 秒）	正常，未中招
明显 > 60 秒，甚至数分钟	中招，命中冷启动缓慢问题

补充判据：执行上面的测试时，另一个终端跑 wsl --version 若依然秒回，而 wsl -d ... 却迟迟不返回，即可进一步确认慢点在 VM 冷启动，而非 WSL 服务整体卡死。

三、概述

部分 Windows 版本 与部分 WSL 版本 的组合下，WSL 2 轻量级工具 VM（Utility VM）的冷启动会异常缓慢——正常情况下拉起一个 Linux 发行版只需 5~10 秒，但在受影响环境中可能耗时数分钟。

需要注意的是：这里的「慢」发生在 VM 本体的冷启动，而不是某个具体的 Linux 发行版启动快慢，也不是 WSL 服务（LxssManager）本身卡死。可据此与普通故障区分：

命令	是否需要 VM	受影响环境下表现
wsl --version / wsl --status	否	秒回，正常
wsl -l -v / wsl -l -q --running 在 VM 启动期间	是	阻塞数分钟
wsl -d <distro> ...（第一次拉起）	是	阻塞数分钟

四、受影响环境（已知报告 / 已复现）

Windows 版本	WSL 版本	内核版本	来源
Windows 11 25H2 10.0.26200.9168	2.7.12	6.18.33.2	本机已复现
Windows 11 25H2 10.0.26200.9168	2.6.3	—	本机已复现（说明 WSL 版本不是唯一变量）
Windows 11 25H2 10.0.26200.8973	2.7.11	6.18.33.2	microsoft/WSL#41253
Windows 11 25H2 10.0.26200.7623	2.7.0	6.6.114.1	microsoft/WSL#14072
Windows 11 25H2 10.0.26200.8457	2.7.3	—	microsoft/WSL#40616

共同点：Windows 11 25H2（build 26200） 是最主要的触发条件；多个 WSL 版本（2.6.3、2.7.x）上均有报告或复现。

五、现象描述

1. 只在冷启动时发生：刚重启 Windows、或执行 wsl --shutdown 之后，第一次拉起任意发行版（VM 冷启动）才会慢。
2. 热启动正常：VM 已经运行时，wsl 系列命令基本秒回。
3. 表现为「卡住」而非「报错」：命令一直等不到返回，没有明显错误输出。
4. 连带影响：VM 冷启动期间，任何需要访问 VM 状态的 wsl 命令（如另一个终端里的 wsl -l -v、wsl -l -q --running）都会跟着阻塞，因为它们都在排队等待 VM 就绪。
5. 典型耗时从正常的 5~10 秒 恶化到 数分钟，偶发或稳定复现。

六、相关链接

• microsoft/WSL#41253 — WSL2 hangs after utility VM startup and returns HCS_E_CONNECTION_TIMEOUT on Windows 11 build 26200.8973
• microsoft/WSL#14072 — WSL VM slow to start up (occasionally)
• microsoft/WSL#40616 — WSL 2.7.3 fails to start: missing system.vhd/modules.vhd
• microsoft/WSL#40488 —（#40616 的关联/重复问题）

七、可能放大问题的因素（排查建议）

已确认 WSL 版本不是唯一变量，因此同时关注以下机器级配置（.wslconfig 位于 %USERPROFILE%\.wslconfig）：

• sparseVhd=false：关闭稀疏 VHD，虚拟磁盘固定分配、挂载更重，可能拖慢冷启动。
• memory=8GB + swap=4GB 等较大内存预留：冷启动一次性预留大内存 + swap，宿主机内存吃紧时会触发分页，明显拉长启动时间。
• dnsTunneling=true + autoProxy=true：网络栈初始化环节可能引入额外延迟。
• 杀毒软件实时扫描 VHDX / VM 进程（部分环境出现过干扰）。

排查/绕开建议

1. 先确认版本：wsl --version（若降级后仍显示旧版本号，需 wsl --update 或重启确认生效）。
2. 临时备份并清空 %USERPROFILE%\.wslconfig，wsl --shutdown 后重测冷启动，观察是否恢复。
3. 若恢复，再逐条加回配置二分，锁定具体那一行（优先怀疑 sparseVhd）。
4. 若仍慢，考虑 Hyper-V / 虚拟机平台冷启动、杀软排除 WSL 的 vhdx 与安装目录（C:\Program Files\WSL\）。

八、结论

冷启动缓慢是环境级问题，主要与 Windows 25H2（build 26200）相关，跨多个 WSL 版本复现；当前无法由应用层代码加速。对 wsldashboard 而言，能做的仅在调度链路中采用有界探测 + 并发轮询 + 超时降级，避免单次阻塞黑洞并保证业务最终正确落地，而不是去「加速」VM 本身。

该问题的根治需要由微软 WSL 开发团队修复底层 VM 冷启动逻辑；应用侧只能缓解与降级，无法从源头解决。建议在上文「相关链接」中的 GitHub issue 跟进官方进展。

[owu]

Scope: wsldashboard project maintenance note
Last updated: 2026-08-21

1. Impact (on wsldashboard)

All of the issues below occur right after Windows boots (while the WSL VM is not yet warm, i.e. still in the cold-boot stage); once the VM is warm, things return to normal.

1. App shows no distro list on open

Most visible impact: right after Windows boots, opening the app shows no installed distros in the "distro list".

Why: wsldashboard enumerates the distro list via wsl -l -v (the list_distros function in info.rs). During a slow VM cold boot, wsl -l -v also ends up "queued waiting for the VM to be ready" (see the table in "Overview" below), which causes:

• The UI stays blank for a long time and shows no installed distros;
• Downstream actions that depend on that list (start/stop, port proxy sync, USB attach, status refresh) cannot proceed normally;
• Users may wrongly think "distros are lost" or "the app is broken", when in fact the status simply cannot be queried — no data is lost.

Once the VM cold boot finishes, refreshing or restarting the app usually restores it.

2. /scheduler startup tasks slow down (but will eventually complete)

/scheduler handles the background tasks at boot: distro auto-start, USB auto-attach, and port forwarding activation. During a slow VM cold boot, each of these steps has to wait for the VM to be ready:

• The overall flow stretches from "seconds" to "minutes" (consistent with the ~4.5 min measured on this machine);
• It looks "stuck", but it is not failing — as long as the VM eventually becomes ready, these tasks will definitely complete (distros get started, USB gets attached, port forwarding gets applied).

So unless it is still not done after a long time (far beyond the VM cold-boot ceiling), no intervention is needed — it is essentially just waiting for the WSL environment to warm up.

2. How to check if you are affected

Core idea: create a real cold boot, then time the "first distro launch".

Method A: test right after a Windows restart (recommended)

1. Restart Windows 11.
2. Once boot completes, immediately open PowerShell (admin or non-admin).
3. Run:

Measure-Command { wsl -d Ubuntu -u root echo ok }

Replace Ubuntu with your actual distro name (see wsl -l -q).

Method B: cold-boot test via wsl --shutdown

No system restart needed, but equivalent to a cold boot:

wsl --shutdown
Measure-Command { wsl -d Ubuntu -u root echo ok }

Result interpretation

Duration	Conclusion
< 30 s (usually 5–10 s)	Normal, not affected
Clearly > 60 s, even minutes	Affected — hits the slow cold-boot issue

Additional check: while running the test above, if wsl --version in another terminal still returns instantly but wsl -d ... takes a long time, that further confirms the slowness is in the VM cold boot, not the whole WSL service hanging.

3. Overview

In some combinations of Windows versions and WSL versions, the WSL 2 lightweight utility VM's cold boot is abnormally slow — normally launching a Linux distro takes only 5–10 s, but in affected environments it can take minutes.

Note: the "slowness" is in the VM's own cold boot — not how fast a specific Linux distro boots, and not the WSL service (LxssManager) itself hanging. You can use this distinction to tell it apart from ordinary failures:

Command	Needs VM?	Behavior in affected environment
wsl --version / wsl --status	No	Instant, normal
wsl -l -v / wsl -l -q --running while the VM is starting	Yes	Blocks for minutes
wsl -d <distro> ... (first launch)	Yes	Blocks for minutes

4. Affected environments (reported / reproduced)

Windows version	WSL version	Kernel version	Source
Windows 11 25H2 10.0.26200.9168	2.7.12	6.18.33.2	Reproduced locally
Windows 11 25H2 10.0.26200.9168	2.6.3	—	Reproduced locally (shows WSL version is not the only variable)
Windows 11 25H2 10.0.26200.8973	2.7.11	6.18.33.2	microsoft/WSL#41253
Windows 11 25H2 10.0.26200.7623	2.7.0	6.6.114.1	microsoft/WSL#14072
Windows 11 25H2 10.0.26200.8457	2.7.3	—	microsoft/WSL#40616

Common factor: Windows 11 25H2 (build 26200) is the main trigger; it has been reported or reproduced across multiple WSL versions (2.6.3, 2.7.x).

5. Symptoms

1. Happens only on cold boot: right after restarting Windows, or after wsl --shutdown, the first launch of any distro (VM cold boot) is slow.
2. Warm boot is normal: once the VM is already running, wsl commands return almost instantly.
3. It "hangs" rather than "errors": the command just never returns, with no visible error output.
4. Knock-on effect: during the VM cold boot, any wsl command that needs VM state (e.g. wsl -l -v or wsl -l -q --running in another terminal) also blocks, because they all queue waiting for the VM to be ready.
5. Typical duration degrades from the normal 5–10 s to minutes, intermittent or consistently reproducible.

6. Related links

• microsoft/WSL#41253 — WSL2 hangs after utility VM startup and returns HCS_E_CONNECTION_TIMEOUT on Windows 11 build 26200.8973
• microsoft/WSL#14072 — WSL VM slow to start up (occasionally)
• microsoft/WSL#40616 — WSL 2.7.3 fails to start: missing system.vhd/modules.vhd
• microsoft/WSL#40488 — (related/duplicate of #40616)

7. Factors that may magnify the issue (troubleshooting)

WSL version is confirmed to not be the only variable, so also pay attention to the following machine-level settings (.wslconfig lives at %USERPROFILE%\.wslconfig):

• sparseVhd=false: disables sparse VHD; the virtual disk is fixed-allocated and heavier to mount, which can slow cold boot.
• memory=8GB + swap=4GB and other large memory reservations: reserving a big chunk of memory + swap at cold boot can trigger paging when the host is low on RAM, noticeably lengthening startup.
• dnsTunneling=true + autoProxy=true: network stack initialization may add extra latency.
• Antivirus real-time scanning of VHDX / VM processes (interference seen in some environments).

Troubleshooting / workarounds

1. Confirm the version first: wsl --version (if a downgrade still shows the old version, run wsl --update or restart to confirm it took effect).
2. Temporarily back up and empty %USERPROFILE%\.wslconfig, then wsl --shutdown and re-test cold boot to see if it recovers.
3. If it recovers, add the config back one line at a time to bisect and identify the specific line (suspect sparseVhd first).
4. If it is still slow, consider Hyper-V / Virtual Machine Platform cold boot, or antivirus exclusions for WSL's vhdx and install directory (C:\Program Files\WSL\).

8. Conclusion

The slow cold boot is an environment-level issue, mainly related to Windows 25H2 (build 26200), reproduced across multiple WSL versions; it currently cannot be sped up by application-level code. For wsldashboard, the only thing we can do is adopt bounded probing + concurrent polling + timeout degradation in the scheduling path, avoiding a single blocking black hole and ensuring that business logic eventually lands correctly — not "accelerating" the VM itself.

The root cause must be fixed by the Microsoft WSL development team at the underlying VM cold-boot layer; the application side can only mitigate and degrade. It is recommended to follow the official progress on the GitHub issues listed under "Related links" above.