wslg: (1.0.55 pre-release) Changing network causes all WSL windows to disappear

@fargiolas and all, thanks for helping us to address this issue. We are going to address this issue in two ways.

1: At first, the remote desktop connection to WSLg/Linux VM should not be disconnected when Windows host’s network configuration is changed. I already made a fix to remote desktop client software (msrdc.exe or its variant), so WSLg window will no longer disappear from desktop at network change, and this is what it ideally should be. The fix is already in pipe, but because this is external component (from WSLg’s aspect), it will be for a while to be integrated to WSL release.

2: Second, in case RDP connection is dropped for whatever reasons (like @fargiolas kills msrdc process from task manager), it still should restore properly. At this point, I think this could possibly be an issue in GDK framework. From wayland perspective, when RDP connection is dropped and restored, it appears as wl_seat is gone then recreated. I think this might be an unlikely event in normal Linux desktop environment, thus there might be some missing piece, and this is why Wayland reference app, such as weston-editor, works properly, but this is just my speculation at this point, and further investigation is still required, thanks!

GTK bug for wl_seats handling: https://gitlab.gnome.org/GNOME/gtk/-/issues/6335

Hi, Yes, the new version of wsl restarts the RDP connection. However, xfce4-terminal which is based on GTK loses input channel, and konsole whic his based on QT after several cycles looses clipboard integration. It seems like most of the wayland application did not QA the seat re-connection. I am waiting for the RDP fix so that RDP will not drop connection when network change occurs, not sure why a network change as global causes RDP to drop connections to networks that are available. Regards,

Same for me as for @alonbl, but with emacs in pgtk version. If I understand correctly, pgtk emacs runs purely on top of wayland. It just completely unresponsive when reappears. Opening new windows doesn’t make it responsive, new emacs windows are unresponsive too it doesn matter client window or standalone. Complete restart of all emacs instances including server helps. It could just be emacs bug actually…

I found a way around this by recompiling emacs with lucid. Now when the window reappears it is responsive. Just starting testing this so I don’t know what other consequences may there be in using lucid instead of gtk though.

I have the same issue. As a workaround I run xclock from the terminal, then my disappeared windows appear again.

Welp, it was the only relevant command I found in my history so I assumed it must have been how I did it. Clearly that’s not the case then. Based on my recollection, the only other way I could have achieved it is by simply downgrading WSL with the latest stable msixbundle from WSL repository (https://github.com/microsoft/WSL/releases/tag/1.2.5). Once downloaded, you just have to open it, confirm that you want to downgrade in the MS Store prompt and wait for it to complete. I am not certain there are no risks associated with this but it did seem to work just fine in testing.

Hello,

Pre-release 2.2.4.0 seems to solve the network change event that triggers restart of RDP session, no restarts wayland applications continue to run as usual.

However, Windows sleep still triggers restart of RDP session, which means that this issue is still not fully resolved as within a valid lifetime of a valid user experience there may be network change, sleep or hibernate events.

Regards,

PS C:\Users\gpettey> wsl --version
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

Today I noticed that starting another application in WSlg (e.g. gvim) restores all my windows that disappeared after a network change.

@fargiolas, this is very helpful and interesting clue, if you switch the focus to that window by ALT+TAB (not by mouse), and type in something with keyboard, is the input delivered to application? And do see you the wayland application window is moved/changed before/after disappearance? thanks!

@hideyukn88 thanks, I’ll get back with the version information as soon as I can.

Please note that while the wayland app disappears and when it gets back it’s not stuck or frozen, it’s still running fine. You can still see it updating the window just fine if it was running something. The problem seems more that it’s not receiving user input (keyboard and mouse events) anymore.

@hideyukn88 thanks, I’ll get back with the version information as soon as I can.

Please note that while the wayland app disappears and when it gets back it’s not stuck or frozen, it’s still running fine. You can still see it updating the window just fine if it was running something. The problem seems more that it’s not receiving user input (keyboard and mouse events) anymore.

WOW! This is truly annoying, no way to rollback and every change in network I must reopen all my windows. Is there anyone from Microsoft on this thread?

still happens with 2.0.4. I thought the new wslinfo command might get some insights but alas it just tells me that i use nat which i knew beforehand 😃

still happens to me with

WSL: 2.0.0.0
WSLg: 1.0.57

actually to me it looks like https://github.com/microsoft/wslg/issues/1108

Restarting WSL using WSL --shutdown and then opening a new window doesn’t fix it? I know that fixes issues around external drives not being available for use if they were ejected at any point during the life of WSL , so it’s worth a shot

it’s more like if you start another window/gui application, all disappeared windows appear, but my emacs-client windows remains unresponsive though. Killing and restarting it works, but it’s annoying, I’m losing my open buffers etc literally after every sleep.

Restarting WSL using WSL --shutdown and then opening a new window doesn’t fix it?

Sure, so does killing the individual GUI processes inside the running WSL instance and just opening them again but it shouldn’t be happening in the first place, especially considering that this used not to be a problem.

agree. It’s kind of basic scenario of use (does MS perform any testing though 😄 )

Restarting WSL using WSL --shutdown and then opening a new window doesn’t fix it?

Sure, so does killing the individual GUI processes inside the running WSL instance and just opening them again but it shouldn’t be happening in the first place, especially considering that this used not to be a problem.