Powershell: The term 'C:\Windows\System32\OpenSSH\ssh.exe' is not recognized as the name of a cmdlet, function, script file, or operable program.

[cloudhan]

Steps to reproduce

Seems only ssh.exe and wsl.exe will have this weird problem. Even I use a full path like C:\Windows\System32\OpenSSH\ssh.exe wont fix the problem. See following screenshots.

Expected behavior

With Windows PowerShell, everything works as expected.

Actual behavior

With PowerShell Core

Environment data

Installed with PowerShell-7.0.0-rc.2-win-x64.msix

Name                           Value
----                           -----
PSVersion                      7.0.0-rc.2
PSEdition                      Core
GitCommitId                    7.0.0-rc.2
OS                             Microsoft Windows 10.0.19041
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

[cloudhan]

Note, autochk.exe is a executable that I randomly chosen from C:\Windows\System32, to show that:

1. C:\Windows\System32 is in $env:Path.
2. C:\Windows\System32 is readable in ps core

[mklement0]

A shot in the dark: Are these perhaps 32-bit executables? If so, you must target them via C:\Windows\SysWow64 from 64-bit processes.

[cloudhan]

Might be related https://github.com/MicrosoftDocs/WSL/issues/499 and https://github.com/microsoft/WSL/issues/4259.

@therealkenc I see you commented in https://github.com/microsoft/WSL/issues/4259, do you have any idea? I think this is a PSCore's issue.

Here is my path.

> $env:Path -split ';'
C:\Program Files\WindowsApps\Microsoft.PowerShellPreview_7.0.102.0_x86__8wekyb3d8bbwe
C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v10.2\bin
C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v10.2\libnvvp
C:\Program Files (x86)\Common Files\Intel\Shared Libraries\redist\intel64_win\compiler
C:\Program Files (x86)\Common Files\Intel\Shared Libraries\redist\ia32_win\compiler
C:\Program Files\WindowsApps\Microsoft.PowerShell_7.0.0.4_neutral__8wekyb3d8bbwe
C:\ProgramData\Oracle\Java\javapath
C:\Program Files (x86)\PDFtk\bin
C:\Program Files (x86)\GnuPG\bin
C:\Program Files (x86)\IntelSWTools\OpenCL\runtime\cpu\windows\compiler\lib\ia32_win
C:\Program Files (x86)\IntelSWTools\OpenCL\runtime\cpu\windows\compiler\lib\intel64_win
C:\Program Files (x86)\IntelSWTools\OpenCL\sdk\bin\GTPin
C:\Program Files (x86)\IntelSWTools\OpenCL\sdk\bin\Pin
C:\Program Files (x86)\IntelSWTools\OpenCL\sdk\bin\x64
C:\Program Files (x86)\IntelSWTools\OpenCL\sdk\bin\x86
C:\Program Files (x86)\Wolfram Research\WolframScript
C:\Program Files\dotnet
C:\Program Files\Git LFS
C:\Program Files\Git\cmd
C:\Program Files\Microsoft SQL Server\130\Tools\Binn
C:\Program Files\Microsoft VS Code\bin
C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common
C:\Program Files (x86)\Windows Kits\10\Windows Performance Toolkit
C:\Windows
C:\Windows\System32
C:\Windows\System32\OpenSSH
C:\Windows\System32\wbem
C:\Windows\System32\WindowsPowerShell\v1.0
C:\Program Files\NVIDIA Corporation\Nsight Compute 2019.5.0
C:\Program Files\CMake\bin
C:\texlive\2019\bin\win32
C:\tools\vcpkg
C:\tools\vcpkg\installed\x64-windows\bin
C:\Users\cloud\.dotnet\tools
C:\Users\cloud\AppData\Local\Microsoft\WindowsApps
C:\tools\depot_tools
C:\tools

[cloudhan]

@mklement0 random executables live in $env:Path being not executable is frustrating. I just don't understand how can I being unable to launch a process with an absolute path of an executable, where the executable is perfectly runnable with cmd or Windows PowerShell.

And I notice an even more stupid thing, if I launch cmds from powershells, the problem still presents with PSCore launched cmd, is it contagious, or just something wrong with my env?

[mklement0]

Does PowerShell at least find the _file_? Does the following return what you expect it to?

Get-Item -Force C:\Windows\System32\OpenSSH\ssh.exe

Your $env:PATH variable content is short enough to not be a problem.
Still, given that you say that a cmd instance launched from PowerShell then also displays the problem makes me wonder if there's something about the _content_ of your $env:PATH variable that causes problems (though that contradicts being able to run autochck.exe);

if you trim down $env:PATH to just the standard entries (temporarily, so we can narrow down the problem), does the problem persist.

[cloudhan]

@mklement0 PSCore failed to Get-Item with

Get-Item: Cannot find path 'C:\Windows\System32\OpenSSH\ssh.exe' because it does not exist.

[mklement0]

I see: I'm starting to suspect that it is _PowerShell_ that has been installed as a _32-bit_ version, which would explain the symptom, given that 32-bit processes have their own, independent C:\Windows\System32 directory that shadows the one that 64-bit processes see.

Try:

# This would only work from a 32-bit PowerShell instance.
# Access the 64-bit C:\Windows\System32 directory.
Get-Item -Force C:\Windows\SysNative\OpenSSH\ssh.exe

A quick test to determine whether your PowerShell session is 32-bit is to examine $env:ProgramFiles: if it contains C:\Program Files (x86) instead of C:\Program Files, you're running a 32-bit session.

[cloudhan]

@mklement0 Great thanks for the help, problem resolved after I reinstalled x64 version. Seems I make some mistake and install x86 version, and I can confirm that with my command history. Also thanks for pointing out the interesting SysNative directory.

[ianpan870102]

@mklement0 Thanks Michael, your solution saved my day.