In one of the previous post, we discussed how to use visual studio code for PowerShell development. Writing scripts in Visual Studio code is now more or less at par with ISE (Integrated scripting environment) and in a few cases, is more useful. However, you do need to be able to make sure that whatever code you have written in PowerShell, should be able to run as intended. Also, if its not working as intended, you should be able to debug and see where you went wrong. In this blog post, we’ll discuss how to use Visual Studio code for debugging. These features are provided by the PowerShell extension, or, more accurately, by the PowerShell Editor Services module which comes with the PowerShell extension. PowerShell Editor services not only provides language services to the Extension (which in turns provide services to Visual Studio code) but also provides useful debugging features.

Since editor services runs in a separate process, even if it crashes, it does not affect/crash Visual Studio code. You should be able to just restart PowerShell extension to restart the process. To start with the debugging process, we need to define breakpoints. A breakpoint can simply be defined by placing your cursor at code line of your choice and then pressing F9. This should place a red circle immediately left to the line number in the code:

To open the Debug view, in the View Bar, select Debug from the View menu (shown in the following screenshot)  or press Ctrl + Shift + D. In the Launch Configuration dropdown (shown in the following screenshot), select the PowerShell Launch (current file) configuration. Like the PowerShell integrated scripting environment (ISE), this configuration will execute the file that’s in the active editor window under the debugger when debugging is started:

To start a debug session, press F5 or start debugging. After the debugger starts, you will see the Debug actions pane (shown in the following screenshot), and the debugger should pause at the breakpoint that you set:

The Debug actions pane provides buttons for:

• Continue / Pause – F5
• Step Over – F10
• Step Into – F11
• Step Out – Shift + F11
• Restart – Ctrl + Shift + F5
• Stop – Shift + F5

Following features are available during a debug session:

The VARIABLES section of the Debug view allows easy inspection of variable values. The Auto group weeds out the PowerShell automatic variables and leaves just the variables you’ve defined and are likely interested in seeing. However, if the variable you are looking for isn’t listed in Auto, you can look for it in the Local, Script, or Global groups.

The WATCH section allows you to specify a variable or expression whose value should always be displayed.

The CALL STACK section displays the call stack, and you can also select a different frame in the call stack to examine calling functions, scripts, and the variables that are defined in those scopes.

The BREAKPOINTS section provides a central UI to manage, that is, create, disable, enable, and delete breakpoints that you may have defined over many different script files.

Below is one of the screenshot from the debug session:

Let’s expand VARIABLES section local variables, and we can see all the variables in the local scope:

For primitive variable types, the value is displayed directly, typically as numbers, strings, and Booleans. For non-primitive variables, the type information is displayed. If the type is a collection or an array, the number of elements is displayed as well. You can do more than just inspect variable values. To change those values, double-click the value that you want to change, enter a new value, and click outside the edit box to complete the operation. You can also enter arbitrary expressions when setting a variable’s value. Just remember, the expression has to be valid PowerShell syntax.

However, sometimes due to complex type of variables, you may not be able to put it directly.

The WATCH section allows you to monitor any variables of your choice. If it does not show anything by default, hover your mouse along the WATCH header and a + sign would appear:

You can also provide a expression over there. Do note that these values will always be evaluated, if possible. Also the variables entered as a watch may not be available in all scopes.

We’ll continue to discuss on the debugging features offered in another blog post.