WSL2 X11 output corruption

[deviantbit]

Windows Version

Version 10.0.22631 Build 22631

WSL Version

2.0.9.0

Are you using WSL 1 or WSL 2?

• WSL 2
• WSL 1

Kernel Version

5.15.133.1-1

Distro Version

Ubuntu-22.04

Other Software

Any and all applications that use xlib or X Windows.

Repro Steps

Launch an xeyes, or emacs.

Expected Behavior

Actual Behavior

Diagnostic Logs

Nothing in logs to report.

[github-actions]

Hi I'm an AI powered bot that finds similar issues based off the issue title.

Please view the issues below to see if they solve your problem, and if the issue describes your problem please consider closing this one and thumbs upping the other issue to help us prioritize it. Thank you!

Closed similar issues:

• Corrupted WSL (#7016), similarity score: 0.80
• WSL got corrupted (#3536), similarity score: 0.80
• WSL gets corrupt out of nothing (#4697), similarity score: 0.80
• wsl 2 stops working for unknown reason (#8357), similarity score: 0.80
• WSL2 stops working (#4405), similarity score: 0.79
• wsl 2 breaks vcxsrv X11 server (#6941), similarity score: 0.79
• WSL characters get corrupted after a while (#5777), similarity score: 0.79
• WSL2 completely breaks after resetting ubuntu (#7112), similarity score: 0.78
• wsl2 causes blue screen (#9129), similarity score: 0.78
• WSL2 Suddenly Stopped Working (#10467), similarity score: 0.78

Note: You can give me feedback by thumbs upping or thumbs downing this comment.

[deviantbit]

I have tried multiple versions of NVIDIA drivers. Doesn't appear to be a driver issue. Appears to be and issue with the internal X window server.

[etxaleku]

I'm experiencing the same issue. After a lot of reading I'm thinking that it may be because I'm running on a Surface Pro 7 with a 2560x1440 resolution display. Found some postings talking about HiDPI displays having issues with FreeRDP, an internal WSLg component.

$ wsl.exe --version
WSL version: 2.0.9.0
Kernel version: 5.15.133.1-1
WSLg version: 1.0.59
MSRDC version: 1.2.4677
Direct3D version: 1.611.1-81528511
DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Windows version: 10.0.22621.2715

Specifically I'm (also) trying to get emacs working using the following:

$ git clone --single-branch --branch emacs-29 git://git.sv.gnu.org/emacs.git
$ sudo apt install build-essential libgtk-3-dev libgnutls28-dev libtiff5-dev libgif-dev libjpeg-dev libpng-dev libxpm-dev libncurses-dev texinfo autoconf libgccjit-11-dev libsqlite3-dev xml2 libattr1-dev libacl1-dev libxml2-dev
$ cd emacs
$ ./autogen.sh
$ ./configure --with-pgtk
$ make -j4
$ sudo make install

$ emacs --version
GNU Emacs 29.1.90
Development version 687c416ce9bf on emacs-29 branch; build date 2023-11-27.

All Windows 11 updates have been applied with particular attention to drivers and firmware.

gnome-tweaks and other linux gui apps all seem to have the same behavior.

[deviantbit]

I plugged in a 1080p monitor. It had the same issue.

[etxaleku]

I also noticed that whenever I try to run any GUI apps like emacs for example, my %AppData%\Local\Temp\DiagOutputDir\RdClientAutoTrace folder is filling up with hundreds of 4MB files...

[deviantbit]

This is rasterization problem.

[etxaleku]

I got mine completely working! It's rock solid and I couldn't be happier... well, I guess I could win the Lotto but... :)

So I tried a ton of stuff but the one that got everything working was upgrading my video driver. So throughout Microsoft's WSL/WSLg web pages they do mention that it's very important for WSLg/Wayland to work that you update your video driver to the latest from the manufacturer. But then both Microsoft (laptop vendor) and Intel (driver vendor) warn that if you update from Intel (the driver vendor) then you risk losing any special customizations/configurations that the OEM vendor (Microsoft in this case) may have made and worst case you could even lose your video entirely (the warnings look a bit ominous). They both recommend going to the laptop vendor site and upgrading from there as the safe path - so that's what I had (previously) done. But in the case of the Surface Pro Microsoft does offer a single package that upgrades all the Surface drivers and firmware and puts everything back to "out of box" so I applied that (early on) but no joy. So armed with that as a "backup" I went ahead, held my breath, and upgraded from the Intel (driver vendor) site at www.intel.com/content/www/us/en/support/intel-driver-support-assistant.html being careful to select the right video hardware and "generation", etc. The vendor driver update went smoothly (I may have passed out holding my breath once or twice during the process, it took a while) but then after a reboot I brought up emacs and it seems rock solid. No video weirdness whatsoever, new frames are fine, splitting windows is flawless, everything is exactly as I've known emacs to be for, well, a long time. Even web browsing works (I'd never even tried that before)!

And no more trace files have shown up in my %AppData%\Local\Temp\DiagOutputDir\RdClientAutoTrace folder.

Also, all other WSL GUI apps (gnome-tweaks, octave, gnuplot, etc) are also all working smoothly now. Octave and gnuplot integrate and work from emacs smoothly.

I cannot say enough great things about WSL/WSLg - it's the environment I've always wished for and maybe a bit more!

Thanks to everyone that worked on and supports WSL/WSLg!

[deviantbit]

Something else resolved it. I'm not on a laptop, and using the latest drivers. I went back several generation of drivers and it still had the problem. So you did something else.

[ksylvan]

I'm on a desktop, with an external display, seeing the same thing.

I have an NVIDIA GeoForce RTX-4090 and the latest drivers.

[etxaleku]

Hmm, I see what you mean. Are you also seeing those trace files piling up in your %AppData%\Local\Temp\DiagOutputDir\RdClientAutoTrace folder?

For me, I really feel like the driver update made the difference. But there’s a lot of components involved here so I can imagine that every situation has its own nuances. I kept pretty careful notes and I went back and reviewed my command history, and I couldn’t find anything else that looked like it really had any hope. I installed libgccjit-11-dev if that makes a difference.

[ksylvan]

Hmm, I see what you mean. Are you also seeing those trace files piling up in your %AppData%\Local\Temp\DiagOutputDir\RdClientAutoTrace folder?

Yes @etxaleku

[keesj]

I have had similar issues (on and off) for .. about the last 2 or 3 weeks. E.g. I started seeing the issue on a Friday morning(I guess after a windows update) and was having different problems but the issue disappeared .. possibly after restarting wsl. Due to other issues over the last week (can only run WSL as administrator I install a pre-release (version 2.0.11) see https://github.com/microsoft/WSL/releases and I think the problems started to appear again.

I have an Intel IRISxe graphics card, dell laptop and dell usb-c docking startion/multiple displays.

Update: I upgrade the 2.0.12.0 and the issue remains present form me
(my intel driver is from 11/07/2023)

[ksylvan]

I've restarted WSL (and even shutdown and restart the desktop) and can reproduce this every time, so it's a genuine WSLG bug as far as I can see.

[etxaleku]

I had a bit of a regression - so my Surface Pro 7 with WSL2 initially experienced the video "fuzzing" problem and I struggled with it for a while but eventually upgraded my Intel Iris Plus driver from the intel web site and all my issues stopped. No more video "fuzz" ever, all Linux graphical apps run smoothly (gnome-tweaks, etc) and no more trace files piling up in that RdClientAutoTrace folder. Well... that is until I did some desktop screen sharing and tried to show them how it was all working... something about the desktop screen sharing caused the issue to come back - emacs and all Linux GUI apps all "fuzzed out" 100% of the time and the RdClientAutoTrace folder starting filling up with the 4MB trace files again... situation continued until I rebooted (getting out of the screen sharing session made no difference) and after the reboot everything is back to rock solid working order... no more fuzz or trace files...

So it look like I have a great working environment, but I can't ever do any screen sharing and expect it to work. :(

And probably once I do any screen sharing then I'll need to reboot to get things working again.

Oh well, it could be worse, as others have mentioned (where they don't have a "fix").

Just thought I'd document the screen sharing aspect as that might shed some insight to a WSLg developer trying to work on this issue.

[keesj]

In my case I do not think it matters if I use an external display or not. I can boot and reproduce the issue with my laptop "standalone"

[mahi1980]

I have the same issues. Updating GPU drivers didn't work (AMD Radeon Pro WX 2100, Driver 31.0.21018.6011 (2023/08/24)).
RdClientAutoTrace is being filled as well, but file size is much larger than 4MB.

[Stanzilla]

I have the same issue, also latest driver from today (nvidia)

[lucvdv-aleacsys]

Same issue here, latest Dell-provided Nvidia drivers on a Dell laptop.
I only found out about WSLg this morning after the problem occurred. I don't use GUI apps that much and thought I was still using VCXSrv, which always did the job fine. Turns out it was silently changed into using WSLg.
No wonder uninstalling (and reinstalling) VCXSrv didn't help :)

[thanat0s]

I have the same issue on NVIDIA 546.29 latest WHQL driver on a triple monitor desktop setup.

EDIT: problem seems solved using this : #1130

[bryghtlabs-richard]

Dell laptop with Dell Nvidia drivers, first boot of wsl2, same issue. Looks like a mismatch in stride or pixel format. Thanat0s' linked solution apt update, apt upgrade, wsl --shutdown fixed it for me.

[brianherold]

Thanat0s' linked solution fixed it for me as well. I'm running a Dell laptop with Dell Nvidia drivers. The issue popped up for me sometime last week after a few months of stable use.

[deviantbit]

That didn't resolve it for me. Maybe there is an update being pushed down stream that hasn't arrived.

[lucvdv-aleacsys]

I hadn't tried any GUI apps since my previous comment (2 weeks ago), so I don't know exactly when it got fixed, but the problem no longer occurs here either (see comments by brianherold and thanat0s).
I remember doing an 'apt update && apt upgrade' last wednesday, so that must have fixed it.

[deviantbit]

This has been resolved for me now.

[av-2024]

This should be reopened. It might be resolved for @deviantbit, but the same issue exists for a lot of other people. For me, it happens after my system has been on for a while. Rebooting temporarily fixes it, but it always happens again after some time.

[deviantbit]

Okay. I reopened the issue.

[etxaleku]

I agree, it is working for me (very reliably) but there are times when it regresses and the issue reappears. The two situations where I have seen it reappear is -

R1. if I use Teams in a screen sharing session then I have seen it reappear. Rebooting (and avoiding screen sharing) returns it to working condition.
R2. if I bring up other Windows-based apps of a "graphical" nature, like a browser, BEFORE starting WSL2 and X-based Linux apps, then the issue seems to be very reproducible - so far 100% of the time based on about 10 reiterations.

For R1 I have successfully been able to do some Teams screen sharing recently and did not have the issue reappear. That one seems to be intermittent. Given the frequency of the Teams screen sharing recurrence, I'm almost wondering if those few times that occurred that it might have actually been a reproduction of R2 as I wasn't aware of R2 initially.

For R2, that one seems very reproducible. If I reboot and the very first thing I start up is WSL2 and then emacs then everything works very reliably and I can use anything (Windows or Linux) I want for days on end without issue. But if I reboot and bring up a browser first then when I start WSL2 and then emacs the issue appears every time. A quick reboot returns everything to working order.

@avaranze, when you say that it works and then "always happens again after some time", how much time are you finding has to pass before it happens? Is it hours or days? Mine has been stable for periods on the order of 7 days or so. The main X-based "graphical" app that I'm running is emacs though I have recently started running a Linux-based version of IntelliJ (Community Edition).

I do also see the "other" issue where X-based graphical apps are "orphaned" after a Windows sleep. Basically if your machine goes to sleep for any reason (manual or automatic), then after resuming the graphical apps are still running according to "ps -ef" but they don't appear on the taskbar and cannot be rendered. But this is a different issue than the one discussed here - the video "fuzzing" issue.

[keesj]

I am still having the issue

[fuzy112]

I still have this issue. A workaround for me is to use fullscreen mode when using Emacs (M-x toggle-frame-fullscreen). But other apps still don't work now.

[indigodarkwolf]

I ran into this issue on a fresh Windows 11 install. Double-checked and already had the latest drivers for my NVIDIA card. Using WSL and the Debian build from the Microsoft Store app.

I wound up working around it by creating a .wslgconfig file in %userprofile%, following the advice from #1148 (comment).

[jakubzeman-acc]

A simple solution that worked for me on Windows 11 was setting a default user in the Windows registry. Set the following key to your non-root UID (usually 1000, which is in HEX 3e8)> HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Lxss<UUID>\DefaultUid

And restart wsl.

[epg]

:metoo:

WSL version: 2.0.14.0
Kernel version: 5.15.133.1-1
WSLg version: 1.0.59
MSRDC version: 1.2.4677
Direct3D version: 1.611.1-81528511
DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Windows version: 10.0.19045.3930

Reproducible with:

• dsda-doom v0.27.5
• emacs 29.1
• gtk3-icon-browser from gtk3-tools 3.24.38
• seamonkey 2.53.18
• xterm 388

[tkonsta]

After reading some comments which related to the intermittent WSLg issues to running programs on windows I did some tests and for me disabling Microsoft PowerToys resulted in a reliably stable WSLg experience without UI glitches and without lagging or hanging keyboard. Maybe someone else who is running PowerToys on Windows could give this a try and confirm?

[keesj]

I have tried a few more suggestions posted here and elsewhere

• Disabling opengl in wslconfig

keesj@vlsi:/mnt/c/Users/keesj$ cat .wslconfig
[wsl2]
memory=24GB

[system-distro-env]
;disable GPU in system-distro
LIBGL_ALWAYS_SOFTWARE=1

• Downgrading drivers

Perhaps that my setup has something else with it going wrong.

• I did upgrade the kernel / ubuntu to a recent version e.g. 23.10
• Hyper-V is disabled

Currently I am working around the issue by using xpra (but that does require me to remount /tmp/.X11-unix read/write

[neodon]

I've run into this problem many times and did some experimenting. Observations:

• Performing wsl --shutdown or wsl --terminate my-distro and then starting my apps back up does not seem to resolve the problem.
• Likewise, closing all apps and waiting for wsl to shut down automatically doesn't work either.

Here is the solution I am using that has been working consistently. This command needs to be run in PowerShell as an administrator.

Restart-Service -Name WSLService

Since the WSLg processes run under WSLService, this command restarts them. It consistently fixes the corrupt display issue for me... at least for a few hours. 🤷

[Cpt-Squirrell]

I can throw my hat into the mix here. Same issue consistently as the images earlier in this thread show.
I run Intel ARC card so hey, mine might not be very surprising. For all I know though it might not be GPU related at all.

[mahi1980]

For me, updating to the latest pre-release of WSL solved the issue.
https://github.com/microsoft/WSL/releases/tag/2.1.1

[keesj-riscure]

For me, updating to the latest pre-release of WSL solved the issue. https://github.com/microsoft/WSL/releases/tag/2.1.1

From the looks of it. it might also have solved my problem

Initial state

WSL version: 2.0.14.0
Kernel version: 5.15.133.1-1
WSLg version: 1.0.59
MSRDC version: 1.2.4677
Direct3D version: 1.611.1-81528511
DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Windows version: 10.0.19045.4046

Upgraded

wsl --update --pre-release
Checking for updates.
Updating Windows Subsystem for Linux to version: 2.1.3.

and so far things appear to be working. I also noticed that 2.1.1 has an upgrade of gwsl to version 1.0.60

[etxaleku]

@keesj-riscure and @mahi1980, your approach of upgrading to the WSL pre-release sounds very promising and your results sound great but one question - how stable is your environment? Do you use it a lot and depend on it for work? It sounds like you've both been on it for about a week, any concerns? I use mine for work and have to depend on it to work.

One aspect I've noticed that probably significantly contributes to the seemingly random behavior is that starting from a Windows reboot, for me at least, it greatly depends on the order that I start apps. If I reboot and start emacs or any X-application from WSL BEFORE running any Windows graphics apps then everything works and life is good. But if I reboot Windows and bring up say a browser and pull up some web pages and then try to start any WSL X-applications then I get the video fuzzing.

Definitely planning on trying @neodon's recommendation of Restart-Service -Name WSLService from PowerShell, that sounds promising.

[keesj-riscure]

@keesj-riscure and @mahi1980, your approach of upgrading to the WSL pre-release sounds very promising and your results sound great but one question - how stable is your environment? Do you use it a lot and depend on it for work? It sounds like you've both been on it for about a week, any concerns? I use mine for work and have to depend on it to work.

I use WSL2 / Ubuntu 99% of the time and I am quite sure my setup is unique and over the last 2 years of using WSL2 it has been a love/hate affair. I can not perform my work without it and when it works .. it works great but I do accept some breakage.

This last update resolved multiple issues for me who is forced to use a firewall/VPN. I needed to run "netsh winsock reset" after every reboot before I was able to access WSL2 and this problem is gone. A colleague of mine was able to restore X11 using #426 (e.g. wsl --system, and then kill -9 the /usr/bin/weston ) but that did not work for me.

In the time X11 was not working I used https://github.com/Xpra-org/xpra/wiki/Download with much satisfaction.
(I had to mount -o remount,rw /tmp/.X11-unix the X11 folder and started xpra start --start=xterm --bind-tcp=0.0.0.0:10000 )

All that to say.. that I am currently very happy with the upgrade and the relationship is currently good but dmesg is trying to tell me something different:

[   17.647043] WSL (2) ERROR: WaitForBootProcess:3335: /sbin/init failed to start within 10000
[   17.667864] WSL (2): Creating login session for keesj

One aspect I've noticed that probably significantly contributes to the seemingly random behavior is that starting from a Windows reboot, for me at least, it greatly depends on the order that I start apps. If I reboot and start emacs or any X-application from WSL BEFORE running any Windows graphics apps then everything works and life is good. But if I reboot Windows and bring up say a browser and pull up some web pages and then try to start any WSL X-applications then I get the video fuzzing.

I have had occasions where it was working but wsl --shutdown never fixed it for me.

Definitely planning on trying @neodon's recommendation of Restart-Service -Name WSLService from PowerShell, that sounds promising.

[mahi1980]

@etxaleku I need WSL for work as well, so basically I had no real choice. Regularly trying the new pre-releases was my only hope to come back to a fully operational setup.
So far, I did not have any further issues with the pre-release.

[etxaleku]

Thanks for the feedback, gives me confidence to go to the pre-release.

This last update resolved multiple issues for me who is forced to use a firewall/VPN. I needed to run "netsh winsock reset" after every reboot before I was able to access WSL2 and this problem is gone.

Oh wow, I wonder if this will resolve my WSL2 issue when on VPN... Whenever I'm on VPN I have had to use WSL1 as WSL2 would not route traffic properly. I tried everything I could find to get it to work but nothing helped - maybe going to the pre-release of WSL2 will do it for me!