Originally, I opened a bug report for PowerShell with Microsoft Connect (https://connect.microsoft.com/PowerShell/Feedback/Details/1821747) about this issue, but I have since learned it is with the PSReadline module included with Windows 10, and possibly previous versions.
On Windows 10, from the PowerShell console when using the command "Start-Process powershell -Credential (Get-Credential) -PassThru", while specifying credentials other than those of the current login (eg. CONTOSO\user is currently logged in, and specified CONTOSO\admin in the Get-Credential), the new PowerShell process becomes unresponsive to keyboard commands until either A) enter is pressed in the parent window, or B) the parent window is closed. In the case of A, when the enter key is pressed, the new window will begin typing whatever was put into the window. At that time, the parent window goes unresponsive until the reverse is done.
A workaround is done by issuing Remove-Module PSReadline prior to running Start-Process. However, you cannot reload the module or the issue resumes.
I just reproduced this on Win10 5.1.14393.2879 Thanks for noting the workaround, Bryan!
I reproed launching both powershell.exe and cmd.exe
PS peeps - my scenario is managing privileged credentials using Cyberark, and my module targets allowing admins to launch privileged processes without needing to know the underlying credentials. E,g, running mundane disk maintenance scripts interactively against domain controllers. I ran into this bug immediately. To the extent that you consider interactive admin important, please raise the priority of this bug.
I'll use the workaround for now, but it's ugly and makes for an inconvenient admin experience. E.g.
Remove-Module PSReadline
Start-Process $command -Credential $cred
Read-Host -prompt "Hit <enter> after you're done with the elevated console. Dont use this console until then."
Import-Module PSReadline
I came across this very same problem in powershell as well as powershell core.
Regarding the age of the issue - any news or roadmap how to fix?
A work around is to use the .NET Diagnostics.Process class
$Credential = Get-Credential
$Process = [Diagnostics.Process]::new()
$Process.StartInfo = [Diagnostics.ProcessStartInfo]::new()
$Process.StartInfo.FileName = $PowerShellPath
$Process.StartInfo.UseShellExecute = $false
$Process.StartInfo.Arguments = ('-NoExit -ExecutionPolicy Bypass -Command ')
$Process.StartInfo.Domain, $Process.StartInfo.Username = $Credential.UserName -Split '\\'
$Process.StartInfo.Password = $Credential.Password
$null = $Process.Start()
One thing to note is that the user account will have "c:\users\default" as it's $env:UserProfile path, so you'll need to create a folder called PowerShell in "C:\UsersDefault\AppData\Roaming\Microsoft\Windows"
then you'll need to provide the user account read/write permissions, I just gave authenticated users RW because I'll be using this for a bunch of different accounts.
Any update on this? I just ran into this same problem both in PowerShell and pwsh.
Most helpful comment
I came across this very same problem in powershell as well as powershell core.
Regarding the age of the issue - any news or roadmap how to fix?