1

Just today bash on my Windows 10 machine has completely stopped working. Running bash from the command prompt results in about a one second pause, and then returns immediately back to the command prompt.

enter image description here

I have already tried removing and reinstalling "Windows Subsystem for Linux" from Turn Windows features on or off (several times) with associated reboots (see below):

enter image description here

What else could I possibly do to get bash working again?

--- Edit with additional information ---

Output of wsl.exe -l -v showing distributions and versions installed on my local machine:

enter image description here

For further context, the Ubuntu and Debian images were installed after I started experiencing the problem with the bash command prior to today.

2
  • @Ramhound Windows 10 version 2004 (build 19041.867)
    – Lemonseed
    Mar 15, 2021 at 0:08
  • According to Microsoft's documentation on WSL (docs.microsoft.com/en-us/windows/wsl/reference) bash remains full supported as invoked directly from the command line. There is also a list of deprecated commands at the bottom of the page.
    – Lemonseed
    Mar 15, 2021 at 1:20

1 Answer 1

1

There seem to be some deleted comments, but for clarity, Microsoft calls bash.exe a "historic command" in that page you linked to. I don't consider it "deprecated" (since, as you point out, they explicitly list deprecated commands). But "historic" is, IMHO, just one step before "deprecated." Also, the WSL/Windows Interop documentation, says "bash.exe has been replaced with wsl.exe" (emphasis added).

Anyway, the recommended way of launching is (currently) certainly through the wsl.exe command, since it provides many more options and is more robust. It's also possible for distributions such as Alpine to not even include a bash shell, so it's a bit of a misnomer anyway.

Not that bash.exe itself is likely your problem. It's just that you'll probably need the features of wsl.exe to recover.

You note that you installed the Ubuntu and Debian after this problem started happening. Does this mean that you were only running the Docker Desktop prior to this? A typical installation for WSL is to:

  • Install the WSL feature itself (along with the WSL2 kernel)
  • Install a distribution
  • Then install Docker Desktop

However, if you only had the two docker-desktop* instances, it would seem that you never installed any other distribution. This isn't really recommended. The docker-desktop instance is launchable, but I believe it is really designed for Docker Desktop's internal use (e.g. setting up the Docker sockets). I could be wrong on this ...

As to why bash.exe is no longer launching your default docker-desktop container, I'm not sure, but it's likely something to do with your bash startup configuration. When WSL exits without any error message, that's usually due to a problem inside the instance. WSL does not appear to redirect stderr back to the host, or perhaps it just needs some redirection to do so that I haven't delved into yet.

To try to find out what's going wrong inside, try launching with any of the following:

wsl -e bash --noprofile --norc # Launches without any startup profile
wsl -u root # Launches as root instead of the default user
wsl -e sh # Launches the dash shell instead of bash
wsl -u root -e sh # Same as above, but as root

If one or more of those work, then you can begin troubleshooting your startup configuration from there. If you are able to launch as root, then you can su yourusername to switch to your user. Since you are launching from inside the WSL instance, you should be able to see any error messages that could be suppressed when running from the Windows command prompt.

Ultimately, though, I'd recommend you set a different distribution as default, via:

wsl --set-default Ubuntu

You can still get back to the "docker-desktop" distribution to copy out any needed files via wsl -d docker-desktop (append any of the previously discussed options if those help you launch it without error).

1
  • Deprecating bash and replacing with an another exe, which does very much the same thing is a typical Microsoft play book. All that effort for the sake of a name, when all they needed to do was link bash.exe to wsl.exe and all this needless confusion would be prevented. The only good that's come out of it is that Bash.exe and WSL.exe can have different colors.
    – Andrew S
    Nov 15, 2022 at 15:30

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .