WSL 2 connection lost after too much time in Modern Standby

[adrianghc]

• VS Code Version: 1.47.3
• Local OS Version: Windows 10 19042.421
• Remote OS Version: Ubuntu 18.04
• Remote Extension/Connection Type: WSL

Steps to Reproduce:

1. Start WSL 2 on a device with Modern Standby, e.g. a Surface.
2. Put the device into Modern Standby for several hours, e.g. overnight.
3. Wake up the device after several hours, e.g. in the morning.

In the morning, VS Code says it's lost its connection with WSL and needs to reload the window. However, calling wsl -l -v shows that the WSL 2 VM is indeed still running.

I've written about Modern Standby specifically because I don't know if this behavior occurs with normal standby as well, but I imagine it's probably specific to Modern Standby because Windows is still active there, but not during normal standby afaik.

[Chuxel]

@aeschli Is this just another variation of challenges with reconnecting after sleep?

[jamestut]

Seems like the WSL remote extension is using TCP/IP for the connectivity to the WSL 2 container. When the system enters modern standby, Hyper-V will pause running VMs and Hyper-V-VmSwitch will "disconnect" itself from host. On a system with plenty of virtual switches, Hyper-V will sometimes takes a full minute to restore connectivity of all of those virtual switches, further exaggerating this problem.

Replacing TCP/IP sockets with the Hyper-V sockets (AF_VSOCK on the Linux side and AF_HYPERV on the Windows side) instead of the regular TCP/IP should solve this problem.

[aeschli]

Let see if increasing the timeout helps

[aeschli]

I wasn't able to reproduce the issue.

[adrianghc]

Lately I have found that this issue does not always occur, or at least it seems to happens less frequently. Perhaps something seemingly unrelated somehow mitigated this to a degree. I'll try to see if I find a pattern, and will try to get a better idea of how often it still occurs.

[jamestut]

Issue happened (much) less often if I can get Hyper-V virtual switches to wake up faster, in case of short modern standby sessions. (e.g. the typical duration of lunch break, commuting, etc.). Several ways that I can do to speed this up are:

1. Reducing the number of Windows Firewall rules.
   The Windows Firewall rules on Windows 10 can easily reach thousands of entries, because they're automatically created every time an app tries to bind and listen to a TCP/UDP port.
2. Disabling the NetSetupSvc after WSL 2 is started.
   This service is responsible for setting up the "vEthernet (WSL)", so if this service is disabled at first system boot, WSL 2 will fail to run. However, after WSL 2 has ever been started, keeping this service enable somehow causes a temporary packet loss between WSL 2 and Windows host around 1 to 2 seconds after the system wakes up from modern standby, for around 1 to 2 seconds as well. I can observe this behavior on both my Dell XPS 15 9560 and my Surface Go, both running 19041.508.

Keeping the system for an extended amount in modern standby (e.g. overnight) will almost certainly reproduce this behavior. Most of the time it will also result in VSCode asking for "reload the window" as well (like in #3126).

Therefore, I really hope that you migrate to AF_VSOCK/AF_HYPERV instead. Or perhaps, make this extension open source so I can modify it. 😁

[ninjaa]

Yeah this problem is horrible please escalate. I find myself having to restart vscode 2x to 3x daily because I do all my work in WSL remote and the reload ruins my terminal sessions with running programs. Terrible for programmer productivity.

Also for whatever stupid clearly related reason workplace settings on remote are not honored. So my windows always lose their color scheme (I use a different color scheme for each project). I'll open a second ticket for this issue but mention it because this chore of manually resetting color schemes in 6 windows wouldn't be relevant except for this super weird reload bug.

Please fix it ASAP thanks.

[jamestut]

I'd add that once WSL 2 is started, the hns service can be disabled to prevent the Hyper-V virtual switches from disconnecting when the computer enters modern standby. On my Dell XPS 15 9560, disabling this service doesn't seem to prevent the computer from entering DRIPS either.

The only downside is that if we stop the WSL 2 (e.g. by logging off or running wsl --shutdown), it won't be able to start. In that case, to restart WSL 2 without rebooting the computer, we can take the following steps in order:

1. Stop the LxssManager service.
2. Enable and start the hns service.
3. Start the WSL 2 using the regular means.
4. Stop and disable the hns service.

Had done this in the last 4 days and no more reconnecting / "please reload window" after resuming from modern standby, even when the modern standby lasted overnight. It now works flawlessly as it should. But I have to stress again, this is just a hack, and there should be no reason for VSCode not to use AF_HYPERV/AF_VSOCK.

Also to Hyper-V team (where I can file this to them by the way?), there should be no reason why would you disconnect the virtual switches when the computer enters modern standby. I didn't find any single issue so far, even with regular Hyper-V VMs. Both the default NAT network and bridged networks works flawlessly as well with the hns service disabled after I've started at least one VM that uses the virtual switches.