Start-Process -Credential prevents interactive input in both the caller and the new window

[mklement0]

This is a long-standing bug that also affects Windows PowerShell.

On Windows, -Credential can be used to start a process in a new window with a given user identity.

Currently, doing so effectively prevents interactive use of both the caller's window and the new window, because they seem to be competing for keyboard input.

Note: Curiously, if you start powershell.exe specifically, the problem does not occur; other shells, however - such as pwsh itself and cmd - do exhibit the problem.

Steps to reproduce

On Windows (update: problem verified on Windows 10 versions 1809 and 1909 - see (Get-ComputerInfo).WindowsVersion)

# Enter a different user's credentials (or even your own) when prompted.
Set-Location C:\; Start-Process cmd -Credential (Get-Credential)

Expected behavior

The call should return after having launched the cmd process and both the calling shell and the cmd shell in the new window should function normally and independently.

Actual behavior

Typing in either window either has no effect or sometimes makes what was typed show up in the respective other window.

Behavior returns to normal when the new window is closed.

Environment data

PowerShell Core v7.0.0 (7.0.0) on Microsoft Windows 10 Pro (64-bit; Version 1909, OS Build: 18363.720)

[iSazonov]

I can not repo. Run pwsh, run the command, new window is opened, both windows work well.
Could you please add more info about repo steps? Do you mean using -NoNewWindow?

[mklement0]

I just tried the repro steps again - I get the symptom every time, in the environment as reported.
Are you running on a different Windows 10 version?

-NoNewWindow doesn't apply, because it is ignored when you use -Credential (the combination should arguably result in a syntax error, but that's a separate issue).

[iSazonov]

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

[iSazonov]

I tried on 10.0.19041 and I can repo. I see that both windows compete for input.

[iSazonov]

Look like defaults for redirections was changed on OS level.

[iSazonov]

@mklement0 Have you Windows Feedback tool on your system? You could pull the feedback there (and maybe reference the issue there) and share a reference here (I'd confirm your report).

/cc @TravisEz13 @PaulHigin Could you please look the issue?

[mklement0]

@iSazonov, since runas.exe /user:... still manages to work correctly on the affected recent Windows 10 versions, I suspect that a solution on our end is possible.

[iSazonov]

@mklement0 I hope but we use so simple pinvoke that I wonder where we have an issue.

[PaulHigin]

• @daxian-dbw
  I believe Dongbo has worked most recently in this area, and may have some thoughts.