PowerShell attach removes existing breakpoints in attached session

[nightroman]

Prerequisites

• I have written a descriptive issue title.
• I have searched all open and closed 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.
• If this is a security issue, I have read the security issue reporting guidance.

Summary

I use VSCode PowerShell debugger by attaching to a process hosting PowerShell.
Attaching removes breakpoints that I have already set in my session.

PowerShell Version

Name                           Value
----                           -----
PSVersion                      7.3.3
PSEdition                      Core
GitCommitId                    7.3.3
OS                             Microsoft Windows 10.0.19045
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.73.1
6261075646f055b99068d3688932416f2346dd3b
x64

Extension Version

[email protected]

Steps to Reproduce

(1) Invoke the below script test1.ps1 in some PowerShell session. E.g. I used and saw the problem in powershell and pwsh consoles and in my application hosting PowerShell as well.

function global:test1 {
	'hi'
}
Set-PSBreakpoint -Command test1
Set-PSBreakpoint -Script $PSScriptRoot\test1.ps1 -Line 2

(2) Run Get-PSBreakpoint -- see 2 breakpoints

(3) In VSCode, launch/attach PowerShell debugger configured as below.
Select the target process where we have set 2 breakpoints.

      {
        "type": "PowerShell",
        "request": "attach",
        "name": "PowerShell attach",
        "processId": "${command:PickPSHostProcess}",
        "runspaceId": 1
      },

(4) With the debugger attached, run Get-PSBreakpoint again -- see that breakpoints are gone.

Visuals

No response

Logs

No response

[andyleejordan]

Unfortunately that's currently just how it works until we finish #4065. So consider this in progress!

[nightroman]

@andschwa Noted, thank you. Looking forward to the progress and improvements.

FWIW, I believe (strongly) it used to work fine, breakpoints were not removed. That was my usual workflow - set breakpoints in the app, then start VSCode debugging. Granted, it was some time ago. Maybe newer versions are "not supposed to work" due to their new tech issues.

[andyleejordan]

Hard to say if/when the behavior changed. As far as I remember the debugger has always issued a "clear breakpoints" command on startup, but it's a project with a looong history.

[nightroman]

Some sort of proof, my user manual -- https://github.com/nightroman/FarNet/tree/main/PowerShellFar#debugging

Select this debugger as active and start (F5). In the shown list of processes hosting PowerShell select Far Manager. Assuming you have set some breakpoints (in Far Manager, not VSCode), run your PowerShellFar code. If breakpoints are hit then VSCode debugger opens the source code at the active breakpoint.

[nightroman]

Updated the manual and gave the users some hope :)

With the latest VSCode and PowerShell breakpoints set in Far Manager are
removed when VSCode debugger attaches. If you experience this issue, set
breakpoints in VSCode instead. Hopefully, this issue will be fixed, #4489.

[SeeminglyScience]

Yes I think at one point it "worked" in that it just didn't try to manage breakpoints in the remote session at all. Or at most just repeatedly set the same breakpoints every time you attached. I know it's not the best for your scenario but the old behavior leads to some pretty wonky UX if you are trying to set breakpoints in the UI.

As Andy said though, #4065 should make the behavior more consistent (and I'll be returning to it shortly). I don't think I touch existing breakpoints in remote sessions.

[nightroman]

FWIW, PowerShellFar (Far Manager PS host) takes care of breakpoint updates via events, i.e. breakpoints set by a user in UI, or by commands, or, as I can see, even set in VSCode after attaching the debugger.

[SeeminglyScience]

Then once that PR is in, breakpoints should automatically sync in both UI's regardless of where they're added 🤞

[nightroman]

Anyway, it's good to know that issue is known and addressed, one way or another. I'll adjust.

[nightroman]

Hello, with the recent development on fixing the debugger (https://github.com/PowerShell/vscode-powershell/releases/tag/v2024.3.0-preview), is there any chance this issue gets some progress?

[andyleejordan]

That work is happening with #4065 which is still in progress.

[nightroman]

@andyleejordan It looks a little stagnated though, for a not involved observer. But I hope that "in progress" is the true status and I look forward for the fix. This is needed for some known practical scenarios, when BPs are set in a custom IDE before starting VSCode debugging.

[nightroman]

FWIW, not complaining about anything, but please take a look at the manual for my users on using VSCode PowerShell debugger. You might and should be interested in the section "Known issues" (4). It's a lot of pain to make it working, apart from configuring, and IMHO many users will never enjoy VSCode PowerShell debugging by attaching (which actually works at this point, wow!).

https://github.com/nightroman/FarNet/wiki/PowerShellFar-debugging

[JustinGrote]

@nightroman it's a very tricky PR and @SeeminglyScience who owns it has been on leave for a bit. It is moving forward however.

[Kaled1992]

  {
    "type": "PowerShell",
    "request": "attach",
    "name": "PowerShell attach",
    "processId": "${command:PickPSHostProcess}",
    "runspaceId": 1
  },

[Kaled1992]

{
"type": "PowerShell",
"request": "attach",
"name": "PowerShell attach",
"processId": "${command:PickPSHostProcess}",
"runspaceId": 1
},