2.0.0-insiders-834: prompt gets displayed in an endless loop

Issue Description

When I open a folder containing PowerShell scripts, the integrated terminal displays the prompt in an endless loop, as if I would press and hold the Enter key for it to autorepeat.

Attached Logs

See 1539111398-a60423be-01d3-4cc1-83df-f15ead97e8aa1539111394598.zip

Environment Information

Visual Studio Code

Name	Version
Operating System	Windows_NT x64 10.0.17763
VSCode	1.28.0
PowerShell Extension Version	2.0.0-insiders-834

PowerShell Information

Name	Value
PSVersion	5.1.17763.1
PSEdition	Desktop
PSCompatibleVersions	1.0 2.0 3.0 4.0 5.0 5.1.17763.1
BuildVersion	10.0.17763.1
CLRVersion	4.0.30319.42000
WSManStackVersion	3.0
PSRemotingProtocolVersion	2.3
SerializationVersion	1.1.0.1

Visual Studio Code Extensions

Visual Studio Code Extensions(Click to Expand)

Extension	Author	Version
beautify	HookyQR	1.4.4
cpptools	ms-vscode	0.19.0
csharp	ms-vscode	1.16.2
path-intellisense	christian-kohler	1.4.2
PowerShell	ms-vscode	2.0.0-insiders-834
prettier-vscode	esbenp	1.6.1
printcode	nobuhito	3.0.0
vscode-color	anseki	0.4.5
vscode-html-css	ecmel	0.2.0
vscode-javascript-snippet-pack	akamud	0.1.5
vscode-npm-script	eg2	0.3.5
vscode-standardjs	chenxsan	1.2.3
vscode-tidyhtml	anweber	1.10.0

Seems logs didn't make it via drag-and-drop.

1539111398-a60423be-01d3-4cc1-83df-f15ead97e8aa1539111394598.zip

This seems to be the relevant part of the log:

2018-10-09 20:57:11.511 [VERBOSE] C:\projects\PowerShellEditorServices\src\PowerShellEditorServices\Session\PowerShellContext.cs: In method 'ExecuteCommand', line 622:
    Attempting to execute command(s):
    
        
            [System.Diagnostics.DebuggerHidden()]
            [System.Diagnostics.DebuggerStepThrough()]
            param()
            return [Microsoft.PowerShell.PSConsoleReadLine, Microsoft.PowerShell.PSReadLine2, Version=2.0.0.0, Culture=neutral, PublicKeyToken=null]::ReadLine(
                $Host.Runspace,
                $ExecutionContext,
                $args[0]) System.Threading.CancellationToken
    

2018-10-09 20:57:11.513 [ERROR] C:\projects\PowerShellEditorServices\src\PowerShellEditorServices\Session\PowerShellContext.cs: In method 'ExecuteCommand', line 692:
    Execution of the following command(s) completed with errors:
    
        
            [System.Diagnostics.DebuggerHidden()]
            [System.Diagnostics.DebuggerStepThrough()]
            param()
            return [Microsoft.PowerShell.PSConsoleReadLine, Microsoft.PowerShell.PSReadLine2, Version=2.0.0.0, Culture=neutral, PublicKeyToken=null]::ReadLine(
                $Host.Runspace,
                $ExecutionContext,
                $args[0]) System.Threading.CancellationToken
    
    Error #1:
    Exception calling "ReadLine" with "3" argument(s): "The type initializer for 'Microsoft.PowerShell.PSConsoleReadLine' threw an exception."
    ScriptStackTrace:
    at <ScriptBlock>, <No file>: line 5
    Exception:
       System.Management.Automation.MethodInvocationException: Exception calling "ReadLine" with "3" argument(s): "The type initializer for 'Microsoft.PowerShell.PSConsoleReadLine' threw an exception." ---> System.TypeInitializationException: The type initializer for 'Microsoft.PowerShell.PSConsoleReadLine' threw an exception. ---> System.TypeInitializationException: The type initializer for 'Microsoft.PowerShell.Keys' threw an exception. ---> System.ArgumentException: An item with the same key has already been added.
       at System.ThrowHelper.ThrowArgumentException(ExceptionResource resource)
       at System.Collections.Generic.Dictionary`2.Insert(TKey key, TValue value, Boolean add)
       at Microsoft.PowerShell.Keys..cctor()
       --- End of inner exception stack trace ---
       at Microsoft.PowerShell.PSConsoleReadLine..cctor()
       --- End of inner exception stack trace ---
       at Microsoft.PowerShell.PSConsoleReadLine.ReadLine(Runspace runspace, EngineIntrinsics engineIntrinsics, CancellationToken cancellationToken)
       at CallSite.Target(Closure , CallSite , Type , Object , Object , Object )
       --- End of inner exception stack trace ---
       at System.Management.Automation.ExceptionHandlingOps.ConvertToMethodInvocationException(Exception exception, Type typeToThrow, String methodName, Int32 numArgs, MemberInfo memberInfo)
       at CallSite.Target(Closure , CallSite , Type , Object , Object , Object )
       at System.Dynamic.UpdateDelegates.UpdateAndExecute4[T0,T1,T2,T3,TRet](CallSite site, T0 arg0, T1 arg1, T2 arg2, T3 arg3)
       at System.Management.Automation.Interpreter.DynamicInstruction`5.Run(InterpretedFrame frame)
       at System.Management.Automation.Interpreter.EnterTryCatchFinallyInstruction.Run(InterpretedFrame frame)InnerException:
       System.TypeInitializationException: The type initializer for 'Microsoft.PowerShell.PSConsoleReadLine' threw an exception. ---> System.TypeInitializationException: The type initializer for 'Microsoft.PowerShell.Keys' threw an exception. ---> System.ArgumentException: An item with the same key has already been added.
       at System.ThrowHelper.ThrowArgumentException(ExceptionResource resource)
       at System.Collections.Generic.Dictionary`2.Insert(TKey key, TValue value, Boolean add)
       at Microsoft.PowerShell.Keys..cctor()
       --- End of inner exception stack trace ---
       at Microsoft.PowerShell.PSConsoleReadLine..cctor()
       --- End of inner exception stack trace ---
       at Microsoft.PowerShell.PSConsoleReadLine.ReadLine(Runspace runspace, EngineIntrinsics engineIntrinsics, CancellationToken cancellationToken)
       at CallSite.Target(Closure , CallSite , Type , Object , Object , Object )InnerException:
       System.TypeInitializationException: The type initializer for 'Microsoft.PowerShell.Keys' threw an exception. ---> System.ArgumentException: An item with the same key has already been added.
       at System.ThrowHelper.ThrowArgumentException(ExceptionResource resource)
       at System.Collections.Generic.Dictionary`2.Insert(TKey key, TValue value, Boolean add)
       at Microsoft.PowerShell.Keys..cctor()
       --- End of inner exception stack trace ---
       at Microsoft.PowerShell.PSConsoleReadLine..cctor()InnerException:
       System.ArgumentException: An item with the same key has already been added.
       at System.ThrowHelper.ThrowArgumentException(ExceptionResource resource)
       at System.Collections.Generic.Dictionary`2.Insert(TKey key, TValue value, Boolean add)
       at Microsoft.PowerShell.Keys..cctor()

Relevant PSReadLine code:
https://github.com/lzybkr/PSReadLine/blob/57bc3a65fd2bbf0b69aaed2ce395d0327de20cc0/PSReadLine/Keys.cs#L406-L419

Stéphane BARIZIEN (@sba923)

Stéphane BARIZIEN (@sba923) Out of curiosity:

Does your normal PowerShell session support PSReadLine? I'm assuming Windows PowerShell -- if so, it might be worth installing PowerShell Core to see if its PSReadLine works for you.
What's your keyboard configuration? Is it US or something else? Normal layout or something like Dvorak or Colemak?
What's your language/culture set to? en_US, or something else?

Patrick Meinecke (@SeeminglyScience)

Tagging Patrick Meinecke (@SeeminglyScience) as well, since he knows much more about PSReadLine than me

Jason Shirk (@lzybkr)

Ah yeah. That's most likely the known issue with different keyboard layouts.

~~Here's the PR to follow PowerShell/PSReadLine#771~~

The fix has already been merged (Thank you Jason Shirk (@lzybkr)!)

Stéphane BARIZIEN (@sba923) here's the latest preview build for PSReadLine if you'd like to see if that fixes your issue.

Rob Holt (@rjmholt) We should consider updating the insiders build to pull a daily until that fix gets into a beta

Patrick Meinecke (@SeeminglyScience)

Patrick Meinecke (@SeeminglyScience) - wrong PR, the fix was merged in PowerShell/PSReadLine#768

Here's my setup:

French Windows 10 (preinstalled by Acer)
English and German language packs installed
Windows display language set to English
keyboard layout = French
Get-Culture returns

LCID             Name             DisplayName
----             ----             -----------
1033             en-US            English (United States)

If I switch VScode to PowerShell Core 6.1, the problem is still present.

If I switch the keyboard layout to English while the PowerShell "integrated terminal" starts, the problem disappears -- even if I later change the keyboard layout back to French.

HTH

Stéphane BARIZIEN (@sba923)

Stéphane BARIZIEN (@sba923) - note that some key bindings won't work correctly if you switch keyboard layouts after starting PowerShell - specifically the need for Shift differs between the initial and changed keyboard layouts, e.g. Alt+1 does not require Shift in English, but does for French.

I don't think this affects commonly used key bindings, but it's good to be aware of. If it does affect important bindings, I'd like the hear about it because I rely on a Win32 api that reports incorrect information after the keyboard layout change and the team needs customer feedback to justify fixing it.

Stéphane BARIZIEN (@sba923)

Stéphane BARIZIEN (@sba923) sorry by "swtich to PSCore", I meant as the standalone app rather than in VSCode. But I think we are using an even newer version of PSReadLine than PSCore anyway.

Anyway, it looks like this is fixed in PSReadLine.

Patrick Meinecke (@SeeminglyScience) maybe we can come up with a way to identify PSReadLine issues similar to how PSReadLine itself deals with them to make crashing and reporting easier? Just thinking about being more helpful to Jason Shirk (@lzybkr) here :)

Rob Holt (@rjmholt)

Rob Holt (@rjmholt) I'm using PowerShell Core 6.1 next to Windows PowerShell 5.1, and don't have any prompt issues in either. Only the integrated terminal in VScode with any post-1.9.0-test-build of the PowerShell extension exhibits the problem.

Jason Shirk (@lzybkr) I find it very strange that 1) there are apps that still do their keycode-to-action-or-character mapping on their own instead of relying on OS infrastructure for that 2) changing the keyboard mapping e.g. with Win+Space while an app is running (which is just... always the case) would cause problems

Where does this all tell about us getting a version of the PowerShell extension for VScode that "just works"? Do you guys have to wait for a fixed PSReadLine to be "baked into" the extension?

Stéphane BARIZIEN (@sba923)

Stéphane BARIZIEN (@sba923)

Where does this all tell about us getting a version of the PowerShell extension for VScode that "just works"? Do you guys have to wait for a fixed PSReadLine to be "baked into" the extension?

Yeah this issue was just recently discovered and fixed in PSReadLine, so it hasn't made it to a beta release yet. Once that happens we can change the CI build to pull the newest release and it will be a part of the daily build bundle.

Rob Holt (@rjmholt)

Patrick Meinecke (@SeeminglyScience) maybe we can come up with a way to identify PSReadLine issues similar to how PSReadLine itself deals with them to make crashing and reporting easier? Just thinking about being more helpful to Jason Shirk (@lzybkr) here :)

Yeah we need to handle this better, even though a similar situation is unlikely to happen again. Because PSRL is invoked via PowerShellContext.ExecuteCommand any exceptions are caught, logged, optionally printed to the console, then ignored. If PSRL throws any exception, we should either fall back to old ReadLine or hard fail. Maybe in this case we should log stack trace, OS, framework, and module information into one entry for to make it a little easier to troubleshoot as well.

Not yet, and I must confess I was kinda scared by the first testing reports...

The behaviour's probably going to be better than an infinite loop. There were changes made in the most recent update for international keyboards. But the only way we can improve it is by trying it out.

Flavien MICHALECZEK (@fMichaleczek)

I've replaced PSRL beta3 with beta4, made it so that Flavien MICHALECZEK (@fMichaleczek)'s workaround is nop-ed out using:

Write-Host ("{0:yyyy-MM-dd HH:mm:ss.fff}: '{1}' starting..." -f (Get-Date), $MyInvocation.MyCommand.Path)

$psrl = (Get-Module PSReadLine)

if ($null -eq $psrl)
{
    $prerelease = $null
    Write-Host -ForegroundColor Red ("Cannot find PSReadLine!!!")
}
else
{
    Write-Host("PSReadLine is '{0}'" -f $psrl.Path)
    $prerelease = ($psrl | ForEach-Object { $_.PrivateData.PSData })['Prerelease']
}


if ($prerelease -eq 'beta4')
{
    Write-Host("No workaround should be needed for PSReadLine 2.0.0 beta4")
}
else
{
…
}

and it seems to work (just did one quick test):

2019-03-29 15:57:11.528: 'C:\private_sba\profile.ps1' exiting.
2019-03-29 15:57:14.411: 'C:\private_sba\NET\DOC\WindowsPowerShell\Microsoft.VSCode_profile.ps1' starting...
PSReadLine is 'C:\Users\sba\.vscode\extensions\ms-vscode.powershell-preview-2.0.0\modules\PSReadLine\2.0.0\PSReadLine.psm1'
No workaround should be needed for PSReadLine 2.0.0 beta4

no endless loop at this point!

I'll deploy this on as many systems as possible and report back.

FWIW here's how I checked that I have only copies of PSReadLine beta4 on $env:PSModulePath:

$env:PSModulePath -split ';' | ForEach-Object {
    $psrlpath = Join-Path -Path $_ -ChildPath 'PSReadLine'
    $found = Test-Path -LiteralPath $psrlpath
    $prerelease = $null
    if ($found)
    {
        $isprerelease = $false
        $psrl = Get-Module -ListAvailable -FullyQualifiedName $psrlpath
        if ($null -ne $psrl)
        {
            $version = $psrl.Version
            $privatedata = $psrl.PrivateData
            if ($null -ne $privatedata)
            {
                $prerelease = $privatedata['PSData']['Prerelease']
                $isprerelease = $true
            }
        }
        [PSCustomObject]@{
            Path         = $psrlpath
            Found        = $found
            Version = $version
            IsPrerelease = $isprerelease
            Prerelease      = $prerelease
        }
    }
}

On one system I'm facing something pretty weird: during execution of Microsoft.VSCode_profile.ps1, and at the TERMINAL prompt, "get-module PSReadLine" returns $null, even though the module is found on $env:PSModulePath.

There must be something I don't understand / guess about the inner workings of PSES / the extension.

Can someone help me out with this?

Same problem on another machine...

Does this give a hint on what's going on?

PS ~/powershell> gmo psreadline
PS ~/powershell> import-module -verbose psreadline
VERBOSE: Loading module from path 'C:\Users\steph\OneDrive\Documents\WindowsPowerShell\Modules\psreadline\2.0.0\psreadline.psd1'.
VERBOSE: Cannot verify the Microsoft .NET Framework version 4.6.1 because it is not included in the list of permitted versions.
VERBOSE: Loading 'FormatsToProcess' from path 'C:\Users\steph\OneDrive\Documents\WindowsPowerShell\Modules\psreadline\2.0.0\PSReadLine.format.ps1xml'.
VERBOSE: Loading module from path 'C:\Users\steph\OneDrive\Documents\WindowsPowerShell\Modules\psreadline\2.0.0\Microsoft.PowerShell.PSReadLine2.dll'.
VERBOSE: Importing cmdlet 'Get-PSReadLineOption'.
VERBOSE: Importing cmdlet 'Set-PSReadLineOption'.
VERBOSE: Importing cmdlet 'Set-PSReadLineKeyHandler'.
VERBOSE: Importing cmdlet 'Get-PSReadLineKeyHandler'.
VERBOSE: Importing cmdlet 'Remove-PSReadLineKeyHandler'.
VERBOSE: Loading module from path 'C:\Users\steph\OneDrive\Documents\WindowsPowerShell\Modules\psreadline\2.0.0\PSReadLine.psm1'.
VERBOSE: Exporting function 'PSConsoleHostReadLine'.
VERBOSE: Exporting cmdlet 'Get-PSReadLineOption'.
VERBOSE: Exporting cmdlet 'Set-PSReadLineOption'.
VERBOSE: Exporting cmdlet 'Set-PSReadLineKeyHandler'.
VERBOSE: Exporting cmdlet 'Get-PSReadLineKeyHandler'.
VERBOSE: Exporting cmdlet 'Remove-PSReadLineKeyHandler'.
VERBOSE: Importing cmdlet 'Get-PSReadLineKeyHandler'.
VERBOSE: Importing cmdlet 'Get-PSReadLineOption'.
VERBOSE: Importing cmdlet 'Remove-PSReadLineKeyHandler'.
VERBOSE: Importing cmdlet 'Set-PSReadLineKeyHandler'.
VERBOSE: Importing cmdlet 'Set-PSReadLineOption'.
VERBOSE: Importing function 'PSConsoleHostReadLine'.

Sydney Smith (@SydneyhSmith)

Sydney Smith (@SydneyhSmith) TylerLeonhardt I tested beta4 (On preview 2) on 2 PCs and it looks like it working.
With beta3 if keyboard is on Hebrew and I start the terminal I get the loop, with beta4 I don't have this problem.
Thank you

Stéphane BARIZIEN (@sba923)

Stéphane BARIZIEN (@sba923) Get-Module PSReadLine means that PSRL is not loaded in your session. However, if you run Set-PSReadLineKeyHandler or something in your profile, that will cause module autoloading to load PSRL.

We probably load PSRL after profiles are run, but if your profile runs a cmdlet from PSRL, it will cause it to load PSRL and all will be fine.

Stéphane BARIZIEN (@sba923)

We can close this issue now as being an external issue fixed in the next release of PSRL but Stéphane BARIZIEN (@sba923) if you have more concerns regarding when PSRL gets loaded, feel free to open a new issue.

TylerLeonhardt

Thanks to all who contributed to this fix! ISE's grave is getting deeper ;-)

TylerLeonhardt Yes I will open another issue for the problem where PSRL doesn't get loaded in some circumstances: when this happens not only don't I get PSRL in my VScode session, but also if I load it manually using Import-Module it doesn't behave properly (no syntax highlighting, so history backed by a file on disk....)

Opened #1834

Stéphane BARIZIEN (@sba923)

Stéphane BARIZIEN (@sba923) That link in your comment is broken (leads to: https://github.com/PowerShell/vscode-powershell/issues/url)

Fixed, thanks for the remark.

Navigation Menu

Repository navigation

2.0.0-insiders-834: prompt gets displayed in an endless loop #1570

Issue Description

Attached Logs

Environment Information

Visual Studio Code

PowerShell Information

Visual Studio Code Extensions

44 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

2.0.0-insiders-834: prompt gets displayed in an endless loop #1570

Description

Issue Description

Attached Logs

Environment Information

Visual Studio Code

PowerShell Information

Visual Studio Code Extensions

Activity

sba923 commented on Oct 10, 2018

rjmholt commented on Oct 10, 2018

rjmholt commented on Oct 10, 2018

rjmholt commented on Oct 10, 2018

rjmholt commented on Oct 10, 2018

SeeminglyScience commented on Oct 10, 2018

lzybkr commented on Oct 10, 2018

sba923 commented on Oct 10, 2018

lzybkr commented on Oct 10, 2018

rjmholt commented on Oct 10, 2018

sba923 commented on Oct 11, 2018

SeeminglyScience commented on Oct 11, 2018

44 remaining items

rjmholt commented on Mar 28, 2019

sba923 commented on Mar 29, 2019

sba923 commented on Mar 29, 2019

sba923 commented on Mar 29, 2019

sba923 commented on Mar 30, 2019

sba923 commented on Mar 30, 2019

ili101 commented on Mar 31, 2019

TylerLeonhardt commented on Mar 31, 2019

TylerLeonhardt commented on Mar 31, 2019

sba923 commented on Apr 1, 2019

sba923 commented on Apr 2, 2019

ExE-Boss commented on Apr 2, 2019

sba923 commented on Apr 2, 2019

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions