wsltty not working with Windows Subsystem for Linux Preview from Windows Store?
pa-jberanek opened this issue · comments
Version: WSLtty 3.5.1
I can't provide a huge amount of detail here, but I installed "Windows Subsystem for Linux Preview"[1] from the Windows Store, to try out the new WSL version, and all my WSLtty shortcuts stopped working.
When launched a mintty window opens and then closes very soon after, so fast that I can't see any error messages.
I removed the Windows Store version of WSL, and WSLtty sprung back to life again.
BTW, can you provide the error message from that WSL preview setup?
- Install that WSL Preview as you've done.
- Run Command Prompt in
C:\Users\UserName\AppData\Local\wsltty\bin
folder. - Run
wslbridge2.exe
command there. You can see the error message.
assertion "hRes == 0" failed: file "GetVmId.cpp", line 181, function: HRESULT GetVmId(GUID*, GUID*)
0 [main] wslbridge2 1274 cygwin_exception::open_stackdumpfile: Dumping stack trace to wslbridge2.exe.stackdump
the same error with offline package (WSL2)
Converted a WSL distro to version 1, and:
C:\Users\johnb\AppData\Local\wsltty\bin>wslbridge2.exe -d Ubuntu-20.04
johnb@PCNAME:/mnt/c/Users/johnb/AppData/Local/wsltty/bin$
C:\Users\johnb\AppData\Local\wsltty\bin>wsl -l -v
NAME STATE VERSION
* openSUSE-Leap Running 2
Ubuntu-20.04 Running 1
C:\Users\johnb\AppData\Local\wsltty\bin>wslbridge2.exe -d openSUSE-Leap
assertion "hRes == 0" failed: file "GetVmId.cpp", line 181, function: HRESULT GetVmId(GUID*, GUID*)
0 [main] wslbridge2 1677 cygwin_exception::open_stackdumpfile: Dumping stack trace to wslbridge2.exe.stackdump
Here is some report from a quick look.
- wslbridge2.exe in wsltty uses undocumented ILxssUserSession COM interface. It is provided by LxssManager.dll loaded in normal Win32 service host process.
- The WSL Preview Store version registers its own service and COM interface, named IWSLService, in a UWP like process. That interface is somehow replaces itself with ILxssUserSession at runtime (probably).
- If I try to use ILxssUserSession now then
CreateLxProcess
in GetVmId.cpp returns error 1224 i.e. The requested operation cannot be performed on a file with a user-mapped section open. This is the error you've seen.
Next I shall try to do the same thing with wsltty.appx. But I need to figure out what I did years ago 😄
same issue after upgrading to Windows 11 with wsltty 3.3.0. Upgrading to wsltty 3.5.1 fixed the issue for me.
Upgrading to wsltty 3.5.1 fixed the issue for me.
Are you using WSL Preview from Windows Store?
Upgrading to wsltty 3.5.1 fixed the issue for me.
Are you using WSL Preview from Windows Store?
I thought I was but turns out I am not. Please disregard my comment if it's irrelevant.
I just discovered the wsl mintty project a few days ago, and tried to get it working with my Windows 11 machine running the WIndows Store version of the Linux subsystem stuff. I'm also getting the black-screen-then-immediate-close problem.
I change my shortcut to pause on the error, and can now see this is the error I'm getting.
/bin/wslbridge2: Aborted. assertion "hRes == 0" failed: file "GetVmId.cpp", line 54, function: void ComInit()
It doesn't quite match the other errors posted so I'm not sure if it's the same issue or not.
Is this something still to be fixed before release of 3.5.2?
Have the exact same problem when installing wsl preview from windows store (worked well before that, 3.5.1) except in my case the message from running wslbridge2.exe
is different: it is
note: wsl.exe output: The process cannot access the file because it is being used by another process.
This also happens immediately after restart
Would anyone like to volunteer to test a wslbridge2.exe? The test executable will be provided from CI and one has to just copy/paste it in wsltty installation.
Sure
It seems to be partially working, if the wsl2 is already running, it works, but if I shutdown using wsl --shutdown
then it fails with
assertion "hRes == 0" failed: file "GetVmId.cpp", line 236, function: HRESULT GetVmId(GUID*, GUID*) 0 [main] wslbridge2 1322 cygwin_exception::open_stackdumpfile: Dumping stack trace to wslbridge2.exe.stackdump
Here are the steps:
- Download the ZIP file from here https://ci.appveyor.com/project/Biswa96/wslbridge2/build/job/mx67rxpl87fbxvfv/artifacts
- Extract wslbridge2.exe from it.
- Rename or backup the wslbridge2.exe file in
%LocalAppData%\wsltty\bin
path.- Move the previously extract wslbridge2.exe in that path.
- Now run WSL Preview from store.
I download this build and do steps above, there is a cgywin dll error. I tried both cygwin1.dll
come from wsltty 3.5.1 and latest cygwin install by setup-x86_64.exe today.
./wslbridge2.exe
0 [main] wslbridge2 (10504) C:\Users\user\AppData\Local\wsltty\bin\wslbridge2.exe: *** fatal error - cygheap base mismatch detected - 0x180348408/0x180345408.
This problem is probably due to using incompatible versions of the cygwin DLL.
Search for cygwin1.dll using the Windows Start->Find/Search facility
and delete all but the most recent version. The most recent version *should*
reside in x:\cygwin\bin, where 'x' is the drive on which you have
installed the cygwin distribution. Rebooting is also suggested if you
are unable to find another cygwin DLL.
After git clone wslbrideg2 and make RELEASE=1 using new installed cygwin, it works.
Released 3.5.3 with the wslbridge2 fix applied. Please test.
It seems to be partially working, if the wsl2 is already running, it works, but if I shutdown using
wsl --shutdown
then it fails withassertion "hRes == 0" failed: file "GetVmId.cpp", line 236, function: HRESULT GetVmId(GUID*, GUID*) 0 [main] wslbridge2 1322 cygwin_exception::open_stackdumpfile: Dumping stack trace to wslbridge2.exe.stackdump
I am not sure if this is related, although it seems like it.
On a clean install of Win11, WSL Preview from Windows Store, wsltty 3.6.0, everything worked on install but after first reboot wsltty crashes on launch with a segmentation fault in wslbridge2.
Yes, I am aware of that. The newer version of WSL Preview from Store has different COM interface. I have a fix. But I am waiting for the above discussion in wsltty.appx.
that worked for me, thanks a lot!
new bridge works if WSL is already running, but still fails to start it with the following error.
/bin/wslbridge2: Aborted. assertion "hRes == 0" failed: file "GetVmId.cpp", line 287, function: HRESULT GetVmId(GUID*, GUID*, bool) Stack trace: Frame Function Args 000FFFFB2A0 001800620B7 (000FFFFB4A8, 00000000002, 00000000002, 000FFFFDE50) 00000000000 001800640F5 (000FFFFBC50, 00000000000, 000000002C4, 00000000000) 000FFFFB9B0 00180130FD8 (00000000000, 000007D2160, 00000620000, 00000000000) 000000000C1 0018012C70B (00000000000, 00000000000, 00000000000, 00100000037) 000FFFFBDA0 0018012CB15 (0018026A458, 00180132E3E, 0000000011F, 0018026A3DF) 000FFFFBDA0 001802137F8 (00100424000, 0010042401E, 0000000011F, 0018026A3DF) 000FFFFBDA0 001800434C7 (000FFFFC0D0, 00000000000, 00000000000, 00000000000) 000FFFFC390 00100401A1A (001004232E0, FEFEFEFEFF372C45, 8080808080808080, 00000000000) 000FFFFC390 001004215A5 (000FFFFCC20, 000FFFFCD30, 00180368960, 000FFFFCDF0) 000FFFFCD30 00180049B8D (00000000000, 00000000000, 00000000000, 00000000000) 000FFFFFFF0 00180047746 (00000000000, 00000000000, 00000000000, 00000000000) 000FFFFFFF0 001800477F4 (00000000000, 00000000000, 00000000000, 00000000000) End of stack trace
Agree, I have mentioned about that in above comment. wsltty.appx is required for WSL Store version. I am waiting for the discussion in that repository.
The artifact also worked for me. Thank you so much! 🙏
The artifact also worked for me. Thank you so much! 🙏
ditto
Agree, I have mentioned about that in above comment. wsltty.appx is required for WSL Store version. I am waiting for the discussion in that repository.
Any plans to proceed? The appx project seems to be totally dead, I see no response to your issues raised and the last update seems to have been in February where the message "This project is obsolete" was added to the readme.
I think you should propose your fixes here...
Try the cygwin zip from here https://github.com/Biswa96/wslbridge2/releases/tag/v0.9. If you are using WSL Preview from Store make sure to run wsl.exe before running wsltty.exe.
run wsl.exe before running wsltty.exe
I'm considering to do this automatically within mintty.exe, which could also be used to adjust locale configuration.
I was evaluating an alternative solution but its implementation turns out to be cumbersome so far.
Try the cygwin zip from here https://github.com/Biswa96/wslbridge2/releases/tag/v0.9. If you are using WSL Preview from Store make sure to run wsl.exe before running wsltty.exe.
Yeah I am using wsl Preview from Store. It's the 'run wsl.exe before running wsltty' part that I'm hoping to see fixed.
Would be great to see it all integrated into the wsltty.exe
I'm considering to do this automatically within mintty.exe, which could also be used to adjust locale configuration.
I think wsl.exe should be initiated from wslbridge2.exe. It will handle default distro and wsl2 or not logics. But I did not figure out how to do that.
wsl.exe should not be run constantly. Otherwise there will be an bash process lingering around which we fixed in another issue. Assume the first wsl.exe process is like a spark plug. It will initiate the WSL2 VM and exit. Then wslbridge2.exe will catch up with that VM instance quickly.
I bumped into this issue after upgrading to Windows 11 from Windows 10 and upgrading to the Store version of wsl2 with wsl --update
. After this, the wsltty window would close immediately after attempting to start it.
It seems there is a solid workaround for this issue, but I couldn't find a step-by-step description of how to solve this, so I include a step-by-step list of what I did, in the hope someone else finds it useful.
To reproduce:
- Upgrade to Windows 11
- Upgrade to the Store version of WSL2:
C:\WINDOWS\system32>wsl --update
- Confirm the upgrade:
C:\Users\vangelis>wsl --version WSL version: 0.70.4.0 Kernel version: 5.15.68.1 WSLg version: 1.0.45 MSRDC version: 1.2.3575 Direct3D version: 1.606.4 DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp Windows version: 10.0.22621.674
- Confirm that wslbridge2 fails with an assertion error:
C:\Users\vangelis\AppData\Local\wsltty\bin>wslbridge2 -s assertion "hRes == 0" failed: file "GetVmId.cpp", line 126, function: bool IsWslTwo(GUID*, std::wstring) 0 [main] wslbridge2 1374 cygwin_exception::open_stackdumpfile: Dumping stack trace to wslbridge2.exe.stackdump
This series of steps solved the issue for me:
- Install the latest wsltty version from https://github.com/mintty/wsltty/releases/download/3.6.0/wsltty-3.6.0-x86_64-install.exe
- Download the latest release of wslbridge2 from https://github.com/Biswa96/wslbridge2/releases/tag/v0.9 and replace the files under in
%LocalAppData%\wsltty\bin
@Biswa96 I understand this issue is still open, but I am not sure why. I have tested this works regardless of whether I've run wsl.exe
before attempting to start wsltty. Here is what I did:
- Reboot the system, log in
- Start
cmd.exe
and run:
C:\> %LOCALAPPDATA%\wsltty\bin\mintty.exe --WSL=Debian -~ /bin/bash -l
My impression is that releasing a new version of wsltty which integrates the latest wslbridge2 is enough to close this issue, but maybe I am missing something. Thanks!
Sorry I didn't catch up with this issue in time before the breaking release.
I confirm that wslbridge2 also solves the issue for me (testing on Windows 10 with WSL Ubuntu-Preview),
so I can release a quick hot-fix of wsltty. However, I have an issue with two patches that wsltty currently applies to wslbridge2:
- One intended to fix Add COM instance for new lifted WSL service; I assume this fix is now included in 0.9, @Biswa96, please confirm.
- The other intended to fix SIGWINCH propagation (i.e. proper handling of window size changes): #220 (possibly affecting #73). As far as I know this patch has not made it into wslbridge2, although without it, wslbridge2 would occasionally crash under certain conditions. This needs to be rechecked and resolved somehow.
I have now made a release 3.6.1, marked as Pre-Release for the caveats above.
Sadly, I still hit the assertion error on Win11 with Windows Store WSL:
C:\Users\snowgirl\AppData\Local\wsltty\bin>wslbridge2.exe -s
assertion "hRes == 0" failed: file "GetVmId.cpp", line 287, function: HRESULT GetVmId(GUID*, GUID*, bool)
0 [main] wslbridge2 1877 cygwin_exception::open_stackdumpfile: Dumping stack trace to wslbridge2.exe.stackdump
It does start up fine when I’ve already started it through Terminal per the current workaround.
@puellanivis, please confirm: Is that with the just-released wsltty 3.6.1?
@Biswa96, could that be due to dropping the second patch?
The SIGWINCH patch was added in wslbridge2 Biswa96/wslbridge2@a6e2dbb which is present in wslbridge2 version 0.9.
I have mentioned before that it does not solve the actual issue. The wsl.exe has to be run before wslbridge2 or wsltty. I am open to ideas to fix the issue. I have not found any solution without running wslbridge2 as administrator.
Ah, great to know, thank you.
About running wsl.exe first, this could simply be done initially. In order to save an invocation every time, wslbridge2 (or mintty) could check wsl -l -v
(or an API equivalent of this) first to determine whether its state is already Running.
Actually, as suggested before, I might even prefer to do it from mintty, and even every time, in order to get this information:
wsl [-d ...] locale -a
in order to align the presetting of LC_ variables with the capabilities of the selected WSL distribution. Right now, unfortunately, there is often a mismatch; e.g., if I run in a German locale environment and start Debian, an invalid locale will be set, and usage of non-ASCII characters obstructed, because Debian has a minimal locale set installed by default (while some other distributions are equipped with a more complete set).
If that logic (starting wsl.exe) is implemented in mintty then wslbridge2 can not be run as a standalone program. I can not figure out how to start wsl.exe and close the process immediately before starting the wslbridge2-backend process.
I did not mean to combine the invocations. It would be two separate steps:
- Run wsl to initiate WSL and retrieve locale information when it returns.
- Run wslbridge2 just like now.
... which also means you'd need to change nothing. I'll try that approach soon.
I mean that wslbirdge2 need to create wsl.exe process otherwise wslbridge2 can not be run in other terminal emulators.
Understood. Are any others currently using it?
Could wslbridge2 then retrieve the locale information and pass it on to the terminal client per request via some escape code?
That locale issue would be a different topic. wslbridge2 can pass information back and forth with the network sockets.
For this issue, I am finding the solution for launching wsl.exe in wslbridge2.exe for a quick moment then close it before staring the wslbridge2-backend process.
@puellanivis, please confirm: Is that with the just-released wsltty 3.6.1?
Correct, with the just released 3.6.1
Just found the solution. wslbridge2 already starts wsl.exe process. I have to just do it twice 🤦♂️
Please try the wslbridge2.exe and wslbridge2-backend file from this https://ci.appveyor.com/project/Biswa96/wslbridge2/builds/45244286/job/dtg7beug6j48fyst/artifacts. It should fix this issue.
If possible try to test it in various ways, for example,
- with/without WSL Preview
- with/without doing
wsl.exe --shutdown
- with WSL1 and WSL2
- try various command line options.
When running mintty --WSL=Ubuntu-Preview, it hangs for me after this greeting:
To run a command as administrator (user "root"), use "sudo ".
See "man sudo_root" for details.
This is whether with old or new wslbridge2.
Running wslbridge2 from bash in mintty works, again whether old or new.
Tried both WSL V1 and V2.
This is on Windows 10.
That would probably a different issue. I do not use Windows Store and any package from it. I have to play with it a bit. Would you like to create an issue in wslbridge2 repository?
The current issue is with WSL Preview which is available for Windows 11 only.
Can please one of the others in this issue test this on Windows 11? I don't have it...
I replaced wslbridge file with those in the artifact.
Still getting:
/bin/wslbridge2: Aborted.
assertion "hRes == 0" failed: file "GetVmId.cpp", line 287, function: HRESULT GetVmId(GUID*, GUID*, bool)
With Win11, WSL V2, through store.
Did you replace both wslbridge2.exe and wslbridge2-backend files?
I should have; here are the sha256 hashes:
sha256: .\wslbridge2.exe 9EF531B08C2996910968526F3AB169F02D85DC264D51CAFFADB5598EA61D3AEE
sha256: .\wslbridge2-backend 35FCBE86221FB0BED7D1B8471835A89430486837B63922246350F32607A98592
Would you like to try this one https://ci.appveyor.com/project/Biswa96/wslbridge2/builds/45279449/job/370i93njs4onop9y/artifacts ? I have update the log messages. It should show a proper error message. Try these two ways
- Extract both files from the zip and place it in
%LocalAppData%\wsltty\bin
. Run wsltty as usual. - Or, run
%LocalAppData%\wsltty\bin\wslbridge2.exe
after extracting zip file as step 1.
Would you like to try this one https://ci.appveyor.com/project/Biswa96/wslbridge2/builds/45279449/job/370i93njs4onop9y/artifacts ? I have update the log messages. It should show a proper error message. Try these two ways
- Extract both files from the zip and place it in
%LocalAppData%\wsltty\bin
. Run wsltty as usual.- Or, run
%LocalAppData%\wsltty\bin\wslbridge2.exe
after extracting zip file as step 1.
This one works!
PS: I even shutdown WSL and retested just to be sure.
Thanks to both! So if you give it a git tag, I can make a release tomorrow.
This one works!
The last one is same as previous, just changes in printf 😄 I can add a git tag in a day or two.
I have tagged a new version 0.10. See https://github.com/Biswa96/wslbridge2/releases/tag/v0.10
Released 3.6.1.2.
@ngaluru That virustotal report is false positive. There were many similar report in past. See all these old issues https://github.com/mintty/wsltty/issues?q=is%3Aissue+virus+is%3Aclosed. Also the installer and every piece of it are free (libre) and open-source. You can verify the code.
I'm not sure how to interpret that report, but there are two red 1/... marks for two of the shortcut files. So Windows desktop shortcuts are considered to be malicious?? Weird.
Closed as fixed with wslbridge2 0.10.