You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Debug Support for Any Exceptions and Uncaught Exceptions #298
This is a fairly common request and something we have in our backlog, but is impossible to implement with our current script debugger. The reason is that the script debugger runs on the script execution thread and requires running script to work. But once an exception is thrown on the script execution thread the script is no longer running and the script debugger no longer works. At this point you need a managed/native debugger. We could have script debugger break for non-terminating errors since script execution continues and the script debugger is working. But I am not sure how useful that would be.
Jason, Jason Shirk (@lzybkr), has experimented with a mixed managed code/script debugger and it would be ideal for this kind of thing. When the managed exception is thrown this debugger could show both managed and PowerShell script stacks.
Very clever. I like it. But I believe this just handles the case where PowerShell is throwing the exception (either through throw keyword or -ErrorAction Stop). Jason Shirk (@lzybkr) can you confirm? I was thinking in terms of a general exception being thrown in managed code. Still this looks to be very useful and something we could support internally.
Unfortunately, Debug-Error.ps1 does not show the error itself, it just breaks into the debugger. The error has not been written yet (i.e. added to $Error) by PowerShell. So you have to guess what has happened. Sometimes this is clear, sometimes not. The tool is useful in special cases, rather rare.
Any movement on this? At the moment I'm reduced to stepping through my module (and all of its dependencies) line by line trying to find where the exception is being thrown. Or adding a load of Write-Host statements to see which ones get hit.
After $StackTrace is written to, $ErrorActionPreference is checked to see if the error should be terminating. When it checks $ErrorActionPreference it has already written to $Error regardless of the preference value.
For this to be reliable you would need to store state between the two breakpoints to ensure they fire on the same sequence point (in case the script later reads the preference directly). It would also need to handle situations where the break point already exists and be able to remove itself after the first hit.
I'll start looking into the feasibility of adding support for this.
since unlike other error actions it would need to search up the stack to determine if it's going to be caught or not. Honestly that's a pretty complex behaviour.
My thought here is to add something to the compiler to emit something when processing a TryStatementAst that would allow tracking this easier. Still pretty complex but would be incredibly useful.
Edit: You were talking about Stop, not a hypothetical BreakOnUncaughtOrSomething. Oops
Jason, Jason Shirk (@lzybkr), has experimented with a mixed managed code/script debugger and it would be ideal for this kind of thing. When the managed exception is thrown this debugger could show both managed and PowerShell script stacks.
I noticed this comment because I'm looking for a way to step through C# in my own PS module (dll) called by PowerShell script being debugged in vscode-powershell. At the moment I can't debug the PowerShell and C# together so Jason Shirk (@lzybkr) if you ever chose to make available something that supports this I'd be grateful for one. 😊
Mark Murphy (@markm77) you are able to have the PowerShell debugger and C# debugger running at the same time.... so feasibly you can launch debug a PowerShell script and attach the C# debugger... but it doesn't give you the ideal behavior of "stepping into C# from PowerShell".
Mark Murphy (@markm77) - mixed debugging is a little painful but possible today if you attach a C# debugger, set breakpoints where you care about, then debug the PowerShell code with the PowerShell debugger. You don't get a nice shared stack but it's better than nothing.
My prototypes were based on the Desktop version of .Net, I have no idea if they are even possible now.
Thanks guys for interesting comments. To do mixed debugging do I have to re-attach the debugger each time the PowerShell script calls into a C# module cmdlet? Or can I attach the debugger just once following module import and it will re-attach as the DLL is called (much better)?
Also is there any recommended way for dropping the lock on the DLL to allow DLL re-build following any C# update? At the moment I run pwsh inside PowerShell before module import, then run exit to drop the lock on the DLL before C# re-build.
Thanks! I think I'm going to experiment with debugging an outer PS script that calls pwsh to do the import and run the inner PS script, hopefully the PowerShell debugger can hop to the inner process.... Otherwise I'll set up VS Code tasks. Have a great day!
I'm not sure if I get the current situation right …
According to https://github.com/PowerShell/PowerShell/issues/2830, PowerShell seems to now support breaking into the debugger on uncaught exceptions. Yet, I can't find this working in the current version of VS Code PowerShell extension.
I have written a recursive function and I have no clue what's causing a "Collection was modified; enumeration operation may not execute." error without seeing the current stack trace and variable values.
Axel D. (@SetTrend) I don't know if we've wired up the button specifically but if you do $ErrorActionPreference = 'break' it should still break in debugging when an error occurs.
Patrick Meinecke (@SeeminglyScience) has a breakpoint PR we are waiting that changes a lot of things that we are waiting on before we make any breakpoint feature changes. #4065
Activity
daviwil commentedon Sep 20, 2016
I'm not sure how this would work in the case of PowerShell. What do you think, Keith Hill (@rkeithhill)?
rkeithhill commentedon Sep 20, 2016
I've wanted this for a while but I think PowerShell would need to be modified to support this. Who's the debugger expert on the team? Paul H?
FYI, I filed a UserVoice suggestion on this back in March - please vote it up: https://windowsserver.uservoice.com/forums/301869-powershell/suggestions/12843021-enhance-set-psbreakpoint-to-allow-us-to-set-except
daviwil commentedon Sep 20, 2016
Yep, Paul Higinbotham (@PaulHigin) is the PowerShell debugging expert.
PaulHigin commentedon Sep 20, 2016
This is a fairly common request and something we have in our backlog, but is impossible to implement with our current script debugger. The reason is that the script debugger runs on the script execution thread and requires running script to work. But once an exception is thrown on the script execution thread the script is no longer running and the script debugger no longer works. At this point you need a managed/native debugger. We could have script debugger break for non-terminating errors since script execution continues and the script debugger is working. But I am not sure how useful that would be.
Jason, Jason Shirk (@lzybkr), has experimented with a mixed managed code/script debugger and it would be ideal for this kind of thing. When the managed exception is thrown this debugger could show both managed and PowerShell script stacks.
daviwil commentedon Sep 20, 2016
The mixed code/script debugger would be extremely nice to have and would be pretty easy to surface in VS Code.
lzybkr commentedon Sep 20, 2016
That prototype generated a pdb and code that the C# debugger could consume - it was useful, but not a PowerShell experience.
rkeithhill commentedon Sep 23, 2016
Paul Higinbotham (@PaulHigin) What do you think about this workaround by Roman Kuzmin 1967-2026 (@nightroman)? https://github.com/nightroman/PowerShelf/blob/master/Debug-Error.ps1
PaulHigin commentedon Sep 23, 2016
Very clever. I like it. But I believe this just handles the case where PowerShell is throwing the exception (either through throw keyword or -ErrorAction Stop). Jason Shirk (@lzybkr) can you confirm? I was thinking in terms of a general exception being thrown in managed code. Still this looks to be very useful and something we could support internally.
nightroman commentedon Sep 23, 2016
Unfortunately,
Debug-Error.ps1does not show the error itself, it just breaks into the debugger. The error has not been written yet (i.e. added to $Error) by PowerShell. So you have to guess what has happened. Sometimes this is clear, sometimes not. The tool is useful in special cases, rather rare.andrewducker commentedon Nov 10, 2017
Any movement on this? At the moment I'm reduced to stepping through my module (and all of its dependencies) line by line trying to find where the exception is being thrown. Or adding a load of Write-Host statements to see which ones get hit.
SeeminglyScience commentedon Nov 10, 2017
There is a way to break before the terminating error is thrown, but after it's been written to
$Error. It isn't very clean though.After
$StackTraceis written to,$ErrorActionPreferenceis checked to see if the error should be terminating. When it checks$ErrorActionPreferenceit has already written to$Errorregardless of the preference value.For this to be reliable you would need to store state between the two breakpoints to ensure they fire on the same sequence point (in case the script later reads the preference directly). It would also need to handle situations where the break point already exists and be able to remove itself after the first hit.
I'll start looking into the feasibility of adding support for this.
30 remaining items
SeeminglyScience commentedon Mar 7, 2020
My thought here is to add something to the compiler to emit something when processing a
TryStatementAstthat would allow tracking this easier. Still pretty complex but would be incredibly useful.Edit: You were talking about
Stop, not a hypotheticalBreakOnUncaughtOrSomething. Oopsmarkm77 commentedon Apr 29, 2020
[Aside]
I noticed this comment because I'm looking for a way to step through C# in my own PS module (dll) called by PowerShell script being debugged in vscode-powershell. At the moment I can't debug the PowerShell and C# together so Jason Shirk (@lzybkr) if you ever chose to make available something that supports this I'd be grateful for one. 😊
TylerLeonhardt commentedon Apr 29, 2020
Mark Murphy (@markm77) you are able to have the PowerShell debugger and C# debugger running at the same time.... so feasibly you can launch debug a PowerShell script and attach the C# debugger... but it doesn't give you the ideal behavior of "stepping into C# from PowerShell".
lzybkr commentedon Apr 29, 2020
Mark Murphy (@markm77) - mixed debugging is a little painful but possible today if you attach a C# debugger, set breakpoints where you care about, then debug the PowerShell code with the PowerShell debugger. You don't get a nice shared stack but it's better than nothing.
My prototypes were based on the Desktop version of .Net, I have no idea if they are even possible now.
markm77 commentedon Apr 29, 2020
Thanks guys for interesting comments. To do mixed debugging do I have to re-attach the debugger each time the PowerShell script calls into a C# module cmdlet? Or can I attach the debugger just once following module import and it will re-attach as the DLL is called (much better)?
Also is there any recommended way for dropping the lock on the DLL to allow DLL re-build following any C# update? At the moment I run pwsh inside PowerShell before module import, then run exit to drop the lock on the DLL before C# re-build.
Cheers!
lzybkr commentedon Apr 29, 2020
Attaching once is fine, but you must exit the process to rebuild - this is a limitation in .Net.
markm77 commentedon Apr 29, 2020
Thanks! I think I'm going to experiment with debugging an outer PS script that calls pwsh to do the import and run the inner PS script, hopefully the PowerShell debugger can hop to the inner process.... Otherwise I'll set up VS Code tasks. Have a great day!
SetTrend commentedon Mar 11, 2024
I'm not sure if I get the current situation right …
According to https://github.com/PowerShell/PowerShell/issues/2830, PowerShell seems to now support breaking into the debugger on uncaught exceptions. Yet, I can't find this working in the current version of VS Code PowerShell extension.
I have written a recursive function and I have no clue what's causing a "Collection was modified; enumeration operation may not execute." error without seeing the current stack trace and variable values.
JustinGrote commentedon Mar 11, 2024
Axel D. (@SetTrend) I don't know if we've wired up the button specifically but if you do
$ErrorActionPreference = 'break'it should still break in debugging when an error occurs.Patrick Meinecke (@SeeminglyScience) has a breakpoint PR we are waiting that changes a lot of things that we are waiting on before we make any breakpoint feature changes.
#4065