`Start-Process` on Windows: `-Environment` is quietly ignored when `-Verb RunAs` is also specified, combination should be prevented.

[mklement0]

Prerequisites

• [X] Write a descriptive title.
• [X] Make sure you are able to repro it on the latest released version
• [X] Search the existing issues.
• [X] Refer to the FAQ.
• [X] Refer to Differences between Windows PowerShell 5.1 and PowerShell.

Steps to reproduce

Note:

• I'm assuming that the underlying .NET / Windows APIs don't support this combination; if so, an error should be reported.

• Indeed the .NET APIs actively prevent the analogous combination (not sure about direct use of the WinAPI): .Verb = "RunAs" requires .UseShellExecute = true, which in turn actively prevents modifying the environment via .Environment or .EnvironmentVariables (exception "The Process object must have the UseShellExecute property set to false in order to use environment variables.").

Start-Process -Verb RunAs cmd -Environment @{ foo='new' } '/c "echo [%foo%]" & pause' -Wait

Expected behavior

An error indicating that the specific parameter combination isn't supported.

Actual behavior

The process is launched, and the -Environment argument is quietly ignored.

[%foo%]

Error details

No response

Environment data

PowerShell 7.4.0 on W11 22H2

Visuals

No response

[StevenBucher98]

Indeed the .NET APIs actively prevent the analogous combination

Sounds like its an issue with .NET, have you opened an issue in there repo?

[mklement0]

@StevenBucher98:

• I can't speak to whether the by-design limitation in .NET is ultimately an unavoidable limitation in the Windows API.

  • I am not personally interested in researching this further.

  • If someone does, and if it turns out that the limitation could be overcome via a change in .NET, there's no guarantee that such a change would be made and, even if so, it would take a loooonng time for it to become available in PowerShell.

• Therefore, I don't think the Resolution-External label is appropriate here.

  • Instead, this is an Issue-Bug, due to allowing you to specify unsupported parameter combinations without so much as a warning.

  • Another way to resolve this would be for PowerShell itself to work around the .NET limitation, via direct WinAPI calls if even possible.

[StevenBucher98]

Marking up for grabs.

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

This issue has not had any activity in 6 months, if there is no further activity in 7 days, the issue will be closed automatically.

Activity in this case refers only to comments on the issue. If the issue is closed and you are the author, you can re-open the issue using the button below. Please add more information to be considered during retriage. If you are not the author but the issue is impacting you after it has been closed, please submit a new issue with updated details and a link to this issue and the original.

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

This issue has not had any activity in 6 months, if there is no further activity in 7 days, the issue will be closed automatically.

Activity in this case refers only to comments on the issue. If the issue is closed and you are the author, you can re-open the issue using the button below. Please add more information to be considered during retriage. If you are not the author but the issue is impacting you after it has been closed, please submit a new issue with updated details and a link to this issue and the original.