Debugger Issues

[strickdd]

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 have verified that I am using the latest version of Visual Studio Code and the PowerShell extension.

Summary

REF: #3394 (comment)

After attempting to resolve my issue with the pre-release version of the extension, the debugger started failing again. Per @rjmholt 's suggestion, I am opening a new issue for tracking.

PowerShell Version

Both PS 5.1 and 7 have issues.

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


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

Visual Studio Code Version

1.59.1
3866c3553be8b268c8a7f8c0482c0c0177aa8bfa
x64

Extension Version

ms-vscode.powershell@2021.8.0
ms-vscode.powershell-preview@2021.8.1

Steps to Reproduce

Scenario 1 (PowerShell 5.1)

1. Close all VSCode instances
2. Open new instance with no folder opened
3. Create a new PowerShell script
4. Past in script below (do not save)

function Write-SomeStatus {
    # Breakpoint on following line
    Write-Host 'Some Status'
}

Write-SomeStatus

5. Press F5

Expected: Breakpoint is hit
Actual: Breakpoint is skipped and script contents + "Some Status" is written to terminal

Scenario 2 (PowerShell 5.1)

1. Save the script from Scenario 1 to C:\temp\DebuggingTest.ps1
2. Readd the breakpoint to line 3 (as indicated)
3. Press F5
4. Debugger starts and attaches correctly
5. Press F5 to run to completion
6. Run Write-SomeStatus from the terminal directly
7. Debugger attaches to breakpoint at line 3
8. Press F5 to continue and the debugger hangs (screenshot below)

Visuals

Debugger attaches when adding new Write-Host line:

Debugger hangs after calling from terminal directly:

Logs

EditorServices.log
StartEditorServices.log
vscode-powershell.log

[andyleejordan]

Did you try v2021.8.2-preview? There was an issue in v2021.8.1-preview where the debugger "hung" waiting for an enter to actually cancel PSReadLine, #3513.

[strickdd]

Updated to v2021.8.2-preview

ms-vscode.powershell@2021.8.0
ms-vscode.powershell-preview@2021.8.2

Now, here are the results:

Scenario 1 (PowerShell 5.1)

No change, still does not hit the breakpoint

Scenario 2

No change, still hangs with the debug toolbar showing. Pressing "enter" does not continue on or close the debug toolbar

Logs from current run

EditorServices.log
StartEditorServices.log
vscode-powershell.log

[andyleejordan]

Scenario 1 reproduces for me; however, I'd point out that this is debugging an unsaved script. @rjmholt is that something we actively support? I'm not sure how we would, as there is no script file name to pass to the debug adapter.

Scenario 2 also reproduces for me; however, this is again a strange scenario: it's using the PowerShell debugger in the integrated console to start the debugger (which does somehow cause VS Code to recognize the debugger is running), but then when it ends the VS Code debugger doesn't know that the debugging session has finished. @rjmholt is this also something we actively support?

[strickdd]

Scenario 1:
Ref for unsaved debugging:

• https://github.com/PowerShell/vscode-powershell/releases/tag/v2021.5.1
• Don't prompt to save untitled PowerShell files when debugging #3357

Scenario 2:
This is something ISE has always supported, and I believe VSCode has allowed me to do since I switched over. However, I can't confirm how long VSCode has had this functionality.

[andyleejordan]

Digging into this a little bit, Scenario 1 is explicitly only supported in PowerShell 7 and up. It requires the PowerShell breakpoint APIs, which are not available in PowerShell 5.1. And this scenario's issue does not reproduce with PowerShell 7. This should probably be documented somewhere, I found it by looking through PSES.

But I don't understand why that message isn't in your log. I think it's a bug; we should not just emit a warning in the log but we should actively inform the user when you try to debug an untitled file with PowerShell 5.1 that it won't work. And we need a test for that. Moreover, we also need a test that it does work in PowerShell 7.

[strickdd]

Retried Scenario 1 under PS 7 with a slight difference. I modified and debugged an existing file, but did NOT save the file before debugging.

Debugging started, pressed F5, and it entered a "weird" PS file and stops there

Pressing F5 again, I get to another file, but the debugger is "hung"

After it was hung, I pressed the "stop" button on the toolbar and cannot start the debugger anymore. The debug toolbar comes up, but doesn't hit the breakpoint.

[andyleejordan]

I could see Scenario 2 as something that "just worked" in the past. It's good to know that this is functionality you want; it's sad that we did not have tests for it. Because now we'll have to fix it and this time add regression tests. I confirmed it reproduces with both PowerShell 7 and 5.1.

[andyleejordan]

Retried Scenario 1 under PS 7 with a slight difference. I modified and debugged an existing file, but did NOT save the file before debugging.

You should probably save your file before debugging. Again, not sure if that's something we actively support. Breakpoints are set on files with line numbers. In the case of untitled files, I'm not sure how that's implemented; I imagine VS Code is creating a pseudo file for us. The original implementation looked like it guessed that a file was unsaved, and then passed the buffer contents to the debugger directly, which is fragile and probably not how it's done using O#.

[rjmholt]

@rjmholt is that something we actively support?

I didn't think it was in PS 5.1 because there was a whole discussion about the API to support it in PS 7. But our behaviour should do something like reject the breakpoints.

Scenario 2

Is the debugger hanging or just staying on? What is your debug configuration that's running when you hit F5? A PowerShell Interactive Session is supposed to effectively stay open.

The big difference between VSCode and the ISE is VSCode's debug protocol and that fact that its debug client owns the session. So in the ISE, you could place a breakpoint in a file from the UI, hit it from the integrated console and drop into the debugger.

In VSCode, breakpoints placed in the UI only get sent over to the server when the debug client starts, so you'd place a breakpoint, the server would never get told, you'd hit it from the console and no debugger. For that reason the PowerShell Interactive Session was invented, where the debugger is always on, so PSES always gets updated with UI breakpoints. But then your debug session never ends...

Some related issues:

• ISE like breakpoint behaviour (hit breakpoints when running a script from the integrated terminal) #2159
• Reset Session before launching debugger #2411
• Breakpoints not cleaned up if Debug Interactive Session is stopped. #2371
• Debug Session not respecting Added or removed Breakpoints & Integrated Shell Crash #1494
• Break point 'breaks debugging' when disabled during execution #1166

[SeeminglyScience]

In the case of untitled files, I'm not sure how that's implemented; I imagine VS Code is creating a pseudo file for us.

It's identified in VSCode with an ID like untitled:Untitiled-x where x is in incrementing number. On the PowerShell end the Parser.ParseInput(string input, string fileName, ...) overload is used which can attach any arbitrary string to Ast.Extent.File (which is what the engine uses to match line breakpoints to a "file")

[andyleejordan]

I didn't think it was in PS 5.1 because there was a whole discussion about the API to support it in PS 7. But our behaviour should do something like reject the breakpoints.

For what it's worth, it does reject the breakpoint (kind of). It shows up as "unverified" in the editor.

[rjmholt]

For what it's worth, it does reject the breakpoint (kind of). It shows up as "unverified" in the editor.

Yeah that's what I imagined it should do. We still execute the file (since we can) but communicate that we won't honour the breakpoint

[andyleejordan]

In VSCode, breakpoints placed in the UI only get sent over to the server when the debug client starts, so you'd place a breakpoint, the server would never get told, you'd hit it from the console and no debugger. For that reason the PowerShell Interactive Session was invented, where the debugger is always on, so PSES always gets updated with UI breakpoints. But then your debug session never ends...

That sounds like this is working as expected then? To be honest, I've never used the "PowerShell Interactive Session" debugger before 😅

[rjmholt]

That sounds like this is working as expected then?

Depends on @strickdd's debug configuration

[SeeminglyScience]

It's also worth noting that there is support for debug sessions triggering outside of that debug config option. For example, if you just type Wait-Debugger in the PSIC it'll trigger a debug session on the VSCode side.

Even though line breakpoints don't come through automatically, it's still a very useful feature with variable/command breakpoints (and Wait-Debugger).

[andyleejordan]

It's also worth noting that there is support for debug sessions triggering outside of that debug config option. For example, if you just type Wait-Debugger in the PSIC it'll trigger a debug session on the VSCode side.

Even though line breakpoints don't come through automatically, it's still a very useful feature with variable/command breakpoints (and Wait-Debugger).

How do you get the VS Code side to detach and end debugging after this session? That seems to be what's not working.

[strickdd]

Another weird thing is happening as I started testing more.

working scenario

1. Open file C:\temp\DebuggingTest.ps1 (created in scenarios above)
2. Set breakpoint at line 3
3. Press F5
4. Breakpoint is hit
5. Press F5 to continue

Functions as expected

Weird debugging experience

This was alluded to above, but I'm able to consistently reproduce

1. Moved file from C:\temp\DebuggingTest.ps1 to 'C:\Users\dstricke\OneDrive - Myriad Genetics\Coding\Scratch\DebuggingStuff\PSExtensionDebugTesting.ps1'
2. Opened folder 'C:\Users\dstricke\OneDrive - Myriad Genetics\Coding\Scratch\DebuggingStuff'
3. Set breakpoint to line 3
4. Press F5
5. Breakpoint is hit
6. Press F5 to continue

Expected: Debugger exists cleanly
Actual: New breakpoint is hit in a weird file: 'C:\Users\dstricke\AppData\Local\Temp\PSES-86724[MN-DSTRICKER1] Script Listing.ps1'

Pressing F5 at this point brings me to the file with "0" as the content: 'C:\Users\dstricke\AppData\Local\Temp\PSES-86724[MN-DSTRICKER1] Script Listing.ps1'

The debugger toolbar hangs around (see screenshot at bottom), but has the additional dropdown, unlike the other screenshots.

After this, I cannot hit F5 to debug again, ever after clicking the "Stop" square on the toolbar. Terminal is locked up and will not take any input. I have to kill the Powershell Integrated Console and select "Yes" to restart to debug again. Same thing happens next time I try.

EditorServices.log
StartEditorServices.log
vscode-powershell.log

[SeeminglyScience]

How do you get the VS Code side to detach and end debugging after this session? That seems to be what's not working.

Was about to edit with:

It does look like this no longer tells VSCode that the debug session has ended though.

😀

iirc when I was hooking that up to the PSRL integration it was done via a runspace availability event handler... If it's still set up that way it may be a good idea to look for a better pattern when attempting a fix. I can take a look in a couple of hours.

[andyleejordan]

Another weird thing is happening as I started testing more.

@strickdd You keep saying you "Press F5" but we really need to know: what debug configuration is this running?

[andyleejordan]

Changing the labels as at this point I don't think there's an extant bug. There's definitely room for improvement (throwing a more visible message when adding a breakpoint to an untitled file when using PowerShell 5.1, and somehow signaling "end debugging" to the editor when a script has stopped running if the debugger was started from PowerShell), but especially that latter one, it would need to be a user setting, and may not even be possible.

[strickdd]

Another weird thing is happening as I started testing more.

@strickdd You keep saying you "Press F5" but we really need to know: what debug configuration is this running?

Happy to provide you this information; how do I pull the debug configuration so I can provide it?

Here is my current settings.json, incase this helps:

{
    "editor.find.autoFindInSelection": true,
    "editor.minimap.maxColumn": 60,
    "editor.mouseWheelZoom": true,
    "editor.renderWhitespace": "all",
    "editor.tabCompletion": "on",
    "window.doubleClickIconToClose": true,
    "window.newWindowDimensions": "maximized",
    "window.restoreFullscreen": true,
    "window.restoreWindows": "all",
    "files.defaultLanguage": "powershell",
    "search.usePCRE2": true,
    "git.ignoreMissingGitWarning": true,
    "powershell.codeFormatting.useCorrectCasing": true,
    "editor.formatOnPaste": true,
    "workbench.activityBar.visible": true,
    "debug.openDebug": "neverOpen",
    "workbench.colorTheme": "Visual Studio 2019 Dark",
    "powershell.promptToUpdatePowerShell": false,
    "diffEditor.ignoreTrimWhitespace": false,
    "powershell.codeFormatting.autoCorrectAliases": true,
    "powershell.codeFormatting.preset": "Stroustrup",
    "powershell.codeFormatting.trimWhitespaceAroundPipe": true,
    "powershell.codeFormatting.whitespaceBetweenParameters": true,
    "powershell.codeFormatting.alignPropertyValuePairs": false,
    "editor.autoSurround": "never",
    "terminal.integrated.fontFamily": "Cascadia Mono PL",
    "powershell.enableProfileLoading": false,
    "gitlens.views.repositories.branches.layout": "list",
    "vtools.autoHideSideBar": true,
    "powershell.powerShellDefaultVersion": "PowerShell (x64)",
    "powershell.integratedConsole.forceClearScrollbackBuffer": true,
    "window.title": "${dirty}${rootName}${separator}${activeEditorShort}${separator}${appName}",
    "workbench.startupEditor": "welcomePage",
    "editor.detectIndentation": false,
    "powershell.codeFormatting.useConstantStrings": true,
    "powershell.developer.editorServicesLogLevel": "Diagnostic",
}

[andyleejordan]

Happy to provide you this information; how do I pull the debug configuration so I can provide it?

In VS Code, "F5" launches your current debug configuration. You'll want to go to the debug panel and show us what you have set there. It will be one configuration out of potentially many options in your launch.json. For example, in the screenshot in the docs here it's "Launch Program" which is the value for the name field in their sample launch.json file. It may very well be a default/automatic debug configuration you're using, but the extension provides several of those (Launch File, Launch Script, Interactive Session, to name a few).

[andyleejordan]

I think it's possible but it seems very fragile, and I don't see much gain from it. There are certainly users who wouldn't want it to automatically stop, so then we'd need to make it configurable, and anyway the action of "click the stop button" doesn't seem to be a huge issue.

[SeeminglyScience]

I don't feel strongly enough about it to press the issue, all I ask is that it's kept in mind when reviewing feedback. I have a feeling it's one of the things that contribute to a general perception of jank that most users would have difficulty articulating. Even with a pretty good understanding of how it all works I thought it was a bug 🤷

But yeah I agree, at face value having to hit stop or ctrl f5 every now and then is nbd

[andyleejordan]

I think that's totally fair. It certainly took understanding it for it to make any sense at all, but then it became clear why it's that way and why it may not be fixable. It's that we've tied two debuggers together, and the protocol we used to do so (DAP) doesn't know the first debugger also has its own UI (the Wait-Debugger etc. commands).

[SeeminglyScience]

and the protocol we used to do so (DAP) doesn't know the first debugger also has its own UI (the Wait-Debugger etc. commands).

That is a UI that we provide though. I'm probably going to over explain so please ignore what you already know and apologies:

When the engine hits a debug stop it invokes an event that the PSHost is expected to subscribe to. It's the PSHost's job handle rendering a nested repl, debug messages, and when to resume execution, etc. The PSHost in PowerShellEditorServices is what handles all that currently, and it's how we can control PowerShell's debugger via DAP in general. That's also how we start the debugger on an arbitrary stop, we just don't handle ending it as well.

Basically, if we were to add something like this here:

    if (!IsDebugServerActive)
    {
        _didStartArbitraryDebug = true;
        _languageServer?.SendNotification("powerShell/startDebugger");
    }

And then something like this here:

if (IsDebugServerActive && _didStartArbitraryDebug && PromptNest.CurrentFrame.FrameType is PromptNestFrameType.Normal)
{
    // Notification would need to be added
    _languageServer?.SendNotification("powerShell/stopDebugger");
}

return executionResult;

Should work pretty reliably I think. Anyway, food for thought.

[liberdis]

I came here trying to make heads or tails of the wide variety of odd behavior the 1.59.1 update seems to have brought my 5.1 debugging experience. Fairly consistently now in my module (no unnamed files) when i hit a breakpoint and then F5 to continue my integrated console hangs. This can't possibly be by design, I have tried clicking all the "stop" buttons to no avail

[andyleejordan]

@liberdis do you think you might have the same issue(s) as #3539?

[andyleejordan]

@SeeminglyScience what exactly is && PromptNest.CurrentFrame.FrameType is PromptNestFrameType.Normal checking, and is there an alternative? I've started an attempt to implement this and "'PromptNest.CurrentFrame' is inaccessible due to its protection level."

[andyleejordan]

Yeah...this did not quite work. I'll see if I can figure it out but unfortunately I think it's going to be a bit more complicated than just adding that code at the end of ExecuteCommandAsync.

[SeeminglyScience]

NestedPromptLevel is 1 is probably better anyway.

Basically it's just checking that the current REPL isn't for a debugger stop, a remote runspace, or a nested prompt.

[andyleejordan]

!PromptNest.IsInDebugger is what we were looking for, but even with that, it's not quite working.

[SeeminglyScience]

Roger that, I'll take a crack at it this weekend and see if it's feasible

[andyleejordan]

I seem to be sending the notification too soon...I'll take a look in the morning. It is stopping the debugger now, just it's doing so immediately after the breakpoint is hit. So it starts and then stops.

[SeeminglyScience]

Yeah that might not be the best place for the check. It's possible that it's firing right after some of the pre-debugger REPL stuff like setting breakpoints. Right now we'd be setting it once it returns to the "normal" prompt in the stack, but that doesn't necessarily mean that execution is resumed (and ofc very often doesn't mean execution is finished). Maybe the check should be when ReadLine is called? Or in an execution status event handler?

[andyleejordan]

Hey...it's a-working. It just might be a bit fragile (and it needs tests).

[andyleejordan]

@strickdd Can you test out the preview extension that updated yesterday for Scenario 2? I believe I've lit that feature up, but still working on a way to thoroughly cover it in tests.

[andyleejordan]

This change got dropped in the pipeline rewrite, so I am reopening this. The good news is that I also just fixed that!