Piping ssh output to cmdlet with debug breakpoint crashes PowerShell

Prerequisites

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

Steps to reproduce

Piping output from ssh (more specifically cating some syslogs) into a cmdlet with a breakpoint set causes PowerShell to crash as soon as the breakpoint is hit.

I hit this while trying to debug my ConvertFrom-RegEx module, but given that I have a 100% crash-rate no matter where the breakpoint is I don’t think this is something to do with my code. (Even then, the debugger/pwsh executable crashing isn’t ideal.)

Storing ssh output into a variable and piping that variable into the cmdlet with breakpoints works normally. Perhaps ssh is preventing the debugger from calling ReadKey()?

Expected behavior

PS> pushd $HOME\source\repos
PS> ipmo .\ConvertFrom-RegEx\ConvertFrom-RegEx # repo hmmwhatsthisdo/ConvertFrom-RegEx, commit f18a0a46
PS> Set-PSBreakpoint -Script .\ConvertFrom-RegEx\ConvertFrom-RegEx\Public\ConvertFrom-RegEx.ps1 -Line 135 
PS> ssh $remoteuser@$remoteip -i $HOME\.ssh\$remoteuser-id_rsa cat /var/log/syslog | ConvertFrom-RegEx -Pattern '^(?<month>\S+)'
# [PowerShell hits debugger breakpoint]

Actual behavior

Debugger crashes upon hitting breakpoint

Error details

An error has occurred that was not properly handled. Additional information is shown below. The PowerShell process will exit.
Unhandled exception. System.InvalidOperationException: Cannot read keys when either application does not have a console or when console input has been redirected. Try Console.Read.
   at System.ConsolePal.ReadKey(Boolean intercept)
   at Microsoft.PowerShell.PSConsoleReadLine.ReadOneOrMoreKeys()
   at Microsoft.PowerShell.PSConsoleReadLine.ReadKeyThreadProc()
   at System.Threading.Thread.StartHelper.Callback(Object state)
   at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state)
--- End of stack trace from previous location ---
   at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state)
   at System.Threading.Thread.StartCallback()

Environment data

PS C:\> $PSVersionTable

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

Visuals

[dkaszews]

there are several more-graceful ways to handle the situation than crashing the PowerShell process

@hmmwhatsthisdo Fair point, even if some process locks input, debugger could try to detect it and show an error “Unable to debug interactive process” instead.

[PaulHigin]

Removing the WG-Remoting tag because this does not involve PowerShell remoting, and appears to be a bug in PowerShell during command line debugging.