2

$PSVersionTable output is

Name                           Value
----                           -----
PSVersion                      5.1.18362.628
PSEdition                      Desktop
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
BuildVersion                   10.0.18362.628
CLRVersion                     4.0.30319.42000
WSManStackVersion              3.0
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1

[System.Environment]::OSVersion.Version output is

Major  Minor  Build  Revision
-----  -----  -----  --------
10     0      18363  0

C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe started as a user who is a member of the local administrator's group, but not in elevated mode. Call this the 'parent' console.

In the parent console, execute (where 'UserName' should be replaced by either the same or a different user logged-in interactively to the computer)

Start-Process -FilePath powershell.exe -Credential UserName

Upon entering the correct password for 'UserName', a new PowerShell window opens (let's call this the 'child' console). Within that, type 'exit' and then hit the Enter/Return key. Nothing happens in the child console: no letters appear, the Enter/Return is not processed.

Switch to the parent console, press the space bar four times. As the space bar is pressed, 'exit' will appear in the child console. Pressing the space bar one more time will cause the 'Enter/Return' key to be processed in the child and it will then exit.

I've tried this on another machine running a 2016 version (10.0 build 14393) of Win 10 with the same results.

This doesn't seem right. Is it right? If it is, how do I avoid it?

Thank you.

anonmous
  • 139
  • 1
  • 6
  • 3
    It seems that both processes (created via described procedure) are _blocking_ keyboard input **mutually**. If I use `-Wait` switch then at least the _child_ process accepts keyboard input… – JosefZ Mar 13 '20 at 21:08
  • Thanks JosefZ, Unfortunately, the -Wait switch suspends the other process until the child exit. As you pointed out, they both are in a bad state as regards output. – anonmous Mar 15 '20 at 20:42

1 Answers1

1

This doesn't seem right. Is it right?

No, it's a long-standing bug, still present as of PowerShell 7.0, unfortunately; it has been reported in this GitHub issue.

JosefZ narrowed things down in a comment:

It seems that both processes (created via described procedure) are blocking keyboard input mutually. If I use the -Wait switch, then at least the child process accepts keyboard input…

how do I avoid it?

The workaround is to use the standard runas.exe utility:

runas /user:UserName powershell.exe

Caveat: As you point out, the HOMEPATH (and presumably also HOMEDRIVE) environment variable isn't set correctly in the new session (as of Windows 10, version 1909): HOMEPATH unexpectedly points to \WINDOWS\system32 rather than the user's home path; by contrast, USERPROFILE does contain the expected value.

mklement0
  • 382,024
  • 64
  • 607
  • 775