WSLg 1.0.71: GUI session freezes, then Weston becomes unkillable in /mnt/shared_memory virtiofs

Windows build number:

10.0.26200.8655

Your Distribution version:

Ubuntu 26.04 LTS

Your WSL versions:

WSL version: 2.6.3.0 Kernel version: 6.6.87.2-1 WSLg version: 1.0.71 MSRDC version: 1.2.6353 Direct3D version: 1.611.1-81528511 DXCore version: 10.0.26100.1-240331-1435.ge-release Windows version: 10.0.26200.8655

WSLg: 1.0.71+Branch.main.Sha.b836effa32844bc32bc858e8dd1c5360791171a5 FreeRDP: c4030980b29322a9cb2190711a5fadeeeb8b6a33 Weston: 2318fecaeac1f1a2d5a7a042c34d931c71dae04c PulseAudio: c33051f2296af748ac5cd13e51abfac4d129e4c7

Relevant .wslconfig settings:

[general]
instanceIdleTimeout=86400000

[wsl2]
networkingMode=Mirrored
firewall=false
vmIdleTimeout=86400000
distributionStartTimeout=60000

[experimental]
hostAddressLoopback=true
autoMemoryReclaim=gradual

Steps to reproduce:

I do not yet have a short deterministic reproduction. This is the chronology of the captured failure:

1. Run a long-lived WSL/WSLg session and open JetBrains Toolbox and Android Studio as Linux GUI applications under WSLg.
2. Both applications simultaneously stop repainting and accepting input. Their processes remain alive.
3. Confirm that this is not an application/JVM deadlock:
   • xset -q completes through Xwayland.
   • jcmd can attach to both JVMs.
   • Their AWT event threads are idle/waiting for events rather than deadlocked.
   • The Windows msrdc.exe process initially still reports Responding.
4. As a recovery attempt after the freeze, terminate only the WSLg msrdc.exe client. WSLGd launches a replacement msrdc.exe, but it remains trying to connect and the GUI does not recover. Weston does not record a new RDP connection.
5. Attempt to terminate Weston. It does not exit, even with SIGKILL, and is observed in Linux D state with SIGKILL pending.
6. Attempt a narrowly scoped reset of the wslg virtiofs device (virtio1). The unbind operation also becomes unkillable in D state while draining the virtiofs queue.
7. Only a full WSL VM shutdown/restart clears the kernel waits.

Steps 4–6 are recovery/diagnostic actions, not claimed as the original trigger. The original visible failure occurs before any process or device is restarted.

WSL logs:

wslg-virtiofs-hang-2026-07-10-public-diagnostics.zip

WSL dumps:

A normal userspace core dump was not obtainable because Weston was blocked in uninterruptible D state with SIGKILL pending. The attached live kernel stacks and /proc records capture the blocked state.

Expected behavior:

• WSLg windows continue repainting and receiving input.
• If the Windows RDP client fails or is restarted, WSLGd/Weston reconnect or fail cleanly without wedging the shared-memory filesystem.
• Weston and virtiofs teardown do not enter uninterruptible kernel waits requiring the entire WSL VM to be restarted.

Actual behavior:

All WSLg GUI surfaces froze together while the Linux applications and the rest of the distro remained responsive. A new msrdc.exe could not reconnect. During recovery, Weston was unkillable in a FUSE request against WSLg's shared-memory virtiofs mount.

Weston (PID 14) state and wait channel:

State: D (disk sleep)
SigPnd: 0000000000000100
ShdPnd: 0000000000000100
wchan: request_wait_answer

Weston's kernel stack:

request_wait_answer
fuse_simple_request
fuse_do_getattr
fuse_permission
inode_permission
link_path_walk
path_openat
do_filp_open
do_sys_openat2
__x64_sys_openat

Inspection of the blocked openat() argument showed:

openat(AT_FDCWD,
       "/mnt/shared_memory/{377fcf8e-3e3c-48cd-8114-c01e39184de8}",
       O_RDWR|O_CREAT|O_EXCL, 0600)

/mnt/shared_memory is the WSLg virtiofs mount with source wslg, backed by virtio device virtio1.

The process attempting to unbind virtio1 also entered D state:

wchan: virtio_fs_drain_queue

virtio_fs_drain_queue
virtio_fs_remove
virtio_dev_remove
device_remove
device_release_driver_internal
device_driver_detach
unbind_store
drv_attr_store
sysfs_kf_write

This points to a stuck WSLg shared-memory virtiofs request/queue rather than a JetBrains application deadlock. It also explains why restarting Android Studio, Toolbox, or only msrdc.exe could not recover the session.