Calling Set-PSBreakpoint in console doesn't cause breakpoint icon to appear in file

[daviwil]

We need to send a BreakpointEvent back to the debugger client when new breakpoints are added in the session via the Set-PSBreakpoint cmdlet. I've got an implementation working but it's currently blocked by a bug in VS Code (microsoft/vscode#24164) which causes all other breakpoints in the file to be cleared when the BreakpointEvent is received.

[daviwil]

Here's the commit with the current work: daviwil/PowerShellEditorServices@5beeba1

[nightroman]

And the opposite is true, in a way. Namely,

• set a breakpoint by F9 is a script
• in the terminal invoke Get-PSBreakpoint

As a result, the BP is not in the output.
Also, if I invoke this script from the terminal then the BP is not hit.

Is it the related issue or should I open another?

[daviwil]

I don't think there's an issue for it specifically right now, but this is actually a problem with VS Code's debugger model. When you click a breakpoint in a file when the debugger isn't running, they don't send me any notification that the breakpoint was created. They wait until the user starts the debugger before sending the breakpoints to my debug server. I'm trying to get them to expand their model to support scenarios like this but it's a slow process.

[nightroman]

I am looking forward to this development. It's probably too early to file all hiccups in debugging.

I am playing with some useful scenarios in VS Code debugger, e.g. automatically breaking into the debugger and opening scripts on terminating errors at the point of failure. It's promising but not quite reliable yet.

[daviwil]

Definitely not too early! File everything that you run across that doesn't work well for you, I'm hoping to polish out most of the issues over the next couple of months.

[nightroman]

All right, I will create some issues then after a while when I get more facts.

[daviwil]

Thanks Roman!

[nightroman]

Here is the just published little debugging tool with the steps described in its comments:
https://www.powershellgallery.com/packages/Debug-Error

It works. But sometimes with some combination of factors it does not...

[daviwil]

That's really clever! You know, VS Code has a setting to break on exceptions that we can plug into. Would you be interested in contributing this approach as a feature in PSES and the PowerShell extension?

[nightroman]

Why not? Let see how it works (hoping for some feedback). I am still playing with this and trying to use in Invoke-Build tasks troubleshooting in VSCode. To be honest, I started to use VSCode just recently because I was happy with my own sort of script IDE, PowerShellFar for Far Manager.

[rkeithhill]

I've been waiting on @PaulHigin to add the ability to break on unhandled terminating error and it hasn't happened yet AFAIK. This could be interesting way point until we get the built-in support in the debugger.

[daviwil]

Yep, I think this could work in enough scenarios to satisfy the need in the short term, and on older PowerShell versions.

Roman, feel free to send an e-mail anytime with questions about how to get this hooked up. I'm looking for the docs on the high level details right now, I'll pass them along to you soon.

[daviwil]

Looks like the debug adapter protocol wants us to return the exceptionBreakpointFilters capability when it asks us to initialize so that it shows an exception breakpoint option in the UI:

We're returning this capabilities object here:

https://github.com/PowerShell/PowerShellEditorServices/blob/master/src/PowerShellEditorServices.Protocol/Server/DebugAdapterBase.cs#L59

Looks like we'd need to specify an ExceptionBreakpointsFilter, possibly called "Unhandled Script Errors", which would enable an additional checkbox in the "Breakpoints" UI with that name.

If the user checks it, VS Code will send us the SetExceptionBreakpointsRequest which we haven't added to our message classes yet.

Once we receive that message, we could run your breakpoint code inside of the runspace to enable the variable breakpoint on StackFrame. When we hit that type of breakpoint we'll need to be aware of it so that we can return a reason value of exception in the StoppedEvent.

That was a fast overview, feel free to ask questions about any of those steps :)

[daviwil]

Also related to #625.