
> 一次 Docker buildx 跨平台编译中，WSL2 突然崩溃退出，重启后再次崩溃。排查发现这是一个 WSL2 内核级 BUG——且在当前最新版本（2.9.4.0 / 内核 6.18.35.2）中仍未修复。本文记录完整的诊断过程。该 bug 已向微软上报：[microsoft/WSL#41191](https://github.com/microsoft/WSL/issues/41191)。

# 1. 崩溃背景

在 WSL2（Debian bullseye）中使用 Docker buildx 进行 ARM64 跨平台编译 FreeSWITCH 时，WSL2 在编译过程中**突然整体崩溃退出**。重启 WSL 后，刚执行 `ls` 等简单命令就再次崩溃。

最终确认，这是一个 **WSL2 内核 BUG**——且在当前最新版本（WSL 2.9.4.0 / 内核 6.18.35.2）中仍然存在，无法通过 `wsl --update` 解决，最终通过回退 WSL 版本才解决。

# 2. 崩溃时间线

```
08:50:19  DNS 解析开始失败（崩溃前 11 分钟的预警）
          WSL (135) ERROR: CheckConnection: getaddrinfo() failed: -5
          （持续重复失败...）

08:51:31  9P/virtiofs 通道断裂
          Exception: Operation canceled @p9io.cpp:258 (AcceptAsync)
          systemd-journald: Received SIGTERM from PID 1 (systemd-shutdow)
          EXT4-fs (sdd): unmounting filesystem
          → WSL 非正常关闭

08:53:10  WSL 重启后，EXT4 做 journal 恢复
          EXT4-fs (sdd): recovery complete
          systemd-journald: File corrupted or uncleanly shut down, renaming and replacing
          （出现两次，说明当天至少经历了两次非正常关闭）

09:04:46  Docker broken pipe 错误开始密集出现
09:07:36  内核 BUG 触发！
          kernel BUG at fs/namei.c:844!
          → WSL 再次崩溃
```

# 3. 关键日志：内核 BUG

以下是在某次重启后挂起 `tail -f /var/log/syslog`、守候到下一次崩溃时，实时输出中捕捉到的内核 BUG：

```
Jul 28 09:07:36 Czy kernel: [ 1043.996863] ------------[ cut here ]------------
Jul 28 09:07:36 Czy kernel: [ 1043.998965] kernel BUG at fs/namei.c:844!
Jul 28 09:07:36 Czy kernel: [ 1043.999841] Oops: invalid opcode: 0000 [#1] SMP NOPTI
Jul 28 09:07:36 Czy kernel: [ 1044.000429] CPU: 7 UID: 0 PID: 13059 Comm: ls Not tainted 6.18.35.2-microsoft-standard-WSL2 #1 PREEMPT(none)
Jul 28 09:07:36 Czy kernel: [ 1044.001747] RIP: 0010:try_to_unlazy+0xbc/0xe0

Jul 28 09:07:36 Czy kernel: [ 1044.014043] Call Trace:
Jul 28 09:07:36 Czy kernel: [ 1044.014234]  <TASK>
Jul 28 09:07:36 Czy kernel: [ 1044.014456]  complete_walk+0x43/0xb0
Jul 28 09:07:36 Czy kernel: [ 1044.015086]  path_lookupat+0x9c/0x180
Jul 28 09:07:36 Czy kernel: [ 1044.015604]  ? proc_pid_readlink+0x12d/0x1b0
Jul 28 09:07:36 Czy kernel: [ 1044.016224]  filename_lookup+0xe2/0x1e0
Jul 28 09:07:36 Czy kernel: [ 1044.017192]  ? do_readlinkat.part.0+0xa6/0x160
Jul 28 09:07:36 Czy kernel: [ 1044.017973]  vfs_statx+0x69/0x100
Jul 28 09:07:36 Czy kernel: [ 1044.018429]  do_statx+0x48/0x80
Jul 28 09:07:36 Czy kernel: [ 1044.018912]  __x64_sys_statx+0xa6/0xf0
Jul 28 09:07:36 Czy kernel: [ 1044.021636]  x64_sys_call+0x12a1/0x20f0
Jul 28 09:07:36 Czy kernel: [ 1044.022080]  do_syscall_64+0x73/0x990
Jul 28 09:07:36 Czy kernel: [ 1044.026153]  entry_SYSCALL_64_after_hwframe+0x76/0x7e

Jul 28 09:07:36 Czy kernel: [ 1044.033855] ---[ end trace 0000000000000000 ]---
```

**关于这段日志的来历**：第一次崩溃时现场日志完全无从查找——重启后 `dmesg` 和 `/var/log/kern.log` 中**没有任何有效信息**，因为非正常关闭导致 journal 损坏，崩溃前的日志全部丢失。但由于这类崩溃频繁复现，于是在一次重启后主动挂起 `tail -f /var/log/syslog` 守着，才在后续某次崩溃发生时实时抓到了上面这段输出。这正是 WSL2 内核崩溃最棘手的地方：**日志重启后即焚毁，只能趁问题还在复现时提前 tail 挂着等它下次崩**。

# 4. 崩溃根因分析

这是一个 **Linux 内核 BUG() 宏触发**，不是普通错误，而是内核检测到内部状态不一致后主动 panic。

## 4.1 try_to_unlazy() 是什么？

Linux 内核在做路径查找（如 `ls`、`statx`）时，先用高性能的 **RCU-walk** 模式（无锁快速查找）。当 RCU 路径无法继续（比如 dentry 被修改），需要通过 `try_to_unlazy()` 切换到普通引用计数模式。

**BUG() 触发说明状态切换时遇到了非法状态**——内核的路径查找状态机内部数据已损坏。

关键证据：`RAX: 0000000000000004`——nameidata 的 state 字段值为 4，不是 `try_to_unlazy` 期望的合法状态值（应该是 `LOOKUP_RCU` = 1），**VFS dentry 缓存已经被污染**。

## 4.2 调用链

```
statx syscall → vfs_statx → filename_lookup → path_lookupat → complete_walk → try_to_unlazy → BUG()
```

进程 `ls`（PID 13059）执行 `statx` 系统调用查看文件属性，在路径查找过程中 hit 了损坏的 dentry，触发内核 BUG。

## 4.3 Docker broken pipe 不是原因，是症状

09:04–09:07 之间密集出现的 `exec attach failed: broken pipe` 错误是文件系统已经不稳定的**副作用**，不是根源。内核 BUG 才是真正的崩溃点。

# 5. 完整因果链

```
① 9P/virtiofs 通道断裂 (08:51:31)
   ↓
② WSL 非正常关闭 → EXT4 journal 恢复
   ↓
③ 9P/virtiofs 重连后，dentry 缓存中残留脏/过期的状态
   （journal 恢复了文件系统数据，但 dentry 缓存的内核内存状态未同步清理）
   ↓
④ ls 进程 statx → 路径查找 hit 损坏 dentry → try_to_unlazy() BUG()
   ↓
⑤ 内核 oops → 文件系统全面不稳定 → Docker broken pipe
   ↓
⑥ WSL 再次崩溃退出
```

核心问题：WSL2 内核在 9P/virtiofs 通道断裂后重连时，**没有正确清理 VFS dentry 缓存的状态**，导致路径查找状态机进入非法状态。这是 **WSL2 内核本身的 bug**，不是用户配置问题。

# 6. 9P 通道为什么会断裂？

## 6.1 预警信号

崩溃前 **11 分钟**就出现了 DNS 解析失败：

```
08:50:19 WSL (135) ERROR: CheckConnection: getaddrinfo() failed: -5
08:50:50 WSL (135) ERROR: CheckConnection: getaddrinfo() failed: -5
```

`getaddrinfo() failed: -5`（`EAI_FAMILY`）说明 WSL 的网络栈已经不稳定。因为 VMBus 同时承载网络通信和 9P 文件通信，网络栈出问题时文件通道也岌岌可危。

## 6.2 我的 .wslconfig 配置

```ini
[wsl2]
memory=16G
swap=8G
networkingMode=mirrored
dnsTunneling=true
firewall=true
autoProxy=true
nestedVirtualization=false
vmIdleTimeout=-1
processors=8

[experimental]
hostAddressLoopback=true
autoMemoryReclaim=Gradual
```

已经配置了 `networkingMode=mirrored` + `dnsTunneling=true`，但 DNS 还是失败了，说明 **VMBus 通信层本身不稳定**——dnsTunneling 的隧道也没能正常工作。

# 7. 诊断过程与教训

WSL2 崩溃的排查有一个特殊难点：**日志极易在重启后丢失**。

| 信息来源                                    | 排查结果                                       |
| --------------------------------------- | ------------------------------------------ |
| `tail -f /var/log/syslog`（提前挂起守候）      | ✅ 下一次崩溃时实时捕捉到内核 BUG 完整输出                 |
| `dmesg`（重启后）                            | ❌ 无任何有效信息                                  |
| `/var/log/kern.log`（重启后）                | ❌ 无任何有效信息                                  |
| `journalctl`（重启后）                       | ⚠️ 仅能看到 broken pipe 等表层症状                  |
| Windows 事件日志（PowerShell `Get-WinEvent`） | ❌ WSL2 运行在 Hyper-V 内，内核崩溃不反映到 Windows 事件日志 |

**关键教训**：WSL2 运行在 Hyper-V 虚拟机内，内核崩溃**不会写入 Windows 事件日志**；更麻烦的是，由于崩溃是非正常关闭，WSL 内部的 `dmesg` 和 `/var/log/kern.log` 在重启后往往也是空的（journal 损坏或未落盘）。

第一次崩溃时，现场日志完全无从查找。但因为这类崩溃**频繁复现**，于是在某次重启后主动挂起 `tail -f /var/log/syslog`，守着等待下一次崩溃——本文的日志证据就是这样在后续一次崩溃发生时实时捕捉到的。实践上，面对重启即焚毁的 WSL2 崩溃日志，最有效的办法不是"崩溃瞬间去翻"，而是**趁问题还在复现，提前 tail 挂着等它下次崩**。

# 8. 解决方案：回退 WSL 版本

由于当前最新 WSL 版本（2.9.4.0 / 内核 6.18.35.2）仍存在此 BUG，无法通过 `wsl --update` 解决，最终通过 **回退到旧版本 WSL 2.7.3.0** 解决：

下载 `wsl.2.7.3.0.x64.msi` 并重新安装，回退后 WSL 稳定运行，不再出现 9P 通道断裂和内核 BUG。

# 9. 关键知识点总结

## 9.1 WSL2 崩溃日志重启后即焚毁，靠"提前 tail 守着"才能抓到

WSL2 运行在 Hyper-V 虚拟机内，内核崩溃既不写入 Windows 事件日志，重启后的 `dmesg` / `/var/log/kern.log` 也往往为空（非正常关闭导致 journal 损坏）。第一次崩溃时现场无从查找，但这类崩溃常频繁复现——实践中有效的做法是：**在某次重启后主动 `tail -f /var/log/syslog` 挂起，等待下一次崩溃实时捕获**。本文的日志证据正是这样在后续崩溃中抓到的。

## 9.2 try_to_unlazy 内核 BUG 是 WSL2 已知脆弱点

WSL2 内核在 9P/virtiofs 通道断裂后重连时，没有正确清理 VFS dentry 缓存状态，导致路径查找状态机进入非法状态触发 BUG。任何文件操作（`ls`、`statx` 等）都可能触发。

## 9.3 9P/virtiofs 是 WSL2 最脆弱的环节

9P 协议负责 Windows 主机与 WSL VM 之间的文件通信。在高 I/O 负载下（特别是 Docker buildx 跨平台编译），9P 通道是最容易断裂的环节。断裂后可能导致 dentry 缓存污染，触发内核 BUG。

## 9.4 WSL 最新版也可能有内核 BUG

不要假设 `wsl --update` 到最新版就万事大吉。本案例中 BUG 存在于当前最新版（2.9.4.0），必要时回退到旧版本是有效的止损手段。

## 9.5 DNS 失败是 9P 通道断裂的预警

`WSL (135) ERROR: CheckConnection: getaddrinfo() failed: -5` 出现时，说明 VMBus 通信层已经不稳定，9P 文件通道也即将断裂。这是崩溃前最后的肉眼可见信号。

# 10. 环境信息

| 项目            | 版本                                |
| ------------- | --------------------------------- |
| Windows       | 10.0.26200.8894                   |
| WSL 版本        | 2.9.4.0（崩溃版本）→ 2.7.3.0（回退稳定版本）    |
| WSL2 内核       | 6.18.35.2-microsoft-standard-WSL2 |
| Linux 发行版     | Debian 11 (bullseye)              |
| Docker Engine | 29.6.2                            |
| Docker Buildx | BuildKit v0.31.2                  |

# 11. 相关 Issue

本问题已向 Microsoft 官方上报，欢迎关注与补充复现信息：

- **Issue 链接**：[microsoft/WSL#41191 — WSL2 kernel BUG at fs/namei.c:844 (try_to_unlazy) crashes after 9P/virtiofs channel disruption](https://github.com/microsoft/WSL/issues/41191)

# 12. 写在最后

这个案例从一个 WSL2 突然崩溃的现象开始，层层深入最终定位到一个 WSL2 内核级 BUG。第一次崩溃时现场日志完全找不到——既不进 Windows 事件日志，重启后的 dmesg/kern.log 也是空的。好在崩溃频繁复现，于是在重启后挂起 `tail -f /var/log/syslog` 守株待兔，才在下一轮崩溃时抓到了 `kernel BUG at fs/namei.c:844` 的真容。系统的稳定性问题往往不是单一原因，而是多条因果链交织而成：DNS 失败是预警，9P 通道断裂是触发，dentry 缓存污染是根因，内核 BUG 是结果。面对 WSL2 崩溃日志重启即焚毁的特性，记住：**趁问题还在复现，提前 tail 挂着等它下次崩，别等重启后再去找现场**。


一次 Docker buildx 跨平台编译中，WSL2 突然崩溃退出，重启后再次崩溃。排查发现这是一个 WSL2 内核级 BUG——且在当前最新版本（2.9.4.0 / 内核 6.18.35.2）中仍未修复。本文记录完整的诊断过程。该 bug 已向微软上报：microsoft/WSL#41191。

WSL2 最新内核 BUG 致崩溃：9P 通道断裂 + dentry 缓存污染的完整诊断实录

系统架构设计师

操作系统

后端

开发工具

WSL2内核级BUG导致崩溃：Docker buildx跨平台编译时触发内核BUG，9P/virtiofs通道断裂后dentry缓存污染引发路径查找异常。最新WSL2.9.4.0仍存在此问题，需回退至2.7.3.0版本解决。崩溃日志重启即焚，需提前tail-f/var/log/syslog实时捕获内核错误。

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

WSL2 最新内核 BUG 致崩溃：9P 通道断裂 + dentry 缓存污染的完整诊断实录-腾讯云开发者社区-腾讯云

WSL2 最新内核 BUG 致崩溃：9P 通道断裂 + dentry 缓存污染的完整诊断实录

WSL2 最新内核 BUG 致崩溃：9P 通道断裂 + dentry 缓存污染的完整诊断实录

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐