Repository navigation
WSL 2.7.3: /mnt/shared_memory missing → WSLg windows invisible ([WARN:COPY MODE]) #40618
Description
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
- Update to WSL 2.7.3
- Start WSL
- Run:
xeyes - 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_memoryAfter 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_memoryis 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.
Activity
github-actions commentedon May 21, 2026
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:
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 networkinginstead, following the instructions in Collect WSL logs for networking issuesOnce 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 commentedon May 21, 2026
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 commentedon May 21, 2026
Additional Observation
The issue is not stable:
/mnt/shared_memoryThis suggests WSLg is inconsistently selecting between rendering paths.
chemwolf6922 commentedon May 21, 2026
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 commentedon May 21, 2026
done: microsoft/wslg#1456
Document the Windows install path and the WSLg [WARN: COPY MODE] bug
Pitfalls: the WSLg copy-mode blank window is a missing /mnt/shared_me…