Powershell debugger hangs stepping over a script invocation

Issue Type: Bug

1. Open a script with the following contents

Set-StrictMode -Version 5
$ErrorActionPreference = "Stop"
. $PSScriptRoot\test2.ps1
"hello 3"

1. In test2.ps1, put literally anything (e.g. “hello from test2.ps1”, or even blank or non-existant).
2. Put a breakpoint on line 3 (test2.ps1 invocation)
3. Hit F5
4. When it breaks hit F10

Result: debugger will never return. You have to stop it and restart the integrated powershell instance.

Note: If either of the first two lines are commented out, i.e. without either Set-StrictMode OR $EAP = “Stop”, it seems to work The combination causes fits.

Note 2: If there are no breakpoints, it seems to work then as well.

Extension version: 2020.4.0 VS Code version: Code 1.45.1 (5763d909d5f12fe19f215cbfdd29a91c0fa9208a, 2020-05-14T08:27:35.169Z) OS version: Windows_NT x64 10.0.19635

System Info

Item	Value
CPUs	Intel® Core™ i7-8700K CPU @ 3.70GHz (12 x 3696)
GPU Status	2d_canvas: enabled flash_3d: enabled flash_stage3d: enabled flash_stage3d_baseline: enabled gpu_compositing: enabled multiple_raster_threads: enabled_on oop_rasterization: disabled_off protected_video_decode: enabled rasterization: enabled skia_renderer: disabled_off_ok video_decode: enabled viz_display_compositor: enabled_on viz_hit_test_surface_layer: disabled_off_ok webgl: enabled webgl2: enabled
Load (avg)	undefined
Memory (System)	31.78GB (15.85GB free)
Process Argv	–folder-uri file:///c%3A/repos/devdir
Screen Reader	no
VM	0%

[oliverroer]

I have had this issue today as well.

After looking at the log, I realized what caused it - at least in my case.

In my case, I had a variable in the watch window, which wasn’t initialized.

For example, I can run the following script to produce the issue:

Set-StrictMode -Version 2.0
$ErrorActionPreference = "Stop"

Write-Host "Hello World"

With my watch set like this:

I can set a breakpoint on the first line and step through the script. As soon as I’ve stepped over the first two lines and try to step to the Write-Host line, the debugger freezes.

StrictMode version 1.0 and onwards lists the following:

Prohibits references to uninitialized variables, except for uninitialized variables in strings.

So I guess setting any version of StrictMode combined with $ErrorActionPreference='Stop' will cause issues when setting a watch on a variable that doesn’t exist.

Here’s what I saw in my log that helped me spot the issue:

2020-12-15 08:31:32.157 +01:00 [ERR] Execution of the following command(s) completed with errors:

    $Name

Error #1:
The variable '$Name' cannot be retrieved because it has not been set.
ScriptStackTrace:
at <ScriptBlock>, C:\devops\coric-engage-blueprints\freeze.ps1: line 2
Exception:
   System.Management.Automation.RuntimeException: The variable '$Name' cannot be retrieved because it has not been set.
   at System.Management.Automation.VariableOps.GetVariableValue(VariablePath variablePath, ExecutionContext executionContext, VariableExpressionAst varAst)
   at System.Management.Automation.Interpreter.FuncCallInstruction`4.Run(InterpretedFrame frame)
   at System.Management.Automation.Interpreter.EnterTryCatchFinallyInstruction.Run(InterpretedFrame frame)
2020-12-15 08:31:32.159 +01:00 [VRB] Attempting to execute command(s):

    prompt

It would be nice to have a fix for this. It would be great for the watch to check if the variable exists first, and if not, just write something like $Name: uninitialized or something like that, rather than blindly trying to read it and getting locked up. 😄

[andschwa]

I have had this issue today as well.

After looking at the log, I realized what caused it - at least in my case.

In my case, I had a variable in the watch window, which wasn’t initialized.

For example, I can run the following script to produce the issue:

Set-StrictMode -Version 2.0
$ErrorActionPreference = "Stop"

Write-Host "Hello World"

With my watch set like this:

I can set a breakpoint on the first line and step through the script. As soon as I’ve stepped over the first two lines and try to step to the Write-Host line, the debugger freezes.

StrictMode version 1.0 and onwards lists the following:

Prohibits references to uninitialized variables, except for uninitialized variables in strings.

So I guess setting any version of StrictMode combined with $ErrorActionPreference='Stop' will cause issues when setting a watch on a variable that doesn’t exist.

Here’s what I saw in my log that helped me spot the issue:

2020-12-15 08:31:32.157 +01:00 [ERR] Execution of the following command(s) completed with errors:

    $Name

Error #1:
The variable '$Name' cannot be retrieved because it has not been set.
ScriptStackTrace:
at <ScriptBlock>, C:\devops\coric-engage-blueprints\freeze.ps1: line 2
Exception:
   System.Management.Automation.RuntimeException: The variable '$Name' cannot be retrieved because it has not been set.
   at System.Management.Automation.VariableOps.GetVariableValue(VariablePath variablePath, ExecutionContext executionContext, VariableExpressionAst varAst)
   at System.Management.Automation.Interpreter.FuncCallInstruction`4.Run(InterpretedFrame frame)
   at System.Management.Automation.Interpreter.EnterTryCatchFinallyInstruction.Run(InterpretedFrame frame)
2020-12-15 08:31:32.159 +01:00 [VRB] Attempting to execute command(s):

    prompt

It would be nice to have a fix for this. It would be great for the watch to check if the variable exists first, and if not, just write something like $Name: uninitialized or something like that, rather than blindly trying to read it and getting locked up. 😄

This is not a bad idea at all, I’ll see what I can do.