vscode-powershell: Debugging with active breakpoint crashes Powershell session

Prerequisites

  • I have written a descriptive issue title.
  • I have searched all issues to ensure it has not already been reported.
  • I have read the troubleshooting guide.
  • I am sure this issue is with the extension itself and does not reproduce in a standalone PowerShell instance.
  • I have verified that I am using the latest version of Visual Studio Code and the PowerShell extension.

Summary

Powershell session crashes in preview extension when attempting to debug a script with active breakpoint in unsaved file. Debugging the same code in a saved file works.

Also occurs when debugging Pester tests, but was able to reproduce the same exception in this simpler demo so I believe it might be the same root cause.

PowerShell Version

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

Visual Studio Code Version

1.62.0-insider
b3318bc0524af3d74034b8bb8a64df0ccf35549a
x64

Extension Version

ms-vscode.powershell-preview@2021.11.0

Steps to Reproduce

  1. Open a new unsaved file with content $a = 1
  2. Place a breakpoint on the line and launch/debug file as normal

Visuals

Repro pses3-debug-crash

Exception 115

Logs

No response

About this issue

  • Original URL
  • State: closed
  • Created 3 years ago
  • Reactions: 1
  • Comments: 20 (3 by maintainers)

Most upvoted comments

I can consistently reproduce if you:

  1. Start a debug session (I use start interactive session)
  2. Run a pester test

I get the same scopes issue. Doesn’t happen if you don’t have a debug session started.

Agreed, @andschwa there should be a broad catch for all otherwise-uncaught pwsh invocation exceptions that logs the exception occurred but doesn’t kill PSES (or at the very worst auto-restarts it)

I think I found the problem. This seems to assume the stacktrace length is the same as the number of variable scopes, which is going to not be true if any assemblies are involved I think. image