WSL 2.7.3: /mnt/shared_memory missing → WSLg windows invisible ([WARN:COPY MODE])

[neumaennl]

Windows Version

Microsoft Windows [Version 10.0.26200.8457]

WSL Version

2.7.3.0

Are you using WSL 1 or WSL 2?

• WSL 2
• WSL 1

Kernel Version

6.6.114.1-1

Distro Version

Ubuntu 24.04

Other Software

No response

Repro Steps

1. Update to WSL 2.7.3
2. Start WSL
3. Run: xeyes
4. Observe:

• taskbar entry appears
• no window is rendered

Expected Behavior

xeyes GUI window appears and the eyes follow the mouse pointer

Actual Behavior

After updating to WSL 2.7.3, WSLg GUI applications no longer render any windows.

• Applications launch successfully
• Taskbar icons appear
• Window previews show a blank surface
• No actual window is visible

The window title includes: [WARN:COPY MODE]

Diagnostic Logs

The issue is caused by /mnt/shared_memory not being mounted at all.
Expected:
/mnt/shared_memory
Actual:

$ ls -l /mnt
total 3
drwxrwxrwx 1 neumann neumann 4096 May 21 07:30 c
drwxrwxrwt 2 root    root      60 May 21 09:44 wsl
drwxrwxrwt 7 root    root     300 May 21 09:44 wslg
$

From /mnt/wslg/weston.log:
rdp_allocate_shared_memory: Failed to open "/mnt/shared_memory/..." with error: Input/output error

Workaround

Manually creating the mount fixes the issue:

sudo mkdir -p /mnt/shared_memory
sudo mount -t tmpfs tmpfs /mnt/shared_memory

After this:

• GUI windows render normally
• [WARN:COPY MODE] disappears

After manually mounting /mnt/shared_memory once (tmpfs) and then unmounting it again, GUI applications continue to render correctly — even across wsl --shutdown and windows reboot.

This suggests:

• WSLg initialization fails if /mnt/shared_memory is missing at startup
• but once the rendering pipeline is successfully initialized, it continues working even without it

This indicates a timing / initialization dependency rather than a strict runtime requirement.

[github-actions]

Logs are required for review from WSL team

If this a feature request, please reply with '/feature'. If this is a question, reply with '/question'.
Otherwise, please attach logs by following the instructions below, your issue will not be reviewed unless they are added. These logs will help us understand what is going on in your machine.

How to collect WSL logs

Download and execute collect-wsl-logs.ps1 in an administrative powershell prompt:

Invoke-WebRequest -UseBasicParsing "https://raw.githubusercontent.com/microsoft/WSL/master/diagnostics/collect-wsl-logs.ps1" -OutFile collect-wsl-logs.ps1
Set-ExecutionPolicy Bypass -Scope Process -Force
.\collect-wsl-logs.ps1

The script will output the path of the log file once done.

If this is a networking issue, please use .\collect-wsl-logs.ps1 -LogProfile networking instead, following the instructions in Collect WSL logs for networking issues

Once completed please upload the output files to this GitHub issue.

See Collect WSL logs (recommended method).

If you choose to email these logs instead of attaching them to the bug, please send them to wsl-gh-logs@microsoft.com with the GitHub issue number in the subject, and include a link to your GitHub issue comment in the message body, and reply with '/emailed-logs'.

[neumaennl]

Since I can't reproduce the issue anymore after my workaround, I'm attaching the logs from when the error still existed.

weston.log
stderr.log

[neumaennl]

Additional Observation

The issue is not stable:

• Sometimes WSLg falls back to a mode where GUI apps render correctly even without /mnt/shared_memory
• After some time or restarting GUI apps, it switches back to the broken state
• No user action is required to trigger the change

This suggests WSLg is inconsistently selecting between rendering paths.

[chemwolf6922]

Hi @neumaennl , Could you please reopen this issue in https://github.com/microsoft/wslg/issues ? That will help get the correct personal to look at it. Thanks.

[neumaennl]

done: microsoft/wslg#1456