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

[Jackenmen]

Windows build number:

10.0.19045.3086, I was able to reproduce it on 10.0.22621.1992 as well

Your Distribution version:

22.04

Your WSL versions:

WSL version: 1.3.14.0 Kernel version: 5.15.90.3-1 WSLg version: 1.0.55 MSRDC version: 1.2.4419 Direct3D version: 1.608.2-61064218 DXCore version: 10.0.25880.1000-230602-1350.main Windows version: 10.0.19045.3086

Steps to reproduce:

1. Install the latest WSL pre-release (1.3.14 bundling WSLg 1.0.55 at the time of writing)
2. Start any GUI application (in my repro, I'm running xclock -update 1 command from Windows Terminal but this seems to be reproducible with any app - I noticed it with Sublime Text 4 and kitty too; no matter if the app is set to use X11 or Wayland)
3. Disconnect from Wi-Fi or, if you're using Ethernet card, disable the network adapter that connects you to the Internet in Control Panel.
4. See that all Linux app windows disappear once the connection is stopped.

WSL logs:

WslLogs-2023-07-31_18-43-52.zip stderr.log wlog.log pulseaudio.log weston.log

WSL dumps:

No files are available in the /mnt/wslg/dumps directory.

Expected behavior:

I expect the windows of Linux apps to still be visible after I disconnect from the network.

Actual behavior:

All windows of the Linux apps disappear.

[Jackenmen]

It's possible that this is a WSL issue rather than WSLg's - while on my personal PC I was only able to see any difference with GUI apps, on my company laptop I noticed that there's also a different networking change (that does not apply to my personal setup where I don't use any VPNs) done when WSL detects proxy change (i.e. when I connect to company VPN) - it adds http_proxy env var and it shows notification that WSL should be restarted for network changes to apply (both of which I would actually really love to disable since I already have a working setup using redsocks which doesn't require me to set any env vars or to restart WSL).

Since my main issue is with the GUI apps disappearing on me and since everything else does work fine on my personal PC, I figured it makes more sense to create the issue here (and perhaps file another one for the proxy stuff on the main repo later).

[g2flyer]

I see the same issue (i've reported this in the release discussion, see https://github.com/microsoft/WSL/discussions/10302#discussioncomment-6504163, but i guess opening an issue is the better approach)

[Jackenmen]

Welp, GitHub searched has failed me, I did look for a release discussion at some point before pinpointing what the issue is. But yeah I guess making a tracking issue for this isn't a bad idea anyway 😄

apparently I searched for "1.3" and for "1.3.10" and wrongly assumed that pre-releases probably don't have release discussions associated with them

[g2flyer]

same behavior of closing windows still happens with releases 1.3.15 and 1.3.17 ..

[DmitryGrayscale]

just noticed that after sleep my wifi interfaces were gone (blank list, smth with device probably), emacs window was available. Once it finally scanned wifi networks and reconnected to my home wifi, emacs windows disappeared. I have simillar errors in wlog.log as issue reporter:

[13:40:43:339] [11:11] [ERROR][com.freerdp.core.transport] - BIO_read returned a system error 11: Resource temporarily unavailable
[13:40:43:343] [11:11] [ERROR][com.freerdp.core] - transport_read_layer:freerdp_set_last_error_ex ERRCONNECT_CONNECT_TRANSPORT_FAILED [0x0002000D]
[13:40:43:367] [11:11] [ERROR][com.freerdp.core.transport] - BIO_should_retry returned a system error 32: Broken pipe
[13:40:43:367] [11:11] [ERROR][com.freerdp.core.transport] - BIO_should_retry returned a system error 32: Broken pipe
[13:40:43:367] [11:11] [ERROR][com.freerdp.core.transport] - BIO_should_retry returned a system error 32: Broken pipe
[13:40:43:367] [11:11] [ERROR][com.freerdp.core.transport] - BIO_should_retry returned a system error 32: Broken pipe
[13:40:43:367] [11:11] [ERROR][com.freerdp.core.transport] - BIO_should_retry returned a system error 32: Broken pipe
[13:40:44:469] [11:11] [ERROR][com.freerdp.core.transport] - BIO_should_retry returned a system error 32: Broken pipe
[13:40:44:469] [11:11] [ERROR][com.freerdp.core.transport] - BIO_should_retry returned a system error 32: Broken pipe

any way to do rollback without losing my distro?

[Masamune3210]

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

[Jackenmen]

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.

[DmitryGrayscale]

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 :D )

[Masamune3210]

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.

I am aware and at no point did I say that it was a fix for the issue or anything more than a stopgap. The question was is there any way to fix it without losing the distro, which made it sound like they were just never coming back instead of only being temporarily unavailable.

[Jackuczys]

The question was is there any way to fix it without losing the distro, which made it sound like they were just never coming back instead of only being temporarily unavailable.

Ah, you were referring to the question. My belief is that the question was actually asking whether there is a way to rollback to an older (non-prerelease) version of WSL and to answer that - yes, there is. I believe wsl --update --rollback should work, that's what I did when running into this issue to confirm that it's in fact a new problem.

[DmitryGrayscale]

The question was is there any way to fix it without losing the distro, which made it sound like they were just never coming back instead of only being temporarily unavailable.

Ah, you were referring to the question. My belief is that the question was actually asking whether there is a way to rollback to an older (non-prerelease) version of WSL and to answer that - yes, there is. I believe wsl --update --rollback should work, that's what I did when running into this issue to confirm that it's in fact a new problem.

thanks! tried wsl --update --rollback before asking, there is no --rolback parameter on my instance for some reason:

it just prints help instead of rolling version back 🤔

[Jackuczys]

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.

[DmitryGrayscale]

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

[g2flyer]

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 :-)

[DmitryGrayscale]

Weird thing that I tested it with emacs client window and xfce4-terminal, emacs disappears after network change and reappears after opening another frame but unresponsive. Xfce4-terminal doesn't disappear and responsive

[g2flyer]

I primarily use (ubuntu 22.04's standard) emacs where i get the disappearing-window problem but quick experimentation shows also same behavior's with new pgtk emacs 29 or newer, xterm, gnome-text-editor and, contrary to Dmitry's experience, also with xfce4-terminal. Also, starting a new xapp usually makes them all re-appear ~and being responsive~. Contrary to what i thought, though, only standard emacs is responsive but not the other ones.

The caveat "usually" is that sometimes when the network dis/reconnects is due to a hibernation, then the xapps die (which seems due to that wslg/x-server dies and while automatically restarted obviously doesn't "inherit" the apps running at crash time ...)

[alonbl]

Started to happen to me as well today.

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.2428

[Jackenmen]

Darn, did MS release WSL2 2.0 to stable channel without fixing this? :/

[alonbl]

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?

[alonbl]

OK, I give up, I was perfectly happy with WSL, except from two events that completely broke it:

• suspend/resume regression due to Microsoft fix[1], which was resolved for Windows 11 22H2 and not for earlier versions
• this one which is a regression, but I cannot find the root cause.

@Jackenmen please modify title to allow people find this issue, something like: "X applications stop responding when Windows network is modified"

I truly want to avoid installing xserver.

[1] https://github.com/microsoft/WSL/issues/6982

[Jackenmen]

please modify title to allow people find this issue, something like: "X applications stop responding when Windows network is modified"

That sounds more like #1108. The underlying cause may be the same but @hideyukn88 (maintainer of this project) wanted to keep those separate so I imagine changing the title in this way here would work against that. More so, this is NOT limited to X applications and affects Wayland as well - this was already noted in the original issue description.

[rowleya]

I can add that I don't think the issues are the same. I get this behaviour and thought it was hibernate / standby / restore related but was on a train today and had an eclipse window disappear on me when the network dropped. Just re-running eclipse brings the original window back fully working (it also tries to start a new eclipse which fails as it is already using the workspace).

Every now and again it also doesn't reconnect, and I have to kill it and restart it, but it is rare enough for me to not be too worried about that.

I think that this is something to do with the MSRDC connection breaking when the network changes. I don't know then if this means that the connection is made via the wrong IP address. I also don't know how this would be controlled...

[pfz]

Sorry I didn't report this earlier, but I found on Monday that when all windows are gone, I just have to start a new xterm from bash (the most simple Wslg program I can think of), and everything pops up back. Some glitches but by clicking and wait that all event handlers reconnect, everything goes back to normal in 2 or 3 seconds. I use Jetbrains' PhpStorm with at least 3 windows open. It was a real pain as many services attached had to be killed/restarted before I found this by accident.

Hope it works for you, while this bug is fixed. I saved my days.

[alonbl]

yes, I am aware if that except that xfce4-terminal pops up and is unresponsive and it is my main tool.

[fargiolas]

@hideyukn88 any insight about this issue? It's very easy to reproduce, just open a wslg app and disconnect from the Windows network, see the window disappear. You get a [07:40:23.894] <5>WSLGd: Run:108: pid 1289 exited with status 0 in stderr.log and a bunch of errors in wlog.log like:

[07:40:33:874] [579:579] [ERROR][com.freerdp.core.transport] - BIO_read returned a system error 11: Resource temporarily unavailable
[07:40:33:874] [579:579] [ERROR][com.freerdp.core] - transport_read_layer:freerdp_set_last_error_ex ERRCONNECT_CONNECT_TRANSPORT_FAILED [0x0002000D]
[07:40:33:875] [579:579] [ERROR][com.freerdp.core.transport] - BIO_should_retry returned a system error 32: Broken pipe
[07:40:33:875] [579:579] [ERROR][com.freerdp.core.transport] - BIO_should_retry returned a system error 32: Broken pipe
[07:40:33:875] [579:579] [ERROR][com.freerdp.core.transport] - BIO_should_retry returned a system error 32: Broken pipe
[07:40:33:875] [579:579] [ERROR][com.freerdp.core.transport] - BIO_should_retry returned a system error 32: Broken pipe

It seems the rdp client is restarted and the new one isn't able to manage the old windows. I'd say #1098 is the very same issue, a network change caused by going to sleep which leads to the same problem. But this is more easy to trigger and debug.

[martin-rueegg]

Disabling the WiFi-Adapter causes the windows to disappear. While re-enabling the adapter, the WSL's vEthernet adapter and teh vEthernet default switch seem to "disconnect" their "cable" ...

https://github.com/microsoft/wslg/assets/6409516/46f80042-be44-4cbe-9938-c64a5ff77aad

Interestingly, disabling not consistently causes the windows to disappear. But I could not determine what makes them stay.

[someguynamedmatt]

Commenting to add to the noise (as well as follow), but this is happening to me whenever the network interface: a) sleeps, or b) changes (specifically, connecting to a VPN).

I don't necessarily mind reopening Emacs, but as @DmitryGrayscale pointed out, it's incredibly frustrating to lose open buffers when I'm knee-deep in a days-long bug hunting process.

[sppearson]

This gets terrifically frustrating, especially given how inconsistent it is for me. Generally a network change will "disappear" my XWayland windows -- but not always. Sometimes running any simple X application (e.g., xeyes) will restore them, but sometimes neither the vanished windows nor that new app will display (though the all of processes are there, and logging -- at least on the Linux side of things -- indicates nothing unusual). If the behavior was consistent, it'd at least be a heckuva lot easier to work around.

[burak-58]

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

[rowleya]

I agree that running an x application after the windows disappear seems to mostly bring them back. I have also seen an application stop when the networking changes (most often on restore from hibernate); a guess is that that application does something graphical while the GUI is gone and causes a crash somehow.

It used to be possible to hibernate and resume without losing windows so something has changed. A possible place that could have changed though is Hyper-V... maybe this has changed what happens when network cables are disconnected?

Ideally since I can do this manually something would reconnect when it disconnects, and then the problem would likely be solved...

[alonbl]

Dear @Microsoft Representative, Please review and merge #1108, #1092, #1098 bugs. Please acknowledge you accept the issue and working on a solution. Please tell us if you require any missing information from us users to make a progress. WSL is unusable when every network change/sleep/hibernate all applications need to be reopened. Forgive me that I am pasting this to all bugs, I do not know which if any you monitor. Thanks,

[jruhe-adesso]

This is a really annoying and frustrating issue.

WSL-Version: 2.0.14.0 Kernelversion: 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

Changing MESA_D3D12_DEFAULT_ADAPTER_NAME has not effect on this issue.

[hideyukn88]

@alonbl, @fargiolas, @burak-58 and all, thanks for keep updating us. We acknowledge the issue and are investigating the possible solutions. Basically, this occurs when remote desktop connection between Windows and WSL lost by network configuration change, but there are 2 different outcomes. When RDP connection is lost, the remote desktop client software (msrdc.exe) running on Windows terminates, and WSL auto-restart it. First issue is, the auto-restart itself is successfully done, but old windows are not restored. As @burak-58 reported, in this case, by opening another window should restore all other window. This is somewhat easy-fix, and hopefully we can address soon. The second issue more complex one, in this case the successively launched msrdc fails to establish the connection with WSLg, this ends up the log reported by @fargiolas. We have multiple reports of this symptom, including the case from sleep/hibernate, and this is most likely beyond WSLg scope and by some issue from WSL/Windows network integration layer. Unfortunately, I personally don't have local repro for this, thus it's possible some unique configuration might be required. @fargiolas, just for reference, if you perform some network operation between WSL and Windows, what would happen to them, for example, copying large file between WSL and Windows, then disconnect Windows network? Does the copy fail or keep going? Anyway, this is where we are on this issue, thanks!

[alonbl]

Hello @hideyukn88,

Thank you so much for confirming this.

I have 100% reproducible of xfce4-terminal window lost when network change, and is restored when opening a new window (for example another xfce4-terminal), it is shown but unresponsive. In the new xfce4-terminal I can kill the previous one using kill command to get rid of the unresponsive window.

I can provide any data you need to help resolve the issue, please tell me what to collect.

Thanks,

[hideyukn88]

@alonbl, I just tried xfce4-terminal and it looks working fine after window is restored. In my end, it works as wayland-native (not X11), is it to you as well? If so, how about other wayland-native app, will it be unresponsive too? thanks!

[DmitryGrayscale]

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...

[alonbl]

Hello @hideyukn88,

Thank you for checking this out. xterm for example is resumed correctly. xfce4-terminal is not, if I strace the process of the window that is reappear I get poll wakeup events when focus and mouse click but the window itself is not responding.

Some information we compare:

DISTRIB_DESCRIPTION="Ubuntu 22.04.3 LTS"
xfce4-terminal 0.8.10 (Xfce 4.16)
XWAYLAND1 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 0mm x 0mm

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.22621.2715

WSLg ( x86_64 ): 1.0.59+Branch.main.Sha.2bffa4a1867601b1fd0e3c7bb59ada9f6131c28e
Mariner: VERSION="2.0.20230630"
DirectX-Headers:
mesa:
pulseaudio: 6f045ff0dca233a939a2aba815f84d177e294122
FreeRDP: c4030980b29322a9cb2190711a5fadeeeb8b6a33
weston: 1c19fc5ecdd4552f36f77256e1fb53225801aff0

/mnt/wslg/stderr.log:

[22:54:56.080] <5>WSLGd: Run:108: pid 1242 exited with status 0, /init /mnt/c/Program Files/WSL/msrdc.exe msrdc.exe /v:8BA75DC0-97EE-4012-A17E-AB94CB7D55F8 /hvsocketserviceid:362A0DB8-FACB-11E6-BD58-64006A7986D3 /silent /wslg /plugin:WSLDVC_PACKAGE /wslgsharedmemorypath:WSL\8BA75DC0-97EE-4012-A17E-AB94CB7D55F8\wslg C:\Program Files\WSL\wslg.rdp
Error: debug scope named 'rdp-audio' is already registered.
Error: debug scope named 'rdp-audio-in' is already registered.
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

/mnt/wslg/weston.log:

[22:56:57.543] unable to checkDescriptor for 0x557c03b43210
[22:56:57.657] app_list_monitor_thread: stopRdpNotifyEvent is signalled. 1
[22:56:57.657] rdp_rail_notify_app_list(): rdp_peer 0x557c03b40df0
[22:56:57.657]     inSync: 0
[22:56:57.657]     syncStart: 0
[22:56:57.657]     syncEnd: 0
[22:56:57.657]     newAppId: 0
[22:56:57.657]     deleteAppId: 0
[22:56:57.657]     deleteAppProvider: 1
[22:56:57.657]     associateWindowId: 0
[22:56:57.657]     appId: (null)
[22:56:57.657]     appGroup: (null)
[22:56:57.657]     appExecPath: (null)
[22:56:57.657]     appWorkingDir: (null)
[22:56:57.657]     appDesc: (null)
[22:56:57.657]     appIcon: (nil)
[22:56:57.657]     appProvider: Ubuntu-22.04
[22:56:57.657]     appWindowId: 0x0
[22:56:58.620] Client: ClientStatus:0x3f5
[22:56:58.620]      - TS_RAIL_CLIENTSTATUS_ALLOWLOCALMOVESIZE
[22:56:58.620]      - TS_RAIL_CLIENTSTATUS_ZORDER_SYNC
[22:56:58.620]      - TS_RAIL_CLIENTSTATUS_WINDOW_RESIZE_MARGIN_SUPPORTED
[22:56:58.620]      - TS_RAIL_CLIENTSTATUS_HIGH_DPI_ICONS_SUPPORTED
[22:56:58.620]      - TS_RAIL_CLIENTSTATUS_APPBAR_REMOTING_SUPPORTED
[22:56:58.620]      - TS_RAIL_CLIENTSTATUS_POWER_DISPLAY_REQUEST_SUPPORTED
[22:56:58.620]      - TS_RAIL_CLIENTSTATUS_GET_APPID_RESPONSE_EX_SUPPORTED
[22:56:58.620]      - TS_RAIL_CLIENTSTATUS_BIDIRECTIONAL_CLOAK_SUPPORTED
[22:56:58.620] Client HandShake buildNumber:22621
[22:56:58.630] Server AppList caps version:4
[22:56:58.630]     appListProviderName:Ubuntu-22.04
[22:56:58.630]     appListProviderUniqueId:362A0DB8-FACB-11E6-BD58-64006A7986D3
[22:56:58.661] Client: gfxredir_caps: length:28
<snip>

If you have a specific application or configuration you want to test please write to me and I will test, I mostly use the xfce4-terminal as wslg application.

Regards,

[fargiolas]

@hideyukn88 thank you for looking into this and for the very welcome feedback! sad to hear my side of the issue is the trickiest one. It could totally be something specific with my setup, lots of factors I cannot exclude like company firewall/proxy/vpn. But it used to work pretty fine, seems it has something to do with the new WSL networking features, which I'm not using, that were introduced in 2.x.

I tried copying a big file from windows to linux over 9p and disconnecting wifi in between. No issue, file transfer keeps going without any error.

One thing I noticed that may help you to reproduce the issue is that both native wayland (emacs compiled with pgtk in my case) and XWayland (tested with xterm) apps disappear. When I launch a new graphical app both come back but while I can interact with xterm the native wayland app becomes unresponsive/stops to receive input events.

Let me know if I can be of any further help, feel free to contact me by mail if you want more direct feedback.

[hideyukn88]

@fargiolas, to rule out your environmental changes, if you don't mind, would you please install older version of WSL and find out which WSL version does not exhibit the issue? You can install older version of WSL from https://github.com/microsoft/WSL/releases. (you do not need to try the release marked as "pre-release"). If you can find which release works and then from which release doesn't work, then we could find some clue from the differences, and it would help us a lot. Installing/uninstalling older WSL (as long as released version) should not impact your Linux distro configuration, but just for disclaimer, there could be possibility it might cause some negative impact to your installation, if you have another backup system to try, that could be safer, thanks!

[milan-melena]

Hello, I have the same issue - unresponsive graphical app after network change/sleep. In my case, the last WSL version which works without problem is:

Verze WSL: 1.3.11.0 Verze jádra: 5.15.90.2-3 Verze WSLg: 1.0.54 Verze MSRDC: 1.2.4240 Verze Direct3D: 1.608.2-61064218 Verze DXCore: 10.0.25880.1000-230602-1350.main Verze Windows: 10.0.22000.2538

[hideyukn88]

@milan-melena, thanks for info, what apps do exhibit the issue? thanks!

[milan-melena]

At least emacs compiled --with-pgtk. I'm not sure if I tried something else.

[DmitryGrayscale]

Same issue(unresponsive after recover) with gnome-terminal (ubuntu 22.04 flavor), not only with pgtk emacs. Probably every Wayland (not xwayland) app affected

[hideyukn88]

@DmitryGrayscale, @milan-melena, while that apps remain unresponsive, can another wayland app be started and does that new one work correctly? thanks!

[milan-melena]

yes, another wayland app can be started and works correctly.

[hideyukn88]

@milan-melena, would you please take strace log? if you can try with xfce4-terminal, then strace xfce4-terminal. If gnome-terminal, then you launch it first, then find PID of gnome-terminal-server, then strace -p <PID>, then change network configuration, then launch xclock to restore window, hopefully it shows which system call stuck it, thanks!

[fargiolas]

@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.

[milan-melena]

@hideyukn88, I apologize, but I currently do not have WSL with the error installed. Right now, I don't have much free time for reinstallation and experiments. Perhaps someone else with the erroneous version of WSL can retrieve a strace log.

[alonbl]

@hideyukn88,

I wounder why you ask this from someone specific, so far I provided you with all the information so far for this specific issue, please bear with me so that you have a single vector of problem determination.

Attach is the strace log[1].

Please see marker @ALONBL: CHANGE NETWORK when change network and @ALONBL: RESTORE when I run xterm to re-show windows, during which and until @ALONBL: UNRESPONSIVE TO USER no user response from user although there is activity, then I kill the process.

Versions were attached at [2]

Regards,

[1] xfce.log [2] https://github.com/microsoft/wslg/issues/1092#issuecomment-1861629048

[hideyukn88]

@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.