Solution to Visual Studio Code “Reconnecting” Problem on WSL 2

by

Background

The Windows Subsystem for Linux (WSL) is a Windows 10’s feature that allows most native, unmodified Linux programs to run in Windows 10. This technology is based on the picoprocess technology from Project Drawbridge research. Version 2 of the WSL however, emulates the original WSL by running the supplied Linux binaries inside a highly optimized Hyper-V partition, running an actual Linux kernel, which not only improves compatibility but also drastically improves file I/O performance as well. However, being a Hyper-V partition, it shares the usual means to communicate with the host: it uses vhdx file to store the rootfs, Hyper-V virtual switches for network communications, and Hyper-V VMBus for the rest of the integration features.

In Windows 10 version 2004 or 20H2, there is a particular problem with the Hyper-V virtual switches that cause those virtual switches hardware to be removed (not just disconnected, but is actually removed) every time the computer goes into standby, both in the traditional S3 standby mode as well as the modern standby. The virtual switches are restored back once the system woke up, however, this restoration takes time as the virtual switch drivers have to be reinitialized and the IP addresses have to be renegotiated by the DHCP server.

The above behavior causes problems to many applications connected to the WSL 2 instance via TCP/IP when the computer entered the standby mode, since it is equivalent to abruptly yanking the ethernet cable, and that includes the Visual Studio Code with WSL remote extension. You might notice that most of the time, Visual Studio Code tries to reconnect to the WSL 2 instance after the computer wakes up, and often fail to reconnect and you are forced to reload the window.

Solution

Turns out that the service responsible for the virtual switches removal is also the one that sets them up: the hns (Host Network Service) service. Stopping and disabling this service straight away solved this problem, at least on a Windows PC with modern standby. Disabling this service also does not impede the ability to create and manage the Hyper-V virtual switches once they are all set up.

However, disabling this service early on will certainly cause the virtual switches to not be set up, as well as the failure to start a WSL 2 instance. In this condition, to start the WSL 2, no reboot is required! Instead, the following steps can be performed to restore WSL 2 in the exact order:

  1. Stop the LxssManager service.
  2. Enable and start the hns service.
  3. Start the WSL 2 instance, e.g. by launching wsl.
  4. The hns service can now be stopped and disabled again.

For convenience, this following script (save to a .bat file and run as elevated) can be used to do all the 4 steps above:

net stop LxssManager
sc config hns start= auto
net start hns

REM (replace the line below if your default WSL distro is not WSL 2)
wsl false

net stop hns
sc config hns start= disabled

Also please note that I have not evaluated the impact of disabling the hns service on systems with regular S3 standby. This also might impact the ability of your device to enter the DRIPS mode. However, both my Dell XPS 15 9560 and my Surface Go can still go to DRIPS successfully with this tweak.

Leave a Comment