Be able to run wsl / bash from a 32 bit process

[kristjanvalur]

Recently I found that I couldn't run WSL services from a TeamCity worker: https://github.com/microsoft/WSL/issues/4652

It turned out that the workers are running in a 32 bit process, running the 32 bit command line interpreter from c:\windows\SysWOW32 through file system redirection (https://docs.microsoft.com/en-us/windows/win32/winprog64/file-system-redirector)

Now, I confirmed this. Repro steps:

1. 1. open c:\windows\syswow64\cmd.exe
2. type bash. Nothing happens. "dir c:\windows\system32\bash.exe" fails to return a result, as expected, because it is really lookin into c:\windows\syswow64

Now, to test a workaround, I simply copied bash.exe from c:\windows\system32 to c:\windows\syswow64. This worked. now, i can launch bash.exe from the 32 bit command shell.

there really is no restriction on 32 bit processes to launch 64 bit ones, the need to do file system redirection has more to do with dlls and other in-process dependencies. In this particular case, I can't see why a 32 bit process shouldn't be able to start the 64 bit bash shell or execute wsl commands. Perhaps the system32 dir isn't the ideal place for these executables, or perhaps they can be simply copied to syswow64.exe too, to enable this functionality.

[therealkenc]

This is dupe #223 which got closed in an undead state of workaround-available without a ruling on status by-design (contrast bug/feature). The fact #223 was closed would suggest the former, but won't hard-dupe this on benefit of the doubt.

[Biswa96]

For 32 bit process, use Sysnative instead of System32. So, the path becomes C:\Windows\Sysnative\wsl.exe or %SystemRoot%\Sysnative\wsl.exe.

[bvibber]

Note this is tripping me up with PowerShell on ARM64 Windows 10, where the shell itself is provided as a 32-bit x86 binary instead of a native 64-bit ARM64 binary and runs in the WoW64 layer:

In a Command Shell (cmd.exe) it works as expected without requiring the manual sysnative path.

[bvibber]

(I think it's important to note that whether the calling process is 32-bit or not is not just the .exe developer's business; you may be running shell commands via a program that's created by someone else. Developer tooling is a common case for this.)

[therealkenc]

with PowerShell on ARM64 Windows 10, where the shell itself is provided as a 32-bit x86 binary instead of a native 64-bit ARM64 binary

That's sort of interesting. Off topic WSL, but out of mild curiosity, if you grab PowerShell-7.0.0-preview.5-win-arm64.msix from here do you get actual 64-bit goodness?

[bvibber]

with PowerShell on ARM64 Windows 10, where the shell itself is provided as a 32-bit x86 binary instead of a native 64-bit ARM64 binary

That's sort of interesting. Off topic WSL, but out of mild curiosity, if you grab PowerShell-7.0.0-preview.5-win-arm64.msix from here do you get actual 64-bit goodness?

Yes, if I install that and launch powershell 7 preview explicitly it sees the wsl.exe in the expected PATH. So hopefully that particular annoyance will resolve itself in the future sometime. :) For now I've just switched my default terminal shell to CMD.exe since I don't do a lot of PS scripting.

[microsoft-github-policy-service[bot]]

This issue has been automatically closed since it has not had any activity for the past year. If you're still experiencing this issue please re-file this as a new issue or feature request.

Thank you!