wsltty won't load WSL Ubuntu, but it loads from CMD.EXE

[Raven-Singularity]

After being driven crazy by persistent bugs in several different terminal apps (including the two official Microsoft ones), I had hoped that mintty would be a simple and bug free experience -- and it has been for the past few months. But today for no apparent reason, it stopped loading. I booted my Windows 10 yesterday and launched my WSL Ubuntu and loaded my local web server. When I woke up today, I noticed my local web server wasn't running. Tried loading Ubuntu from my usual desktop shortcut, but it closed instantly.

I tried opening a CMD.EXE terminal, then ran bash, which launched my Ubuntu without issues.

I exited out of Ubuntu and in the same CMD.EXE terminal, went to my custom portable wsltty install folder and ran this command:

bin\mintty.exe -w Max --hold=Always --Title="Ubuntu Terminal" --configdir=. --icon=Ubuntu.ico --WSL= -

That gave me the following error:

/bin/wslbridge2: Exit 1.

I don't know much about wslbridge2, but I guess it's part of mintty/wsltty as I see it in the bin folder.

Then I got the idea that because bash ran fine from a CMD.EXE terminal, that I would just load up mintty.exe terminal with bash command.

bin\mintty.exe -w Max --hold=always --Title="Ubuntu Terminal" --configdir=. --icon=Ubuntu.ico bash

Which gives the following error:

stty: 'standard input': Inappropriate ioctl for device

When I run this:

bin\mintty.exe --version

It outputs:

mintty 3.7.1 (x86_64-pc-cygwin) -- wsltty 3.7.1

When I directly run wslbridge2.exe it outputs:

ERROR: GetVmId:312: CreateLxProcess: A null reference pointer was passed to the stub.

---

How can I debug why my mintty/wsltty won't launch my WSL2 Ubuntu Bash?

I can try rebooting or reinstalling/updating wsltty to see if that helps, but I would like to know why it spontaneously self-destructed while I slept.

[rluetzner]

I'm pretty sure I just ran into the very same issue. My wsltty keeps crashing whenever I open it. I've already updated to the latest version 3.7.4, but it doesn't change anything.

[Raven-Singularity]

I have updated to wsltty release 3.7.4 portable (keeping only my old config file), and also rebooted Windows 10, but the problem persists.

bin\mintty.exe -w Max --hold=Always --Title="Ubuntu Terminal" --configdir=. --icon=Ubuntu.ico --WSL= -

Produces this output:

I notice in this output that it says /bin/wslbridge2 and not wslbridge2.exe, so I decided to investigate that file on my Ubuntu Bash, but it doesn't exist inside my Ubuntu. There are a few files matching /bin/wsl*, but they are all Microsoft WSL scripts.

Is the file /bin/wslbridge2 supposed to be inside my WSL2 Ubuntu?

[exeral]

same for me.

when I run from CMD C:\Users\username> C:\Users\usernameq\AppData\Local\wsltty\bin\mintty.exe

mintty open, with an error: /bin/bash: Exit 126. Failed to run '/bin/bash': No such file or directory

I have already tried to reinstall mintty

when I run "wsl" command from CMD, it works well

[Raven-Singularity]

same for me.

when I run from CMD C:\Users\username> C:\Users\usernameq\AppData\Local\wsltty\bin\mintty.exe

mintty open, with an error: /bin/bash: Exit 126. Failed to run '/bin/bash': No such file or directory

I have already tried to reinstall mintty

when I run "wsl" command from CMD, it works well

@exeral:

Normally you run the shortcuts that wsltty provides, which adds some extra parameters to the mintty.exe command line.

What output do you get if you run these two commands in your CMD window:

CD /D C:\Users\usernameq\AppData\Local\wsltty\
bin\mintty.exe -w Max --hold=Always --WSL=

[xuefer]

same for me. when I run from CMD C:\Users\username> C:\Users\usernameq\AppData\Local\wsltty\bin\mintty.exe mintty open, with an error: /bin/bash: Exit 126. Failed to run '/bin/bash': No such file or directory I have already tried to reinstall mintty when I run "wsl" command from CMD, it works well

@exeral:

Normally you run the shortcuts that wsltty provides, which adds some extra parameters to the mintty.exe command line.

What output do you get if you run these two commands in your CMD window:

CD /D C:\Users\usernameq\AppData\Local\wsltty\
bin\mintty.exe -w Max --hold=Always --WSL=

I tends to copy and modify existing shortcut, right click, properties, add --hold=Always to the arguments. however there is a message get clear right before /bin/wslbridge2: Exit 1., i suppose it was ERROR: GetVmId:312: CreateLxProcess: A null reference pointer was passed to the stub. like the OP fist reporter said

[exeral]

with the shortcut parameters and adding the "always" option, I get the same error as you

/bin/wslbridge2: Exit 1.
 stub.

mintty 3.7.4

C:\Users\username>wsl --version Version WSL : 2.3.24.0 Version du noyau : 5.15.153.1-2 Version WSLg : 1.0.65 Version MSRDC : 1.2.5620 Version direct3D : 1.611.1-81528511 Version de DXCore : 10.0.26100.1-240331-1435.ge-release Version de Windows : 10.0.22631.4169

[Raven-Singularity]

Adding my own version info for Windows and WSL:

# wsl --version

WSL version: 2.3.24.0
Kernel version: 5.15.153.1-2
WSLg version: 1.0.65
MSRDC version: 1.2.5620
Direct3D version: 1.611.1-81528511
DXCore version: 10.0.26100.1-240331-1435.ge-release
Windows version: 10.0.19045.4894

@exeral: The only difference between our versions is my Windows is version 10.0.19045.4894 and yours is 10.0.22631.4169. Seems to just be a Windows 10 issue.

@rluetzner @xuefer: Can you post your wsl --version output as well?

[ypnos]

I also have the problem with Windows-Version: 10.0.19045.4894 and everything also being the same as for you @Raven-Singularity

My wsltty worked just fine until the most recent Windows update.

PS C:\Projects\scoop\apps\wsltty\3.7.4\bin> .\wslbridge2.exe -ls
Backend CommandLine: "C:\WINDOWS\System32\wsl.exe" /bin/sh -c 'exec "$(wslpath -u '\''C:\Projects\scoop\apps\wsltty\3.7.4\bin\wslbridge2-backend'\'')" --login -x'
ERROR: GetVmId:312: CreateLxProcess: An den Stub wurde ein Nullzeiger übergeben.

[Raven-Singularity]

I saw that there was a wslbridge github page, and it shows the last update from 2023. I tried that version in case it was different/older than the version shipped with wsltty. It produced the same error.

Should I be posting this bug report to the wslbridge2 project here?

https://github.com/Biswa96/wslbridge2

@ypnos: Do you happen to know what Windows Update broke things?

I'm not sure how to check Windows Update install history on my computer.

[rluetzner]

Can you post your wsl --version output as well?

Here you go @Raven-Singularity .

C:\Users\roberts>wsl --version
WSL-Version: 2.3.24.0
Kernelversion: 5.15.153.1-2
WSLg-Version: 1.0.65
MSRDC-Version: 1.2.5620
Direct3D-Version: 1.611.1-81528511
DXCore-Version: 10.0.26100.1-240331-1435.ge-release
Windows-Version: 10.0.19042.2965

[Raven-Singularity]

The wslbridge2 error I get mentions VM ID:

ERROR: GetVmId:312: CreateLxProcess: A null reference pointer was passed to the stub.

And looking at the wslbridge2 page I see this under the "CAVEATS" section:

There is no documented way to get VM ID of running WSL2 utility VM. See this https://github.com/microsoft/WSL/issues/4131. Hence GetVmId.cpp will change in future Windows 10 releases due to usage of undocumented COM methods.

Maybe those "undocumented COM methods" were updated by Windows, and now it can't get the ID.

[exeral]

with wsl --set-version Ubuntu 1 I was able to get it working again. but that's not a good solution for me

[Raven-Singularity]

I went and searched for recent Windows Updates for my version of Windows 10, and found this update (KB5043131) from September 24th, 2024:

https://support.microsoft.com/en-us/topic/september-24-2024-kb5043131-os-build-19045-4957-preview-2d4a5c54-ac58-4bdb-8685-57d578650e5f

When I looked for my installed Windows Updates, I discovered that update isn't installed. My most recent Windows Update is from September 18th, 2024:

And it was working fine a week ago. I don't see any Windows Updates in the past week... so I'm not sure how this broke all of a sudden? Does WSL2 get auto-updated outside of Windows Update somehow? Maybe from the Microsoft Store?

[Raven-Singularity]

I was trying to find out more information about what version of wslbridge2 I was using, as there are multiple wslbridge projects on github.

By running this command:

wslbridge2.exe --help

I was able to see this output:

wslbridge2 v0.12 : Runs a program within a Windows Subsystem for Linux (WSL) pty.
Copyright (C) 2019-2022 Biswapriyo Nath.

So that clarifies that this is an issue with this project:

https://github.com/Biswa96/wslbridge2

I see that the wslbridge2 version 0.12 I am using is the most recent release over there, from November 22nd, 2023.

I have posted a copy of this bug report over there:

https://github.com/Biswa96/wslbridge2/issues/42

[Raven-Singularity]

Unfortunately, Biswa96 responded that he no longer uses WSL, and that wslbridge2 is not being updated, and asked if anyone wants to take over maintenance.

Biswa96:

I do not use the WSL anymore and ready to give away the wslbridge2 repository if anyone is interested to maintain it.

So it looks like there may not be a solution to this issue any time soon, or ever, unless someone takes over the wslbridge2 project.

I don't know C++ code well enough to try to bug fix this, myself.

The error message says:

ERROR: GetVmId:312: CreateLxProcess: A null reference pointer was passed to the stub.

I found that file on the wslbridge2 repository here:

https://github.com/Biswa96/wslbridge2/blob/master/src/GetVmId.cpp#L312

And when I look at line 312, it is the section for launching WSL2 (there are other sections for launching WSL1, and launching on various versions of Windows):

[Raven-Singularity]

I decided to try working around the problem by using Cygwin's MINTTY.EXE to run SSH.EXE and connect to my Ubuntu.

But then very strangely, when I ran this command:

F:\Software\Linux_Tools\Cygwin\bin\mintty.exe C:\Windows\System32\bash.exe --login

Or simply:

F:\Software\Linux_Tools\Cygwin\bin\mintty.exe bash --login

It magically launches my WSL2 Ubuntu without any errors!

I don't even need to use SSH.EXE to connect to my local Ubuntu this way. I am very confused.

I have no idea how WSL2 Ubuntu loads correctly from Cygwin's MINTTY.EXE whilst wsltty's MINTTY.EXE can't load it.

Edit: I just found out that MinTTY from wsltty is v3.7.4, while the MinTTY from Cygwin is v3.7.6. So perhaps there is something in those last two updates that helps make it work?

---

I did run into an issue where Cygwin's MinTTY was unable to save its config file (for some reason my Cygwin home folder is unwritable, and I am unable to update the permissions via Bash or Windows). I worked around that issue by specifying --configdir=\some\other\folder outside my Cygwin folder.

But then I ran into another issue where Cygwin's MinTTY is ignoring my setting for not using bold fonts and only using bright colours (my VGA font looks terrible in bold). I haven't found a way to fix this.

Edit: I fixed MinTTY forcing bold to be on, by adding this to my MinTTY config file:

SuppressSGR=1

That completely eliminates the terminal's ability to render bold at all.

[prekageo]

This is my temporary workaround:

1. Clone https://github.com/Biswa96/wslbridge2.git.
2. Apply the provided patch.
3. Compile it with Cygwin.
4. Replace the original wslbridge2.exe with the newly compiled version.
5. Finally, run the provided Python script as an administrator to retrieve the VMID of your WSL instance.

diff --git a/src/wslbridge2.cpp b/src/wslbridge2.cpp
index 28f9b1b..5158b79 100644
--- a/src/wslbridge2.cpp
+++ b/src/wslbridge2.cpp
@@ -17,6 +17,8 @@
 #include <unistd.h>

 #include <array>
+#include <fstream>
+#include <iostream>
 #include <string>
 #include <thread>
 #include <vector>
@@ -228,6 +230,15 @@ static void start_dummy(std::wstring wslPath, std::wstring wslCmdLine,
     CloseHandle(pi.hThread);
 }

+static bool string_to_guid(const char *guidString, GUID *guid) {
+    int ret = sscanf(guidString,
+        "%8x-%4hx-%4hx-%2hhx%2hhx-%2hhx%2hhx%2hhx%2hhx%2hhx%2hhx",
+        &guid->Data1, &guid->Data2, &guid->Data3,
+        &guid->Data4[0], &guid->Data4[1], &guid->Data4[2], &guid->Data4[3],
+        &guid->Data4[4], &guid->Data4[5], &guid->Data4[6], &guid->Data4[7]);
+    return ret == 11;
+}
+
 int main(int argc, char *argv[])
 {
     /* Minimum requirement Windows 10 build 17763 aka. version 1809 */
@@ -387,9 +398,17 @@ int main(int argc, char *argv[])
         if (LiftedWSLVersion)
             start_dummy(wslPath, wslCmdLine, distroName, debugMode);

-        const HRESULT hRes = GetVmId(&DistroId, &VmId, LiftedWSLVersion);
-        if (hRes != 0)
-            fatal("GetVmId: %s\n", GetErrorMessage(hRes).c_str());
+        std::ifstream file("vmid.txt");
+        if (!file) {
+            wchar_t buf[MAX_PATH];
+            GetCurrentDirectory(sizeof(buf), buf);
+            fatal("Cannot find %ls\\vmid.txt", buf);
+        }
+
+        std::string vmid_str{};
+        std::getline(file, vmid_str);
+        if (!string_to_guid(vmid_str.c_str(), &VmId))
+            fatal("error: VMID \"%s\" is not a valid GUID\n", vmid_str.c_str());

         inputSock = win_vsock_create();
         outputSock = win_vsock_create();

import os.path
import subprocess

def main():
    vmid = subprocess.check_output(["hcsdiag", "list"]).decode().splitlines()[0]
    print(os.path.expanduser("~/AppData/Local/wsltty/bin/vmid.txt"))
    with open(os.path.expanduser("~/AppData/Local/wsltty/bin/vmid.txt"), "w") as f:
        f.write(vmid + "\n")

if __name__ == "__main__":
    main()

[eeweegh]

If you're desperate, and willing to run a patch rather than compiling yourself, there's one announced at https://github.com/Biswa96/wslbridge2/issues/42#issuecomment-2396502960

It worked for me.

[mintty]

Just to clarify some background first:

@exeral:

C:\Users\usernameq\AppData\Local\wsltty\bin\mintty.exe /bin/bash: Exit 126. Failed to run '/bin/bash': No such file or directory

This is not WSL bash, it is cygwin bash that mintty would run by default, but it is not included in the wsltty package because it's not used for the WSL workflow. Wsltty installs its own very minimal cygwin environment (in %LOCALAPPDATA%/wsltty). It includes dash which could be used for some standalone operation (mintty /bin/dash), without any standard tools however.

@Raven-Singularity:

mintty.exe bash --login It magically launches my WSL2 Ubuntu without any errors!

This is neither WSL bash nor wsltty/cygwin bash. It is the old Windows gateway to WSL, preceding wsl.exe.

I don't even need to use SSH.EXE to connect to my local Ubuntu this way. I am very confused.

ssh would actually be another method to connect to WSL, and rather well-working. However, you can neither assume that ssh service is running in your WSL distributions or even installed, and which IP addresses your various WSL distributions would have...

I have no idea how WSL2 Ubuntu loads correctly from Cygwin's MINTTY.EXE whilst wsltty's MINTTY.EXE can't load it.

You'd need to build and install wslbridge2 manually, into /bin. However, that would not solve this issue.

I just found out that MinTTY from wsltty is v3.7.4, while the MinTTY from Cygwin is v3.7.6. So perhaps there is something in those last two updates that helps make it work?

No, sorry, I would have made a release already in that case.

I did run into an issue where Cygwin's MinTTY was unable to save its config file (for some reason my Cygwin home folder is unwritable, and I am unable to update the permissions via Bash or Windows). I worked around that issue by specifying --configdir=\some\other\folder outside my Cygwin folder.

That is #351, solved in mintty 3.7.5 (not yet released as wsltty).

But then I ran into another issue where Cygwin's MinTTY is ignoring my setting for not using bold fonts and only using bright colours (my VGA font looks terrible in bold). I haven't found a way to fix this.

That is likely mintty/mintty#1235, a bug in Windows conhost.

About the patch: I've confirmed it works, so there'll be an updated wsltty release soon.

[anetsuk]

I have no idea how WSL2 Ubuntu loads correctly from Cygwin's MINTTY.EXE whilst wsltty's MINTTY.EXE can't load it.

As a workaround until wsltty (wslbrdige2) fix, try the following command line: C:\msys64\usr\bin\mintty.exe --config="%APPDATA%\wsltty\config" C:\msys64\usr\bin\bash.exe -c "/usr/bin/stty raw ; wsl bash --login" (msys2) or C:\cygwin64\bin\mintty.exe --config="%APPDATA%\wsltty\config" C:\cygwin64\bin\bash.exe -c "/usr/bin/stty raw ; wsl bash --login" (cygwin)

In my environment(mintty 3.6.4 and 3.7.4/x64 and ARM64!), this method has worked well.

(It is started via bash.exe just to pre-exec stty command. Otherwise, mintty's pty and WSL's pty will operate redundantly, causing problems when typing Ctrl+O, etc.)

[mintty]

Released 3.7.6. For unclear release status, I'm applying rluetzner's patch locally.

[Raven-Singularity]

@Raven-Singularity:

mintty.exe bash --login It magically launches my WSL2 Ubuntu without any errors!

This is neither WSL bash nor wsltty/cygwin bash. It is the old Windows gateway to WSL, preceding wsl.exe.

Okay. I haven't noticed any issues the past week using my WSL2 Ubuntu install launched from CygWin's MinTTY 3.7.5 with the System32\Bash.exe. If this Microsoft gateway "just works" with stock MinTTY, why is this not the preferred method of launching WSL2 on MinTTY?

Why is wslbridge2 needed at all?

@anetsuk:

(It is started via bash.exe just to pre-exec stty command. Otherwise, mintty's pty and WSL's pty will operate redundantly, causing problems when typing Ctrl+O, etc.)

Why not just run mintty.exe from Cygwin with System32\Bash.exe as the program?

I haven't noticed any issues with any shortcuts not working properly in my terminal over this past week (using GNU Screen, Midnight Commander, Vim, and other apps with shortcuts). Can you explain the Ctrl+O not working thing?

[anetsuk]

Can you explain the Ctrl+O not working thing?

When type Ctrl+O key, minty/cygwin pty turn in VDISCARD mode (and type Ctrl+O again to turn it off).

I am not very familiar with this, but it seems that in VDICARD mode, the contents of the buffer for drawing characters to the tty may be discarded. In this case, the ability of moving cursor position, change color with escape sequences behave strangely.

(VDICARD feature seem to work only in tty iexten mode, so may be fine /usr/bin/stty -iexten instead of /usr/bin/stty raw. However, there may be other issues besides VDICARD, so I am specifying /usr/bin/stty raw.)

Please refer to termios(3) man page for detail. Excerpt from the man page below:

VDISCARD (not in POSIX; not supported under Linux; 017, SI, Ctrl-O) Toggle: start/stop discarding pending output. Recognized when IEXTEN is set, and then not passed as input.