This article is about the PowerShell module that I am most proud of and that I have personally found more useful than any other module I have created. I hope that you enjoy it as much as I do.
Every programming language must be designed with debugging in mind, and PowerShell is no exception. No matter who you are, no matter how well you know the language, you will inevitably come across something that isn’t working like it should. What you do in these situations depends on your comfort level with programming and debugging. For some, this means adding lines to the code that produce extra output so that they can get a handle on what is going on. For others, this means rolling up the sleeves and stepping through the code in a debugger. And there are others still who aren’t comfortable enough with programming or debugging, so they turn to others for assistance. Regardless of which of these approaches you would take, I believe I have a module that can help.
DebugPx is a free, open source PowerShell module that was designed to make it easier to troubleshoot problems in PowerShell code. It comes with two core commands: breakpoint and ifdebug. It also includes a few helpful utility commands to control how the breakpoint command works. The core commands are described as follows:
| breakpoint | The breakpoint command is used to trigger a breakpoint at the current location. By default, the breakpoint command causes Windows PowerShell to immediately enter the debugger whenever it is invoked in an interactive session. If it is invoked with its optional ConditionScript parameter, it will only trigger the breakpoint if the script block expression that was provided for the ConditionScript parameter evaluates to true. It also accepts an optional string Message parameter, and it will write the message provided to this parameter to the current host whenever the breakpoint is triggered. |
| ifdebug |
The ifdebug command is used to identify a block of PowerShell script that you only want to run in one of two scenarios: when you invoke a command with -Debug, or when the $DebugPreference variable is set to anything either than SilentlyContinue or Ignore. |
Both of these commands are very powerful and they can make troubleshooting problems in PowerShell scripts a lot easier. Let me provide some background details so that you understand the problems that these commands solve, problems that still exist in PowerShell 5.0 today.
PowerShell version 1.0 did not come with breakpoint support. It had a debugger, and that debugger is still useful today, even though a new debugger has been in PowerShell since version 2.0. It had a -Debug common parameter that was available on every cmdlet and, since version 2.0 of PowerShell, on every advanced function as well. It had a $DebugPreference built-in variable. It also had a Write-Debug cmdlet that allowed you to have some level of debugger control over your scripts. The behaviour of the Debug common parameter, $DebugPreference and how those affect Write-Debug behaviour is quite interesting, and once you understand how those work together, you may see why their implementation leaves some opportunities on the table.
When you invoke a cmdlet or an advanced function with the -Debug common parameter, PowerShell internally sets the $DebugPreference variable value to Inquire within the scope of that command. As far as PowerShell preference variables go, a value of Inquire means that PowerShell will prompt the user to ask if they want to continue the execution of the associated command, stop the associated command immediately, or enter a the debugger at that point, allowing the user to invoke PowerShell commands to troubleshoot the system. This behaviour seems like it was designed to fill the void when PowerShell did not have breakpoints, because it allowed scripters to enter the debugger as long as they threw a few Write-Debug commands into their scripts.
The problem with this approach is that it tries to do too many things and mixes up several distinct needs in the process. The ability to write debug information to the debug stream during script execution, and the ability to enter the debugger on a breakpoint at a specific location in a script are two distinct needs that are mashed together when they shouldn’t be. Another limitation with this approach is that scripters can’t simply change the way a script is invoked in order to gather additional debug information from an environment where they aren’t able to debug with breakpoints as easily, because using -Debug meant prompting the user every time Write-Debug would be called, and often you’re trying to help a user who is having a problem in this scenario, not confuse them by asking them to continue a bunch of Write-Debug calls while telling you what is happening. Yet another limitation with this approach is that there is no easy way to include PowerShell commands inside of an advanced function or script that will only execute when you are debugging, allowing a command or script author to include support for generating debug output but only when that command or script is invoked with -Debug.
When breakpoints were later added along with a new debugger in PowerShell 2.0, PowerShell script authors were suddenly able to set breakpoints in their scripts, either visually using PowerShell ISE or for conditional breakpoints, command breakpoints, or variable breakpoints using the Set-PSBreakpoint cmdlet. This functionality solved the need for breakpoints, and it started the separation of the need to enter the debugger from the need to be able to write debug output; however, the -Debug common parameter behaviour didn’t change, so there still wasn’t a good vehicle for writing information to the debug stream without any requirement for user interaction during the process. Also, while this breakpoint functionality was useful, it came with its own share of limitations. If you were working in an environment other than PowerShell ISE that didn’t have visual support for setting PowerShell breakpoints (such as notepad++, sublime text, or some other awesome editor), you simply had no choice but to work with the Set-PSBreakpoint cmdlet, which isn’t a very friendly way to set breakpoints in PowerShell, putting it mildly. Also, if you were debugging PowerShell code across multiple sessions, you would have to reset your breakpoints every time, either manually or using a profile or some other script, none of which is very practical.
DebugPx was designed to solve almost all of these problems with the breakpoint and ifdebug commands. With the DebugPx module installed and discoverable via the PSModulePath environment variable, you can trigger a breakpoint at a specific location by simply invoking the breakpoint command (or the bp alias, for short). These breakpoints are identifiable in any editor because you can see the commands in the files where they are used. They work in unsaved files. They even work in an interactive PowerShell prompt, or inside of a block that you run in PowerShell using copy/paste, or inside of a block that you select in ISE and run by using the Run Selection (F8) feature. They are properly ignored if they are inside of a function that uses the System.Diagnostics.DebuggerHidden attribute. They are conditional if you invoke them with a condition script block (which would map to the first, ConditionalScript parameter), or unconditional otherwise. They can be globally enabled or disabled using the Enable-BreakpointCommand or Disable-BreakpointCommand commands. They will only cause PowerShell to enter the debugger if they are encountered in an interactive session. And if you want a message to be displayed when the breakpoint activates (for example, as a reminder why you wanted to break when that obscure scenario that you previously couldn’t catch occurs), you can pass a message to the -Message parameter and the breakpoint will output the message to the host when the breakpoint is triggered.
If you are debugging in other scenarios, where you may not be able to use the breakpoint command to enter a debugger because you are not in an interactive session (such as in background jobs, scheduled tasks, Azure Automation or Service Management Automation scripts, or perhaps in a remote customer’s environment), you can include rich debug information inside of an ifdebug command script block, and anything that is output from inside of that script block will automatically be written to the debug stream without prompting the end user. This includes object data, text strings, or anything else you want to write to the debug stream in order to figure out what is going on when that script runs. If the command containing ifdebug is not invoked with -Debug, PowerShell will simply skip directly over that script block, avoiding running debug logic when it is not needed, which is better for performance.
Both the breakpoint command and ifdebug can be used in the middle of a pipeline as well. This is important because it allows for writing debug information to the debug stream or triggering a breakpoint in the middle of a pipeline during the processing of that pipeline. If you use the breakpoint command in a pipeline and you either have the breakpoint command disabled or you are in a script block with the DebuggerHidden attribute set, or if you use the ifdebug command in a pipeline and you didn’t run the script with -Debug, both the breakpoint and the ifdebug commands will simply pass the pipeline object down to the next stage in the pipeline for additional processing.
At this point, you’re probably getting a feeling for the kind for the power that these commands provide. Let me show you a few simple examples that demonstrate how you might use them in practice. You can try these examples at the command prompt in the PowerShell host of your choice, or in a script file, or in functions you write, or script module files, or workflows, etc.
Enter the debugger in the middle of a series of commands
$services = Get-Service wuauserv,bits
breakpoint
Restart-Service -InputObject $services -WhatIf
Enter the debugger conditionally in the middle of a pipeline (using the bp alias)
gsv audiosrv,bits,wuauserv | bp {$_.Name -eq ‘bits’} | spsv -WhatIf
Display a message as you enter the debugger reminding you why you are doing so
Get-Process -Name Idle,PowerShell,Explorer |
breakpoint {$_.Id -eq 0} -Message ‘Process ID is zero???’ |
Format-Table
Disable the breakpoint command so that you can run without debugging
Disable-BreakpointCommand
gsv audiosrv,bits,wuauserv | breakpoint {$_.Name -eq ‘bits’} | spsv -WhatIf
‘See, the breakpoint command did not cause PowerShell to enter the debugger!’
Re-enable the breakpoint command so that it functions normally again
Enable-BreakpointCommand
Skip over breakpoints in a script block by using the DebuggerHidden attribute
& {
[System.Diagnostics.DebuggerHidden()]
param()
breakpoint
‘The breakpoint command is effectively disabled in the current scope.’
}
‘But it still works in scopes that do not use the DebuggerHidden attribute.’
breakpoint
Create a function that generates some useful debug information
function Test-IfDebug {
[CmdletBinding()]
param()
ifdebug {
# This may be useful when debugging, but I wouldn’t want to gather
# this information in everyday use. It is an exaggerated example of
# what you might want to collect when debugging something.
‘*************** Current Operating System ***************’
Get-WmiObject -Class Win32_OperatingSystem | Format-List *
‘*************** Running Services ***************’
Get-Service | Format-List *
‘*************** Running Processes ***************’
Get-Process | Format-List *
}
Get-Service w*
}
Invoke that function without debugging
Test-IfDebug
Invoke that function with debug output turned on
Test-IfDebug -Debug
Compare the performance of the two
Measure-Command {Test-IfDebug}
Measure-Command {Test-IfDebug –Debug}
I think those examples provide a good demonstration of how these commands work. As I hinted at earlier in this article, I am super-excited about this module and I’m thrilled that I can share it with you now. If you want to give it a try, install the latest version in your environment by following the instructions on the DebugPx project page on GitHub. I have a few more features planned for this debugging toolkit, and I would be very happy to entertain your ideas as well, so please let me know what you think! Have fun debugging!
Kirk out.
Poshoholic 