Troubleshooting Windows Subsystem For Linux (WSL)

Enabling WSL2 Support in Firewall Settings

Unlike WSL1 that shares the same IP addresses (including localhost) between Windows and Linux sides, WSL2 distros run inside separate lightweight virtual machines and cannot directly communicate to the Windows host unless explicitly enabled in firewall settings.

VisualGDB relies on the ability to communicate between the WSL target and Windows, hence in order to use WSL2 targets with VisualGDB, you would need to enable TCP/IP connections from WSL2 hosts. The easiest way to configure it is shown below:

  1. Locate PowerShell in the Start menu, right-click on it and select “Run as Administrator”.
  2. In the Administrative PowerShell Prompt run the following command:

  3. Now you can select WSL2 targets in VisualGDB dialogs and they will work out-of-the-box, just like WSL1 targets.

Troubleshooting WSL Launcher Problems

VisualGDB uses a special launcher application to run the WSL applications in their native environment and route their output back to VisualGDB. The launcher is complied from the C:\Program Files (x86)\Sysprogs\VisualGDB\TargetTools\LinuxAppLauncher.c file first time you use VisualGDB with WSL.

If the launcher does not build or start due to some reason, you can try troubleshooting it as shown below:

  1. If the launcher doesn’t build, try opening the WSL bash shell and building it manually:

    If the build fails due to missing GCC, or other errors, please fix them and run VisualGDB again.
  2. If the launcher fails to start, or VisualGDB fails to connect to it, please take the note of the command line shown by VisualGDB, e.g.:

    The tmp1234.tmp file shown in the command line contains the launch parameters for the WSL command started with the launcher. Make sure the file still exists and try running the command line manually to see if WSL fails to run the launcher due to some reason.