I’ve used the integrated debugging features with PowerShell V2 since I’ve had it available, but I never really dug below the surface of setting breakpoints at certain lines.
Set-PSBreakpoint offers some additional options of which I was not aware.
- Setting a breakpoint in relation to a variable (read, assigned, or both)
- Setting a breakpoint when a function or command is called
- Setting a breakpoint based on the column number for the referenced line
- Run a scriptblock when a breakpoint is hit
- Breakpoints do not need to be set on a script
Let’s dig into these in a bit more detail:
1. Setting a breakpoint in relation to a variable (read, assigned, or both)
Set-PSBreakpoint can be used to find all the occurrences of access to a variable (in the current scope). This can be very useful when attempting to find out where things might be taking an unexpected turn with your variable’s contents.
2. Setting a breakpoint when a function or command is called
This is cool. You can configure breakpoints based on when cmdlets or functions are called. Great stopping at the entry point to a particularly troublesome function, so you can drop into the debugger and check the state of parameters about to go in, as well as other state related issues.
3. Setting a breakpoint based on the column number for the referenced line
I’m not so stoked about this feature. This merely allows you to specify which column to stop execution on in a particular line of code… Moderately useful, but not really exciting.
4. Run a scriptblock when a breakpoint is hit
This is where things get interesting. You can assign an action to occur when a breakpoint is hit. This action is a scriptblock that is run in the scope where it is set. Since breakpoints can be variable assignments or calls to commands, this opens up some interesting possibilities. First off, it allows for conditional debugging. If you only want to drop into a breakpoint if a particular value is less than zero before going into a function, you could do something like
$BreakpointAction = { if ($MyNumber -lt 0) { break } else { continue } }
This also has applications outside of debugging. Using the –Action parameter of Set-PSBreakpoint, you have the ability to run a scripblock of your choosing at any of the condition types described above – when variables are accessed, when commands are called, and at certain specific positions in the script.
5. Breakpoints do not need to be set on a script
Finally, breakpoints do not need to be set in a script, they can just be set to respond to variable access or command use. This means that you could use Set-PSBreakpoint in a profile script to configure a particular environment to respond in a certain way, perhaps prompting you before changing a critical environmental variable.
I’m definitely going to be exploring these additional features and applications of Set-PSBreakpoint as I go forward.
Additional debugging tips/info from the PowerShell Team Blog.
Please leave a comment as to how you think this functionality could be used.