wslg
wslg copied to clipboard
microsoft
WSL2 X11 output corruption
Windows Version
Version 10.0.22631 Build 22631
WSL Version
2.0.9.0
Are you using WSL 1 or WSL 2?
- [X] 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.
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.
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
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.
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.
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...
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!
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.
I'm on a desktop, with an external display, seeing the same thing.
I have an NVIDIA GeoForce RTX-4090 and the latest drivers.
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.
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
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)
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.
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.
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"
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.
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 :)
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
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.
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.
That didn't resolve it for me. Maybe there is an update being pushed down stream that hasn't arrived.
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.
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.
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.
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.
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 https://github.com/microsoft/wslg/issues/1148#issuecomment-1827607993.
