WSLg 1.0.71: GUI 会话冻结,然后 Weston 在 /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.

1. 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.
2. Attempt to terminate Weston. It does not exit, even with SIGKILL, and is observed in Linux D state with SIGKILL pending.
3. 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.
4. 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.