microsoft / wslg

Enabling the Windows Subsystem for Linux to include support for Wayland and X server related scenarios
MIT License
10.1k stars 304 forks source link

All GUI apps unresponsive #539

Open shebiki opened 2 years ago

shebiki commented 2 years ago

Environment

Windows build number:Microsoft Windows [Version 10.0.22000.282]
Your Distribution version: Ubuntu 20.04
Your WSLg version: 1.0.26 (preview from app store)

Steps to reproduce

Not sure what caused the crash, all GUI apps become unresponsive. Unable to move/resize their windows or interact with them in anyway. I was also running Docker Desktop at the same time.

Was unable to kill weston with wsl.exe --system followed by ps auxw | grep weston and kill -9 10. Process didn't seem to go away. Using wsl.exe --shutdown resolved the issue.

WSL logs:

You can access the wslg logs using explorer at: \\wsl$\<Distro-Name>\mnt\wslg (e.g.: \\wsl$\Ubuntu-20.04\mnt\wslg)

shebiki commented 2 years ago

Just reproduced this. No Docker Desktop running. Only GUI app was PyCharm which became unresponsive after typing quickly into the autocomplete popup while editing code. App was maximized on second monitor.

rsegeda commented 2 years ago

The same thing happens to me, regardless of the docker. Google Chrome, Jetbrains apps (toolbox, intellij. Sometimes all windows disappear with no error message whatsoever. It seems that the RDP connection is not there anymore.

here's weston.log ⬇️ weston.log

stderr.log ⬇️

dbus[11]: Unknown username "pulse" in message bus configuration file
glamor: 'wl_drm' not supported
Missing Wayland requirements for glamor GBM backend
Failed to initialize glamor, falling back to sw
/usr/share/icons/hicolor/scalable/apps/org.gnome.gedit.svg: unrecognized file header 0x3c 0x3f 0x78 0x6d
/usr/share/icons/hicolor/scalable/apps/org.gnome.seahorse.Application.svg: unrecognized file header 0x3c 0x3f 0x78 0x6d
/usr/share/icons/hicolor/scalable/apps/ibus-setup.svg: unrecognized file header 0x3c 0x3f 0x78 0x6d
The XKEYBOARD keymap compiler (xkbcomp) reports:
> Internal error:   Could not resolve keysym XF86FullScreen
Errors from xkbcomp are not fatal to the X server
The XKEYBOARD keymap compiler (xkbcomp) reports:
> Warning:          Unsupported maximum keycode 569, clipping.
>                   X11 cannot support keycodes above 255.
> Internal error:   Could not resolve keysym XF86FullScreen
Errors from xkbcomp are not fatal to the X server
The XKEYBOARD keymap compiler (xkbcomp) reports:
> Warning:          Unsupported maximum keycode 569, clipping.
>                   X11 cannot support keycodes above 255.
> Internal error:   Could not resolve keysym XF86FullScreen
Errors from xkbcomp are not fatal to the X server
The XKEYBOARD keymap compiler (xkbcomp) reports:
> Warning:          Unsupported maximum keycode 569, clipping.
>                   X11 cannot support keycodes above 255.
> Internal error:   Could not resolve keysym XF86FullScreen
Errors from xkbcomp are not fatal to the X server

Additionally, from pulseaudio.log ⬇️ :

W: [pulseaudio] authkey.c: Failed to open cookie file '/home/wslg/.config/pulse/cookie': No such file or directory
W: [pulseaudio] authkey.c: Failed to load authentication key '/home/wslg/.config/pulse/cookie': No such file or directory
W: [pulseaudio] authkey.c: Failed to open cookie file '/home/wslg/.pulse-cookie': No such file or directory
W: [pulseaudio] authkey.c: Failed to load authentication key '/home/wslg/.pulse-cookie': No such file or directory
E: [pulseaudio] module-console-kit.c: GetSessionsForUnixUser() call failed: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.ConsoleKit was not provided by any .service files
E: [pulseaudio] module.c: Failed to load module "module-console-kit" (argument: ""): initialization failed.
E: [rdp-sink] module-rdp-sink.c: RDP Sink - Trying to connect to /mnt/wslg/PulseAudioRDPSink
E: [rdp-sink] module-rdp-sink.c: Connected failed
E: [rdp-sink] module-rdp-sink.c: RDP Sink - Trying to connect to /mnt/wslg/PulseAudioRDPSink
E: [rdp-sink] module-rdp-sink.c: RDP Sink - Connected to fd 12

versions.txt ⬇️

WSLg ( x86_64 ): 1.0.26+Branch.main.Sha.26ce2c09b86442f3c7f4f6462f770ed2afa76a25
Mariner: VERSION="1.0.20210224"
FreeRDP: b05321cd4e6a862aef76163a69db4e1910245736
weston: 46756d0e77e5c01b5995fbbee6f3ab0db9b30612
pulseaudio: 2f0f0b8c3872780f15e275fc12899f4564f01bd5
mesa:
jama22 commented 2 years ago

Had the same thing happen to me while working on a little python tutorial for building a roguelike game. Repro steps seem pretty consistent. In Step 1 of the tutorial, it demonstrates how you can write a script that responds to the ESC key on the keyboard to close the game. When you first run the Step 1 code, the window closes normally. When you try to run the code again though, the game window flashes briefly and then terminates. I've done some light debugging of the issue and it seems like the root cause is the SystemExit() is what puts the window server into that state.

Steps to Reproduce

  1. Pull the sample code from this repo https://github.com/TStand90/tcod_tutorial_v2/tree/2020/part-1
  2. Using PYthon 3.5+, install the requirements.txt
  3. run python3 main.py
  4. Press ESC key to close the windows
  5. run python3 main.py again

Expected Results

Should see the game window again

Actual Results

Game window flashes briefly and then disappears.

Workaround

As @shebiki mentions, you basically have to shut down wsl and then open a new terminal to get things back to normal again.

stderr.log seems similar to what others have posted

dbus[11]: Unknown username "pulse" in message bus configuration file
glamor: 'wl_drm' not supported
Missing Wayland requirements for glamor GBM backend
Failed to initialize glamor, falling back to sw
The XKEYBOARD keymap compiler (xkbcomp) reports:
> Internal error:   Could not resolve keysym XF86FullScreen
Errors from xkbcomp are not fatal to the X server
The XKEYBOARD keymap compiler (xkbcomp) reports:
> Warning:          Unsupported maximum keycode 569, clipping.
>                   X11 cannot support keycodes above 255.
> Internal error:   Could not resolve keysym XF86FullScreen
Errors from xkbcomp are not fatal to the X server
asampal commented 2 years ago

Happening here as well. Quite annoying and significantly detracts from the usefulness of being able to run graphical apps.

Windows build number: 10.0.22000.527
Your Distribution version: Ubuntu 20.04 (2004.2022.1.0)
Nvidia driver version: 30.0.15.1179
chewi commented 2 years ago

This is driving me crazy and is impeding my ability to work for Microsoft!

pofl commented 2 years ago

This happens on a daily basis for me and is catastrophic. Especially with Jetbrains apps running from WSL.

MaZhengKe commented 2 years ago

I also found this bug in the openGL program I wrote, there is a possibility that the ESC key will be triggered within one second after the program starts. This issue is fixed in preview

RiccardoManzan commented 2 years ago

I use WSLG only for intellij. For me this is likely to happen when i have my docker containers up and running, but not every time happens. This non-deterministic thing is kinda frustraing. Only restarting whole wsl solves the problem, and this is quite annoying as then i need to relaunch all the apps and services i was working on. Not sure if this relates to or is duplicated by #605

linghengqian commented 1 year ago
poplawskidaniel commented 1 year ago

I am facing exact same issue with Intellij and Docker and my wslg version is 1.0.51.

As previous comments I cannot find reason of that.

WSL version: 1.2.5.0 Kernel version: 5.15.90.1 WSLg version: 1.0.51 MSRDC version: 1.2.3770 Direct3D version: 1.608.2-61064218 DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp Windows version: 10.0.19045.3448