Process objects created with Start-Process -NoNewWindow and/or -RedirectStandard* never report their exit code on Windows.

[mklement0]

Note:

• The problem only surfaces on Windows.
• The problem does not occur when you use -Wait in addition to -PassThru as opposed to a separate Wait-Process call.
  • Update: Per Start-Process does not populate the process object's exit code with NoNewWindow switch #20400, the problem now (PowerShell 7.4.0-preview.5) also surfaces when -Wait is used.

Workaround:

Per #20716 (comment), the workaround is to cache the process handle before calling Wait-Process / .WaitForExit():

$p = Start-Process cmd -args '/c', 'ver' -PassThru -NoNewWindow
$dummy = $p.Handle # WORKAROUND: use a dummy variable to cache the handle
Wait-Process -id $p.Id
"Exit code: [$($p.ExitCode)]"  # Now the exit code is reported.

Steps to reproduce

On Windows:

$p = Start-Process cmd -args '/c', 'ver' -PassThru -NoNewWindow
Wait-Process -id $p.Id
"Exit code: [$($p.ExitCode)]"

Note that the problem only occurs when -NoNewWindows and /or any of the -RedirectStandard* parameters are present.

Inserting a $p.WaitForExit() call after the Wait-Process call, as suggested in the docs to ensure that .ExitCode has a value (which should be the equivalent of Wait-Process), doesn't help.

Expected behavior

Microsoft Windows [Version 10.0.15063]
Exit code: [0]

$ps.ExitCode should contain 0, given that the cmd command reports exit code 0.

Actual behavior

Microsoft Windows [Version 10.0.15063]
Exit code: []

Note how $ps.ExitCode is unexpectedly stringified to the empty string.
Also, even though Get-Member indicates that the property's date type is [int], $null -eq $ps.ExitCode is $true.

This suggests that an exception is occurring behind the scenes, which PowerShell quietly ignores.

An exception when accessing .ExitCode should only occur if the process hasn't exited yet, however, which is at odds with having used Wait-Process and $p.HasExited indicating $true.

Environment data

PowerShell Core v6.0.0-beta.9 on Microsoft Windows 10 Pro (64-bit; v10.0.15063)
Windows PowerShell v5.1.15063.674 on Microsoft Windows 10 Pro (64-bit; v10.0.15063)

[vexx32]

https://stackoverflow.com/questions/10262231/obtaining-exitcode-using-start-process-and-waitforexit-instead-of-wait

Dug this up... Seems as though it's not so much waiting for it to end as it is explicitly querying for the process handle while it's still running is what allows the exit code to be captured.

Ideally, Start-Process could internally query the process handle from the object before passing it to the pipeline in order to ensure the exit code is always captured, regardless of the circumstance.

[mklement0]

Great find, @vexx32 - that sounds like a great workaround.

A little more background info to flesh out your statement, from a linked answer:

This is a quirk of the implementation of the .NET Process object. The implementation of the ExitCode property first checks if the process has exited.
For some reason, the code that performs that check not only looks at the HasExited property but also verifies that the process handle is present in the process object and throws an exception if it is not. PowerShell intercepts that exception and returns null.
Accessing the Handle property causes the process object to retrieve the process handle and store it internally. Once the handle is stored in the process object, the ExitCode property works as expected.

I wonder if there was ever a good reason for this behavior, or whether we should also file a CoreFx bug report.

[vexx32]

It probably can't hurt, honestly. But meantime, we can temp-fix this fairly quickly, it would appear. 😄

I'm not familiar with the internals of that object, but I wouldn't be surprised if there was some weirdness where it accesses the ExitCode via the handle reference somehow, so if it isn't retrieved before the process exits, it can't get at it, or something.

Should still be fixed either way, heh.

[jmaxxz]

Any updates on this? This really should be addressed.

[jordanrh1]

Any update? This is a rather impactful productivity blocker because you can't tell if process succeeded or failed. Makes start-process pretty much useless.

[mklement0]

Per #20716 (comment), the workaround (only applicable if -Wait isn't used) is to cache the process handle before calling Wait-Process / .WaitForExit(); I've also updated the initial post with an example.

[mklement0]

A fix may land in v7.4.1 (the PR mentions only the related #20400 issue):

• [release/v7.4.1] Fix #20400, Start-Process with -NoNewWindow returns null ExitCode on Process object with -PassThru #20866

[microsoft-github-policy-service]

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.

[mklement0]

It looks like the problem has indeed been fixed, as verified via the original repro steps, in the current version, v7.4.2.