For debugging, variable breakpoints can be of invaluable help. They break into the debugger once a variable changes. If you know that a variable hits a certain value (or a NULL value) when bad things happen, you can make sure the debugger kicks in just then.

The example below illustrates how to use variable breakpoints. It is best to define them at the top of your script because that way you can use $PSCommandPath to find out the actual script file path that is required for breakpoints to work:

# initialize variable breakpoints (once)
# break when $a is greater than 10
Set-PSBreakpoint -Variable a -Action { if ($a -gt 10) { break }} -Mode Write -Script $PSCommandPath

# run the code to debug
do
{
    $a = Get-Random -Minimum -20 -Maximum 20
    "Drawing: $a"
} while ($true)

Make sure you save the code to a script file before you execute it: debugging always requires a physical file.

As you’ll see, the debugger kicks in whenever $a receives a value greater than 10. You can continue with the command “exit”, view all debugger options with “?”, and stop by pressing SHIFT+F4.

To remove all breakpoints, run this:

 
PS C:\> Get-PSBreakpoint | Remove-PSBreakpoint
 

psconf.eu – PowerShell Conference EU 2019 – June 4-7, Hannover Germany – visit www.psconf.eu There aren’t too many trainings around for experienced PowerShell scripters where you really still learn something new. But there’s one place you don’t want to miss: PowerShell Conference EU - with 40 renown international speakers including PowerShell team members and MVPs, plus 350 professional and creative PowerShell scripters. Registration is open at www.psconf.eu, and the full 3-track 4-days agenda becomes available soon. Once a year it’s just a smart move to come together, update know-how, learn about security and mitigations, and bring home fresh ideas and authoritative guidance. We’d sure love to see and hear from you!

Twitter This Tip! ReTweet this Tip!

Anonymous