32-bit Python 3.12.7 subprocess.run() cannot run executables from Windows\System32

[brechtm]

Bug report

Bug description:

PS C:\> py -V:3.12-32 -c "import subprocess; subprocess.run(['ssh'])"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "C:\Users\Brecht Machiels\AppData\Local\Programs\Python\Python312-32\Lib\subprocess.py", line 548, in run
    with Popen(*popenargs, **kwargs) as process:
         ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Users\Brecht Machiels\AppData\Local\Programs\Python\Python312-32\Lib\subprocess.py", line 1026, in __init__
    self._execute_child(args, executable, preexec_fn, close_fds,
  File "C:\Users\Brecht Machiels\AppData\Local\Programs\Python\Python312-32\Lib\subprocess.py", line 1538, in _execute_child
    hp, ht, pid, tid = _winapi.CreateProcess(executable, args,
                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
FileNotFoundError: [WinError 2] The system cannot find the file specified

This does work in the 64-bit Python 3.12.7 (after renaming vcruntime140.dll; see #125872):

PS C:\> py -V:3.12 -c "import subprocess; subprocess.run(['ssh'])"
usage: ssh [-46AaCfGgKkMNnqsTtVvXxYy] [-B bind_interface]
           [-b bind_address] [-c cipher_spec] [-D [bind_address:]port]
           [-E log_file] [-e escape_char] [-F configfile] [-I pkcs11]
           [-i identity_file] [-J [user@]host[:port]] [-L address]
           [-l login_name] [-m mac_spec] [-O ctl_cmd] [-o option] [-p port]
           [-Q query_option] [-R address] [-S ctl_path] [-W host:port]
           [-w local_tun[:remote_tun]] destination [command [argument ...]]

I'm assuming that this is because ssh.exe is an ARM executable. Using file in a Git Bash shell:

$ file "C:\Windows\System32\OpenSSH\ssh.exe"
C:\Windows\System32\OpenSSH\ssh.exe: PE32+ executable (console) Aarch64, for MS Windows, 6 sections

Calling an amd64 git does work:

PS C:\> py -V:3.12-32 -c "import subprocess; subprocess.run(['git', 'version'])"
git version 2.47.0.windows.1

$ file "C:\Program Files\Git\cmd\git.exe"
C:\Program Files\Git\cmd\git.exe: PE32+ executable (console) x86-64, for MS Windows, 13 sections

CPython versions tested on:

3.12

Operating systems tested on:

Windows 11 ARM

[zooba]

It's more likely because it's under System32, which gets special behaviour from 32-bit executables, and because there is no OpenSSH installed in the x86 System directory.

Can you try launching C:\Windows\SysNative\OpenSSH\ssh.exe? That should bypass the magic that Windows applies, and will give us a hint as to whether we're looking at path resolution or DLL conflict issues.

[brechtm]

Can you try launching C:\Windows\SysNative\OpenSSH\ssh.exe? That should bypass the magic that Windows applies, and will give us a hint as to whether we're looking at path resolution or DLL conflict issues.

running that full path works indeed, as does adding C:\Windows\SysNative\OpenSSH to PATH.

[zooba]

Thanks for confirming. I've updated the title.

Now, asking broadly, what should we do about this? It's a Windows-specific behaviour (if you launch C:\Windows\SysWOW64\cmd.exe then you also won't be able to launch C:\Windows\System32\OpenSSH\ssh.exe from there), but I'm pretty sure we can disable it. Is it worth disabling around subprocess calls?

[brechtm]

I have no strong opinion about this. It does strike me as unexpected, however.

Not sure my use-case matters, but I wanted to distribute a Python script as an executable built by pyinstaller. To have a sort of "universal binary", I thought I could build a x86 (32-bit) exe (by running pyinstaller using a 32-bit Python), since that runs on all Windows flavors. Unfortunately, this issue makes the binary a lot less universal, even though it could be worked around! 😄

I guess these days an x86_64 exe would practically be universal enough, and that doesn't suffer from this problem. That does raise this question: if x86_64 executables have no trouble finding arm64 executables, why should x86_32 executables?

[zooba]

That does raise this question: if x86_64 executables have no trouble finding arm64 executables, why should x86_32 executables?

I'm not sure exactly what the behaviour is, but if the binaries exist for both then you won't notice. The "problem" here is that Windows doesn't include a 32-bit build of OpenSSH, while I suspect that the ARM64 OS will include both x64 and ARM64 builds of OpenSSH.

Strictly speaking you shouldn't assume OpenSSH will be installed anyway, because it is optional. But I suspect it's the most likely edge case to be encountered here. For the most part, System32 and SysWOW64 (and I assume whatever the ARM64 one is called) mostly contain the same files.