docker-desktop distro crash-loops with `Operation canceled @p9io.cpp:258 (AcceptAsync)`; Docker engine never starts (Win10 22H2, kernel 6.18.33.2-2)

Summary

Docker Desktop becomes permanently unresponsive because its WSL2 distro (docker-desktop) enters a crash cycle driven by a 9P/p9io failure. The utility VM stays up and the distro is restarted repeatedly, but each attempt dies before dockerd starts, so the Windows-side backend waits forever for the engine.

This appears to be the same failure mode as #41484 (closed as stale) and #41191 (open), observed on Windows 10 22H2.

Environment

.wslconfig (no custom kernel):

[wsl2]
# networkingMode=mirrored
defaultVhdSize=53687091200
[experimental]
sparseVhd=true

docker-desktop /etc/wsl.conf:

[automount]
root = /mnt/host
options = "metadata"
[interop]
enabled = true

Symptom

docker version / docker info hang indefinitely. Docker Desktop UI stays on "Starting the Docker Engine". Killing and restarting Docker Desktop does not help; only rebooting the machine (or a full wsl --shutdown) clears it.

On the Windows side, the backend logs this, indefinitely:

[main.enginedependencies] still waiting for init control API to respond after 6h7m20.3767988s
[main.socketforward][vpnkit-bridge] /run/guest-services/socketforwarder-receive-fds.sock: does not exist yet, waiting for it to be created
[main.ipc][W] C<-S ConnectionClosed GET /ping (1.0004352s): Get "http://ipc/ping": context deadline exceeded

wsl -d docker-desktop is responsive (uname, free return instantly, load ~0.04), and /run/guest-services/ is empty — dockerd and containerd never start.

Evidence: kernel crash cycle

dmesg inside docker-desktop over one boot window. Each crash occurs roughly 25 s after the data disk (sde) is mounted:

[   39.443015] EXT4-fs (sde): mounted filesystem 79d0ef33-9c4f-46ec-954e-b78362282797 r/w with ordered data mode.
[   66.182557] Exception:
[   66.182565] Operation canceled @p9io.cpp:258 (AcceptAsync)
[   69.435343] systemd-journald[47]: Received SIGTERM from PID 1 (systemd-shutdow).
[   69.777246] EXT4-fs (sde): unmounting filesystem 79d0ef33-9c4f-46ec-954e-b78362282797.
[  601.029473] mini_init (121): drop_caches: 1

[ 1015.322100] EXT4-fs (sde): mounted filesystem 79d0ef33-9c4f-46ec-954e-b78362282797 r/w with ordered data mode.
[ 1036.253162] Exception:
[ 1036.253169] Operation canceled @p9io.cpp:258 (AcceptAsync)
[ 1039.498714] systemd-journald[44]: Received SIGTERM from PID 1 (systemd-shutdow).
[ 1039.770715] EXT4-fs (sde): unmounting filesystem 79d0ef33-9c4f-46ec-954e-b78362282797.
[ 1081.021581] mini_init (121): drop_caches: 1

[ 1255.654486] EXT4-fs (sde): mounted filesystem 79d0ef33-9c4f-46ec-954e-b78362282797 r/w with ordered data mode.
[ 1277.397923] Exception:
[ 1277.397928] Operation canceled @p9io.cpp:258 (AcceptAsync)
[ 1280.670938] systemd-journald[44]: Received SIGTERM from PID 1 (systemd-shutdow).
[ 1280.988326] EXT4-fs (sde): unmounting filesystem 79d0ef33-9c4f-46ec-954e-b78362282797.
[ 1321.024108] mini_init (121): drop_caches: 1

Alongside this, the journal is repeatedly marked unclean:

systemd-journald[47]: File /var/log/journal/997271786bac45bba80c636b9147e856/system.journal corrupted or uncleanly shut down, renaming and replacing.

And GPU-related ioctls fail continuously (also seen in #11293):

misc dxg: dxgk: dxgkio_query_adapter_info: Ioctl failed: -2
misc dxg: dxgk: dxgkio_is_feature_enabled: Ioctl failed: -22

Host-side drvfs mounts

In the affected state, docker-desktop holds 28 9p/drvfs mounts (4 host drives x several mount namespaces, plus bind-mount entries):

C:\ on /mnt/host/c type 9p (rw,noatime,aname=drvfs;path=C:\;uid=0;gid=0;metadata;symlinkroot=/mnt/host/,cache=0x5,access=client,msize=65536,trans=fd,rfd=5,wfd=5)
D:\ on /mnt/host/d type 9p (...)
... (repeated under /tmp/docker-desktop-root/... and per-bind-mount)

This is relevant because the controlled experiment in #41484 narrowed the trigger to drvfs automount.

Relation to existing issues

• #41484 (p9io.cpp:258 (AcceptAsync) + docker veth teardown + journal corruption): identical Operation canceled @p9io.cpp:258 (AcceptAsync) signature on Windows 10 22H2 / WSL 2.7.12 / kernel 6.18.33.2-2 / WSLg 1.0.73.2. Closed by the stale bot, not by a fix. A controlled experiment there showed that disabling drvfs automount (/etc/wsl.conf → [automount] enabled=false) eliminated the crash entirely.
• #41191 (Kernel BUG at fs/namei.c:844 (try_to_unlazy) after 9P/virtiofs channel disruption): open, still receiving reports on WSL 2.7.14.0 / kernel 6.18.33.2-2.
• #11293: same dxgkio_query_adapter_info ioctl failures.

What does not work / what works

• Restarting Docker Desktop alone: does not help. The backend reconnects to the same broken distro instance.
• wsl --shutdown alone: does not help. Tried on this machine before the failure was diagnosed - the distro comes back in the same broken state. This matches docker/for-win#14804, where Docker's watchdog restarts the distro immediately, so the broken state survives.
• Killing Docker user processes first, then wsl --shutdown, then starting Docker Desktop: recovers, because the first step stops the watchdog from racing the shutdown. This is what worked here.

Notes

• The distro's data disk lives on D:\DockerDesktopWSL (via Docker's CustomWslDistroDir), not on the system drive.
• docker_data.vhdx is 148 GB; D: had ~102 GB free when inspected shortly after the failure, so disk exhaustion is not the cause.
• No .dmp crash dump was produced.

/cc @renegadeV (from #41484), @warlockhouseefs (from #41191)