Error: The scope number '7' exceeds the number of active scopes. Parameter name: ScopeID

[DarkLite1]

System Details

### VSCode version: 1.34.0-insider 56f1b4795fed05677eb82a21dac4fc1ab62d747b
x64

### VSCode extensions:
ms-vscode.powershell@1.12.0
ms-vscode.powershell-preview@2.0.1
ritwickdey.LiveServer@5.5.1


### PSES version: 2.0.0.0

### PowerShell version:

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

Issue Description

Sometimes I receive the following error:

[-] should be green 15.49s
ValidationMetadataException: The argument is null or empty. Provide an argument that is not null or empty, and then try the command again.
ParameterBindingValidationException: Cannot validate argument on parameter 'Message'. The argument is null or empty. Provide an argument that is not null or empty, and then try the command again.
at , S:\Test\Script.ps1: line 5

Script.ps1

$Error.Clear()

if ($Error) {
    $Error.ForEach( {
            Write-EventLog @EventErrorParams -Message $_.Exception.Message
        })
}

Script.Tests.ps1

$here = Split-Path -Parent $MyInvocation.MyCommand.Path
$sut = (Split-Path -Leaf $MyInvocation.MyCommand.Path) -replace '\.Tests\.', '.'

$Error.Clear()

Describe $sut {
    Mock Write-EventLog

    It 'should be green' {
        ."$here\$sut"
        $Error | Should -BeNullOrEmpty
    }
    In $TestDrive {
        Describe 'Test' {
            It 'should be green' {
                ."$here\$sut"
                $Error | Should -BeNullOrEmpty
            }
        }
    }
}

This does not always happen and it took me a long time to figure out that this only happens in VS Code and never in the PowerShell ISE. To narrow it further down the behavior can be consistently reproduced when setting a breakpoint at the line if ($Error).

When consulting the array of $Error at the breakpoint the following is shown:

I don;t know why this happens, but it could be related to #66. I'm using the PowerShell Preview 2.0.1.

[rjmholt]

Given that you're in the preview extension, it's likely this is a race condition somewhere between PSReadLine, the extension, and possibly the command being invoked. Fixing it is something we're hoping to achieve later this year when we try to tackle some architectural maintenance with the extension

[yobyot]

Me, too.

I continue to be disheartened at the inability of vscode to replace the console, much less the ISE. On macOS, it's worse -- I end up having to run a VM just to use Windows PowerShell. Delaying such important debugger issues as this with "architectural maintenance" is a way of saying, to me ears, "We really didn't think through debugging hard enough. And we don't care that much about pwsh users -- talk to us about bugs in jscript and we're listening."

`### VSCode extensions:
eamodio.gitlens@9.8.5
ms-vscode.powershell@2019.5.0
streetsidesoftware.code-spell-checker@1.7.17
vscode-icons-team.vscode-icons@8.8.0

PSES version: 1.12.1.0

PowerShell version:

Name Value

---

PSVersion 6.2.1
PSEdition Core
GitCommitId 6.2.1
OS Microsoft Windows 10.0.15063
Platform Win32NT
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
WSManStackVersion 3.0`

[rjmholt]

I understand your frustration. The maintainers of the PowerShell extension are all PowerShell users and contributors. We tend to write a lot more PowerShell and C# than JS.

The difficulty in the debugger comes because of the mismatch between a generalised multithreaded language server experience, and PowerShell's single-threaded completion system.

The work we're currently undertaking to restructure the extension a bit will mean we can address and control the issues that creates much more readily. Rather than being a mutual exclusion, working on this at a lower level will end up being much better for the debugging experience as it stands.

To your point about using Windows PowerShell on macOS, Windows PowerShell is only supported on Windows. Could you describe the scenario you want to service there? Depending on what you're trying to do, it might be worth using remoting, trying out PowerShell 7, or having a look at the PSScriptAnalyzer compatibility rules.

[yobyot]

Thank you for your reply, @rjmholt.

I'm trying not to use Windows PowerShell anywhere. I'd prefer to be using PowerShell 6.2.1 everywhere but cannot because of my main gripe with vscode: it does not reliably replace the Windows PowerShell ISE for even simple debugging, not to mention its inability to advanced debugging like Sapien's PowerShell Studio.

My frustration is that as good as PowerShell is and as good as vscode is, together they actually stink -- at least in what I consider the basics: identical results to what's happening in a console, console editing and reliable debugging. Who's going to adopt PowerShell 6 or 7 on any platform if you get unrepeatable errors (happens to me all the time), different results from modules like Az and AWSPowerShell.NetCore in vscode from a debugger and just plain old hangs?

In short, PowerShell 6 and later is a language in search of a reliable coding environment -- which the vscode extension most certainly is not. I'm shocked and that a language that Microsoft brought to the world has fallen into such disrepair. Maybe it's function that nobody there "owns" the development environment. Or maybe it's just a product management miss. In any case, you guys have a real problem until something -- anything -- can reliably replace the creaky old ISE.

I realize I'm throwing rocks at a project that I'm not contributing to. But I'm a pwsh fan and recommend it highly to enterprises migrating to cloud so that the infrastructure staff can adopt a procedural language and when a declarative language like JSON is a bridge too far.

It's this opportunity I think the vscode extension is missing: catering to legions of admins (for whom pwsh was originally designed) who need to work in the cloud in a "comfortable" way. Asking them, non-devs who last week were racking servers and who are struggling to become full-stack cloud infrastructure engineers -- who must learn coding basics like git and debugging on the job, to use the combo of vscode and this extension in its current state is to doom them to failure.

[DarkLite1]

@yobyot I completely understand your point of view. I've had a similar feeling about using vscode to write PowerShell code in the past. That's why I opened 31555 to make PowerShell a fist class citizen of vscode.

Anyway, back to the issue at hand. The debugger should indeed not be polluted with inexplicable errors. @rjmholt can you tell us when improvements on this can be expected?

I'd also like to point out there are a lot of great people working on the PowerShell extension, PSReadline and the vscode internals like @rkeithhill @daviwil @TheIncorrigible1 @SeeminglyScience @TylerLeonhardt and many others. It's great to see the community working together to achieve something amazing. We're still not at the quality level of the PowerShell ISE but I can see that we're getting there slowly. Thanks guys for the great help already.

[SeeminglyScience]

I'm gonna quote a comment I wrote awhile ago about this:

That error is expected when debugging a script where a frame in the call stack is within a module. The number of scopes iterated when getting variables is based on the number of frames in the call stack. But because each SessionState has it's own stack of SessionStateScopes, so the amount of scopes does not equal the amount of frames in a call stack.

A possible fix would be to check the module of the command listed in the scope with frame.InvocationInfo.MyCommand.Module, but invoking Get-Variable in a different session state than the current EngineSessionState is tricky. If the session state belongs to a module we could do . $module { Get-Variable -Scope x }, but there's no publicly accessible way to get the top level session state. Even if we could get the top level session state, the only way to invoke a script within that session state is to create a fake module object and set it's session state.

$fakeModule = [psmoduleinfo]::new($false)
$fakeModule.SessionState = $topLevelSessionState
. $fakeModule { Get-Variable -Scope x }

But that's probably not intended behavior and is likely as dangerous as reflection.

All that said, this error is caught and wouldn't cause any crashes, we just don't get as much info for each frame as we'd like.

The issue is more complicated than it appears, and is mostly due to limitations in the engine. The fix I proposed (if it would even work) would be pretty time consuming to write. I typically only advise $Error to be used for interactive troubleshooting as it's very inconsistent. Modules can write to it, but not read it, event subscribers as well. Breakpoint actions can also pollute the error list.

You can get similar functionality from the -ErrorVariable common parameter. That will be the same type of list, but it will be limited to the errors generated within the command you use it on.

That's not to say that there is nothing to fix here, just that it's not particularly easy to fix with the PowerShell API's we have today.