wslbridge2 won't load on mintty/wsltty (ERROR: GetVmId:312: CreateLxProcess: A null reference pointer was passed to the stub.)

[Raven-Singularity]

Reposting bug report from: mintty/wsltty#356

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 then tried loading up mintty.exe terminal with bash as the command.

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

Which gave me 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 run wslbridge2.exe --help it gives me:

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

And when I directly run wslbridge2.exe it outputs:

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

The wslbridge2 error I get mentions VM ID, and looking at the main wslbridge2 github page I see this under the "CAVEATS" section:

There is no documented way to get VM ID of running WSL2 utility VM. See this microsoft/WSL#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 stated that switching to WSL1 as a workaround does avoid the wslbridge2 issue:

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

I went and searched Microsoft.com for a list of recent Windows Updates for 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

However, when I then looked for my list of installed Windows Updates, I discovered that update isn't actually installed. My most recent Windows Update showing up is from September 18th, 2024:

But WSL2 was working fine in wsltty after that update a week ago. I don't see any Windows Updates during the past few days... 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?

---

These are other users who area also experiencing the same issue:

@exeral, @rluetzner, @xuefer, @ypnos

Comparing our wsl --version outputs, we're all using the same versions of these apps:

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

And for Windows 10 versions, we all have one of these 3 versions:

Windows Version: 10.0.22631.4169
Windows Version: 10.0.19045.4894
Windows Version: 10.0.19042.2965

Any clues, @benhillis, @Biswa96, or anyone else?

[Biswa96]

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

[Biswa96]

you can use WSL in Windows Terminal.

[Raven-Singularity]

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

Aww, that's too bad. I was really liking using MinTTY for my WSL2.

you can use WSL in Windows Terminal.

I had major issues with Windows Terminal, CMD, ConEmu, and a few other terminals I tried using. Issues such as randomly cutting off several pixels on the left side of the terminal, when in fullscreen or maximised, making them unusable. I haven't had any graphical issues with MinTTY the past few months, so I'm really sad to see this project is being abandoned.

Does this mean wsltty will also become an abandoned project (assuming it's not just us 5 with this issue)?

[jamoflaw]

Definitely not just you :(

wsltty is a savior - had loads of issues with default windows terminal (copy paste for one - who the heck makes pressing enter copy.....!?)

[Biswa96]

I could try to change the code after some time but I can not test it.

[jamoflaw]

Does the Windows part need cygwin? as in can't be cross compiled?

[Biswa96]

Does the Windows part need cygwin?

yes.

[Raven-Singularity]

I had a bunch of annoyances in the other terminals I tried. The cutting off the left edge was the worst, but I also had issues with copying-and-pasting and a bunch of other random things. I spend endless hours coding in my WSL2 and running a local web server, I need a terminal that "Just Works".

Hopefully MinTTY gets native support for launching WSL2 -- possibly the same way other terminals do it?

ConEmu, Windows Terminal, CMD, and at least 1 other terminal I tried supported launching WSL2.

I am not sure how those other terminals handle launching WSL2 without using a wslbridge?

Is that because those are native Windows API apps and not using Cygwin?

---

I could try to change the code after some time but I can not test it.

I'd be happy to test out any code updates.

Would I need to compile the updated wslbridge2 using a Cygwin development environment, or would you be posting binaries?

[Biswa96]

I will try to create a pull request.

[Raven-Singularity]

I just thought of one possible way to work around the issue of needing a WSL2 bridge:

1. Install OpenSSH on my WSL2 Ubuntu
2. Run MinTTY without using wsltty
3. Run SSH.EXE to connect to localhost

I haven't tried this before, but it seems like it should work. This method may end up having issues with terminal emulation or random bugs, but it's worth a shot.

I'm not keen to downgrade to WSL1 in order to keep using MinTTY, as I've read that WSL1 has a lot worse disk performance, less features, and more bugs.

[Biswa96]

Yes, you can use ssh. The first wslbridge was created to skip the ssh setup process and other reasons.

[Raven-Singularity]

I decided to try using Cygwin's MINTTY.EXE, BASH.EXE and SSH.EXE to connect to my Ubuntu.

But very strangely, when I try running 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 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.

How in the world is WSL2 Ubuntu loading correctly from Cygwin's MINTTY.EXE while wsltty's MINTTY.EXE can't load WSL2?

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.

[Biswa96]

Unfortunately, I can not figure out stuff in latest WSL.

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

The issue is due to that undocumented COM methods that wslbridge2 uses.

I can help in other general Linux related topic.

[chpock]

VMid can also be obtained by process traversal, looking for wslhost.exe and snipping the identifier corresponding to distroid from its command line:

D:\>wmic process where caption="wslhost.exe" get commandline
CommandLine

--vm-id {21891965-8985-489c-b6a9-cf2cf4babcd1} --handle 880

--vm-id {21891965-8985-489c-b6a9-cf2cf4babcd1} --handle 2200

--distro-id {cd4dafd6-d6f8-48f0-a9cf-d4e742da06be} --vm-id {21891965-8985-489c-b6a9-cf2cf4babcd1} --handle 704 --event 736 --parent 740

It is done here in go: https://github.com/buptczq/WinCryptSSHAgent/blob/1e526e8b96b23e88818741a2177c50ee2171a8f1/utils/wsl2.go#L29

Unfortunately, I couldn't get a quick fix as cygwin has incomplete headers regarding WMI: https://cygwin.com/pipermail/cygwin/2020-April/244366.html

Perhaps this information will help someone solve the issue

[MrVinkel]

I tried to use WMI and other ways to looking up the process arguments, but I was too much hassle - at least for me.

Instead I found the VM id in the registry. The HKEY is set when the VM starts up and removed again when it shuts down. I have only tested it on Win11 22631.4169

bool GetIdFromRegistry(GUID& guid) {
    HKEY hKeyRoot = HKEY_LOCAL_MACHINE;
    std::wstring subKey = L"SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\HostComputeService\\VolatileStore\\ComputeSystem";
    HKEY hKey;
    if (RegOpenKeyEx(hKeyRoot, subKey.c_str(), 0, KEY_READ, &hKey) == ERROR_SUCCESS) {
        DWORD index = 0;
        WCHAR keyName[256];
        DWORD keyNameSize = sizeof(keyName) / sizeof(keyName[0]);

        while (RegEnumKeyEx(hKey, index, keyName, &keyNameSize, nullptr, nullptr, nullptr, nullptr) == ERROR_SUCCESS) {
            RegCloseKey(hKey);
            std::wstring id = L"{" + std::wstring(keyName) + L"}";
            return IIDFromString(id.c_str(), &guid) == S_OK;
        }
        RegCloseKey(hKey);
    }
    return false;
}

[Biswa96]

Instead I found the VM id in the registry. The HKEY is set when the VM starts up and removed again when it shuts down.

I am not sure if that registry key is valid. VM id is also assigned to Hyper-V VMs. Make sure those are excluded.

[prekageo]

I confirm that the VM id from the registry is correct for me as well (Version 10.0.19045.4894). This can be a potentially better fix than the workaround I proposed in mintty/wsltty#356 (comment)

[rluetzner]

I'm a bit wary of putting this out there. I don't know the first thing about the inner workings of WSL or even basic C++. In no way am I volunteering to continue this project. I'd be lost as soon as the next WinAPI change happens. 😬

Nevertheless, I managed to patch together and build a fixed wslbridge2.exe, that you can find and download here.

You can check the commit for what I've done. It replaces the previous WSL v2 logic with the function to get the VmId from the registry.

Thanks go out to @prekageo and @MrVinkel who did the heavy lifting.

This is pretty much for everybody who just want to have their wsltty back (at least for a little while) without installing Cygwin, figuring out which packages to install and how to patch and build this project. 🙂

[godlygeek]

I found the VM id in the registry. The HKEY is set when the VM starts up and removed again when it shuts down. I have only tested it on Win11 22631.4169

I can confirm that it's there in Windows 10 22H2 (winver 19045.4894) as well.

[eeweegh]

Thank you very much! Patch works for me, after wsltty started failing on me out of the blue (worked fine yesterday, today it was broken after bootup)

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

[mintty]

I could try to change the code after some time but I can not test it.

@Biswa96, thank you very much for considering this even though you don't use WSL anymore.
I've checked the patch and can confirm it works.
Would you integrate it and make another release or should wsltty switch to that other repository for reference?
In either case, thank you so much for years of support, fighting changing secret Windows APIs, and cooperating on solutions.

[Biswa96]

Would you integrate it and make another release

Do you mean the registry lookup patch?

[mintty]

Yes.

[xuefer]

I tried to use WMI and other ways to looking up the process arguments, but I was too much hassle - at least for me.

Instead I found the VM id in the registry. The HKEY is set when the VM starts up and removed again when it shuts down. I have only tested it on Win11 22631.4169

bool GetIdFromRegistry(GUID& guid) {
    HKEY hKeyRoot = HKEY_LOCAL_MACHINE;
    std::wstring subKey = L"SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\HostComputeService\\VolatileStore\\ComputeSystem";
    HKEY hKey;
    if (RegOpenKeyEx(hKeyRoot, subKey.c_str(), 0, KEY_READ, &hKey) == ERROR_SUCCESS) {
        DWORD index = 0;
        WCHAR keyName[256];
        DWORD keyNameSize = sizeof(keyName) / sizeof(keyName[0]);

        while (RegEnumKeyEx(hKey, index, keyName, &keyNameSize, nullptr, nullptr, nullptr, nullptr) == ERROR_SUCCESS) {
            RegCloseKey(hKey);
            std::wstring id = L"{" + std::wstring(keyName) + L"}";
            return IIDFromString(id.c_str(), &guid) == S_OK;
        }
        RegCloseKey(hKey);
    }
    return false;
}

it's a good workaround, unless there's multiple wsl. tested and works under win10 too

[MrVinkel]

I could try to change the code after some time but I can not test it.

@Biswa96, thank you very much for considering this even though you don't use WSL anymore. I've checked the patch and can confirm it works. Would you integrate it and make another release or should wsltty switch to that other repository for reference? In either case, thank you so much for years of support, fighting changing secret Windows APIs, and cooperating on solutions.

I think the registry lookup is just a temp workaround. As mentioned it does not work with multiple WSL instances or other VM's running in Hyper-V and it does not verify the distro ID.

I looked more into extracting the VM ID from command line args, but it is also a hacky fix which requires a WSL session to already be running. It can at least verify the distro ID and works with multiple VM's. I did not complete it though, I just verified it could work - see my fork.

I think the best solution would be to fix the Lxss COM stuff, but it seems like a rabbit hole

[mintty]

I think the registry lookup is just a temp workaround. As mentioned it does not work with multiple WSL instances or other VM's running in Hyper-V and it does not verify the distro ID.

Can you elaborate on this? I have ~6 distros, 2 of which are in WSL mode 2, and I could run all of them in parallel with the patch. So how would it not work?

I looked more into extracting the VM ID from command line args, but it is also a hacky fix which requires a WSL session to already be running.

That is feasible in the context of wsltty. Mintty or its launcher could start a helper process with wsl.exe to achieve that, before connecting.

It can at least verify the distro ID and works with multiple VM's. I did not complete it though, I just verified it could work - see my fork.

Any working solution will raise my attention to integrate it into wsltty. Also any clarification about the registry lookup solution or why it would not work in certain situations.

[Biswa96]

All WSL2 instances are run in same VM. So, VM ID is same for every WSL2 instances in same machine. The problem is that the registry does not exclude Hyper-V VMs. For example, see the two VM IDs when Hyper-V and WSL2 are running simultaneously.

$ hcsdiag.exe list
3F7F4251-3FF4-4DEA-BCCC-7963119FF61F
    VM,                         Created, 3F7F4251-3FF4-4DEA-BCCC-7963119FF61F, VMMS

B9CE8521-73A8-499C-B143-5DC5536A728A
    VM,                         Running, B9CE8521-73A8-499C-B143-5DC5536A728A, WSL

[MrVinkel]

Okay I thought it was unique per wsl instance. So there is no need to verify the distro ID then? If so, the process command line lookup is much easier and I can make a pr on it

[his-ishi]

#43

Worked on win11. thank you @MrVinkel

[Raven-Singularity]

A big thank you to @rluetzner, @MrVinkel, and everyone else who has put efforts into solving this issue.

All WSL2 instances are run in same VM. So, VM ID is same for every WSL2 instances in same machine. The problem is that the registry does not exclude Hyper-V VMs. For example, see the two VM IDs when Hyper-V and WSL2 are running simultaneously.

$ hcsdiag.exe list
3F7F4251-3FF4-4DEA-BCCC-7963119FF61F
    VM,                         Created, 3F7F4251-3FF4-4DEA-BCCC-7963119FF61F, VMMS

B9CE8521-73A8-499C-B143-5DC5536A728A
    VM,                         Running, B9CE8521-73A8-499C-B143-5DC5536A728A, WSL

Can't the parent registry folder be pulled up for the list of VMs, then just grab the one that has "WSL" at the end?

Or where is the VM, Running, B9CE8521-73A8-499C-B143-5DC5536A728A, WSL part coming from?

Would this be cleaner or dirtier than parsing command line arguments of running processes?

Also, does either method require Administrator rights?

The original proposed methods said they required Admin rights, but this seems very strange when other terminals launch WSL2 without Admin.

[mintty]

I've released wsltty 3.7.6 with @rluetzner's patch.

[MrVinkel]

Can't the parent registry folder be pulled up for the list of VMs, then just grab the one that has "WSL" at the end

The registry does not mention 'WSL', but there are some differences between WSL VM and other Hyper V VM's in the registry. But I think that is even more 'unstable' than just looking at the wslhost.exe args

Also, does either method require Administrator rights?

hcsdiag.exe requires admin rights, but looking at the command line args does not

[Biswa96]

hcsdiag.exe requires admin rights

nitpick: hcsdiag.exe requires admin rights if current user is not in Hyper-V Administrators group.