Baike.dev
Log in
Back to tool/Back to issues
#40795·WSL

New WSL sessions hang under memory pressure with vmbus_alloc_ring allocation failure

Author: kuza55Created Jun 12, 2026Updated Sep 17, 2026
Labelskernelemailed-logs

AI disclosure

This report was drafted and filed with assistance from OpenAI Codex, based on local command output and logs from the affected machine.

Summary

WSL semi-routinely gets into a state where existing WSL shells continue to work, but new WSL sessions and Windows interop hang. This appears to correlate with memory pressure and a kernel vmbus_alloc_ring allocation failure.

This looks similar to #11612. It has similar outer symptoms to #12991, but Docker Desktop is already newer than the Docker Resource Saver fix discussed there and in docker/for-win#14656.

Environment

  • WSL 2
  • Distro: Ubuntu 24.04.3 LTS
  • Kernel: 6.18.33.1-microsoft-standard-WSL2
  • .wslconfig: memory=52GB
  • Docker Desktop: 4.44.3
  • Docker Engine / CLI: 28.3.2
  • Docker Compose: v2.39.1-desktop.1
  • Docker Desktop WSL bootstrap: 098d711f2ff00f0a1c4d69da1f9d6d2d
  • Windows / WSL app version: not collected while wedged because wsl.exe --status and wsl.exe -l -v hang

Behavior

After some time under normal dev workload, apparently under memory pressure:

  • existing WSL shells still run commands
  • opening new WSL terminals hangs
  • launching wsl.exe from WSL hangs
  • launching Windows interop commands such as cmd.exe /c echo cmd-ok from WSL hangs
  • recovery requires wsl --shutdown or restarting WSL services / rebooting

Relevant local checks

$ timeout 8 bash -lic 'printf shell-ok'
shell-ok

$ timeout 12 /mnt/c/Windows/System32/wsl.exe -d Ubuntu --exec /bin/bash -lc 'printf wsl-exec-ok'
<3>WSL (...) ERROR: UtilAcceptVsock:273: accept4 failed 110

$ timeout 10 /mnt/c/Windows/System32/wsl.exe --status
# timed out, no output

$ timeout 10 /mnt/c/Windows/System32/wsl.exe -l -v
# timed out, no output

$ timeout 8 /mnt/c/Windows/System32/cmd.exe /c echo cmd-ok
# timed out, no output

Journal excerpts

Repeated session leader failures:

Jun 12 10:04:35 ... WSL (849628 - SessionLeader) ERROR: UtilAcceptVsock:273: accept4 failed 110
Jun 12 10:04:35 ... WSL (849628 - SessionLeader) ERROR: operator():1263: UtilAcceptVsock() failed for session leader 110
Jun 12 10:04:44 ... WSL (849732 - SessionLeader) ERROR: UtilAcceptVsock:273: accept4 failed 110
Jun 12 10:04:44 ... WSL (849732 - SessionLeader) ERROR: operator():1263: UtilAcceptVsock() failed for session leader 110
Jun 12 15:47:51 ... WSL (1042443 - SessionLeader) ERROR: UtilAcceptVsock:273: accept4 failed 110
Jun 12 15:47:51 ... WSL (1042443 - SessionLeader) ERROR: operator():1263: UtilAcceptVsock() failed for session leader 110
Jun 12 17:10:40 ... WSL (1059662 - SessionLeader) ERROR: UtilAcceptVsock:273: accept4 failed 110
Jun 12 17:10:40 ... WSL (1059662 - SessionLeader) ERROR: operator():1263: UtilAcceptVsock() failed for session leader 110

Earlier memory / Hyper-V socket allocation failure:

Jun 11 17:40:07 ... kernel: kworker/0:0: page allocation failure: order:7, mode:0xdc0(GFP_KERNEL|__GFP_ZERO), nodemask=(null),cpuset=/,mems_allowed=0
Jun 11 17:40:07 ... kernel: Workqueue: hv_pri_chan vmbus_add_channel_work
Jun 11 17:40:07 ... kernel:  vmbus_alloc_ring+0x78/0xd0
Jun 11 17:40:07 ... kernel:  vmbus_open+0x29/0x80
Jun 11 17:40:07 ... kernel:  hvs_probe+0x1f4/0x4c0
Jun 11 17:40:07 ... kernel:  vmbus_probe+0x42/0xa0
Jun 11 17:40:07 ... kernel:  vmbus_device_register+0x87/0x130
Jun 11 17:40:07 ... kernel:  vmbus_add_channel_work+0x146/0x1d0

Mem-Info from the same allocation failure showed heavy pressure near the WSL memory cap:

active_anon:114025 inactive_anon:11507801 isolated_anon:32
active_file:1031583 inactive_file:146747 isolated_file:0
free:60986 free_pcp:1372 free_cma:0
Node 0 active_anon:456100kB inactive_anon:46031204kB active_file:4126332kB inactive_file:586988kB
Node 0 Normal free:46896kB min:41688kB low:91140kB high:140592kB
Node 0 Normal: ... 0*512kB 0*1024kB 0*2048kB 0*4096kB = 44724kB
Free swap  = 12716576kB
Total swap = 13631488kB

The same allocation failure repeated at least two more times:

Jun 11 17:41:42 ... kernel: kworker/0:3: page allocation failure: order:7, mode:0xdc0(GFP_KERNEL|__GFP_ZERO)
Jun 11 17:41:42 ... kernel: Workqueue: hv_pri_chan vmbus_add_channel_work
Jun 11 17:41:42 ... kernel:  vmbus_alloc_ring+0x78/0xd0
Jun 11 17:41:58 ... kernel: kworker/0:2: page allocation failure: order:7, mode:0xdc0(GFP_KERNEL|__GFP_ZERO)
Jun 11 17:41:58 ... kernel: Workqueue: hv_pri_chan vmbus_add_channel_work
Jun 11 17:41:58 ... kernel:  vmbus_alloc_ring+0x78/0xd0

Notes

Docker Desktop is installed and WSL integration is active, but the installed Docker Desktop version is 4.44.3, newer than the 4.42.1 fix referenced from #12991 / docker/for-win#14656. This may still be Docker-triggered, but the local kernel evidence looks closer to #11612: vmbus_alloc_ring cannot allocate under memory pressure, then WSL session creation / interop starts timing out.

Source: microsoft/WSL

View original on GitHubView discussion on GitHub