error 0x800700c1 when launching pwsh.exe

[kkostrzewa-coupa]

Windows Terminal version (or Windows build number)

1.11.2921.0

Other Software

pwsh.exe 7.2.0

Steps to reproduce

my terminal has C:\Users\Kevin Kostrzewa\AppData\Local\Microsoft\WindowsApps\Microsoft.PowerShell_8wekyb3d8bbwe\pwsh.exe in the Powershell profile (note the space between Kevin and *Kostrzewa()

Installing Visual Studio 2022 created a file called c:\users\Kevin to be created, containing some installation logs.

Terminal failed to launch pwsh.exe after, presumably because of the space in the terminal profile around powershell. I think this is related to #7195

Expected Behavior

pwsh.exe to launch

NOTE: I think Terminal could be more resilient around pathing and launching the .exe so a file can't be injected ahead of it with clever space filled pathing. This may be a security issue, if c:\users\Kevin was attempted to be CreateProcess'ed.

Actual Behavior

[error 0x800700c1 when launching `C:\Users\Kevin Kostrzewa\AppData\Local\Microsoft\WindowsApps\Microsoft.PowerShell_8wekyb3d8bbwe\pwsh.exe']

[kkostrzewa-coupa]

I fixed this on my machine by killing the bad c:\users\Kevin file, so I'm not facing this issue right now.

[zadjii-msft]

Could you clarify- the commandline

C:\Users\Kevin Kostrzewa\AppData\Local\Microsoft\WindowsApps\Microsoft.PowerShell_8wekyb3d8bbwe\pwsh.exe

did you set that as the commandline in your profile, or are you using one of the dynamically generated pwsh.exe profiles that the Terminal creates for you?

[error 0x800700c1 when launching C:\Users\Kevin Kostrzewa\AppData\Local\Microsoft\WindowsApps\Microsoft.PowerShell_8wekyb3d8bbwe\pwsh.exe']`

I suspect that implies that the Terminal did know that the exe was at that full path, but CreateProcess still decided to use C:\Users\Kevin as the executable path. Hmmm.

[kkostrzewa-coupa]

The command line was dynamically generated by Terminal

[elsaco]

@kkostrzewa-coupa did you install PS7 manually? When adding PS7 from Microsoft Store this is what's being automatically inserted in settings.json

            {
                "guid": "{5fb123f1-af88-5b5c-8953-d14a8def1978}",
                "hidden": false,
                "name": "PowerShell 7",
                "source": "Windows.Terminal.PowershellCore"
            }

Tested on Win10 & WT Preview 1.12.2931.0

[DHowett]

Interestingly, this is the same as what happens when you have a file called C:\Program and we try to launch something out of C:\Program Files...

[kkostrzewa-coupa]

@elsaco I believe I installed from the Microsoft store. Regardless, I think the core issue (weirdness around space in path) is still a problem.

[malxau]

CreateProcess, when given a string that doesn't contain quotes indicating the executable, is documented to probe and guess where the executable really is: https://docs.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-createprocessa

Applications are supposed to use quotes so CreateProcess doesn't guess, partly because if it does guess it's possibly a vulnerability. It'd actually be nice to be able to globally disable this guessing behavior to preemptively flush out this class of bug.

[kkostrzewa-coupa]

@malxau from my read of that doc, the guessing occurs when lpApplicationName is NULL. Can lpApplicationName be set to the string in the Terminal Command Line?

[zadjii-msft]

I'd suspect no, since people could have a commandline like wsl -d Ubuntu, where wsl should be the application name.

Presumably though, there's a way we could construct the commandline for the powershell profiles such that they'd be resistant to that. Maybe just wrapping them up in another layer of quotes?

[ghost]

🎉This issue was addressed in #12086, which has now been successfully released as Windows Terminal Preview v1.13.10336.0.:tada:

Handy links:

• Release Notes
• Store Download