I have written a few posts on debugging using the PowerShell ISE lately. If you care to have a look, here are the links to ISE Debugging 101 and ISE Debugging 102. Those blog posts got newcomers to the ISE slightly more comfortable with the idea of debugging and the the specific tools offered in the ISE. I had a few questions and responses to these posts and I thought the best way to encapsulate this information was with a screen cast. I have taken what I covered and expanded it a bit to the realm of modules and how you can use the ISE debugging tools to work with Modules as easily as you can work with scripts and functions.

I hope you find this video helpful. I would love to hear any kind of feedback on the video, positive or negative. All I can say is that it is a bit easier to talk to yourself in front of a computer after a glass of wine   Seriously, feedback is greatly appreciated.

Andy

In my last post I gave a high level overview of how to get started with debugging in PowerShell 2.0, using the new Integrated Scripting Environment. In this installment, we are going to explore some of cmdlets that can be used to manipulate breakpoints.

First,  lets do some discovery. Whenever I am looking for cmdlets to work with something in particular, i use the get-command cmdlet with wildcards to help my search.

So from this it looks like we can get, set, enable, disable, and remove breakpoints. When we are setting breakpoints, you can specify the line and column you want to break on, but that can get really tedious. This is what the ISE does for you automatically when you toggle breakpoints. However, I find it much more useful to break when ever a variable is accessed.

Let’s use a basic function to demonstrate this.We’ll create a function foo and then set a breakpoint for the $c variable.

When we execute this code and call function foo, we get the output below. Notice that $a and $b is set, and that we break when we hit $c. One thing to note, when we specify the variable, we do not use the $ in front of the variable. This is the same as specifying the –outvariable common parameter for other cmdlets.

Last but not least, let’s take a look at how to navigate this “nested” prompt. If you type “?” or “h”, you will get the following information It is interesting that the “nested>” prompt displays this when you hit “?.” Under normal circumstances, the “?” is an alias for where-object, as we can see when we type ? at a normal prompt.

I hope this helps you with debugging your scripts.

I have always found the origin of words to be fascinating.  Apparently, the terms bug and debugging in regards to computers are attributed to Admiral Grace Hopper in the 1940’s.

While she was working on a Mark II Computer at Harvard University, her associates discovered a moth stuck in a relay and thereby impeding operation, whereupon she remarked that they were "debugging" the system.

When I first started scripting and writing a little code, the concept of debugging something seemed really hard. However, I have found that with a few simple steps I can debug most of my scripts pretty quickly.

Ninety nine percent of the time, debugging scripts requires being able to watch a variable at some point in a script or a function. Have you ever written a function and thought, “If only I knew what x was before y started messing with it?”

The PowerShell Integrated Scripting Environment makes this pretty easy. You can set a breakpoint on any line in the ISE using the Debug Menu and choosing “Toggle Breakpoint.” or by using the F9 shortcut key.

When you toggle a breakpoint on and then run the script, the script will stop at that point. You should note that at this point, the highlighted line has not been executed yet.

Here’s what it looks like when you hit a breakpoint. You get thrown into a nested prompt where you can poke around and look at any variables you want to. Notice the >>> prompt and notice $b has not yet been set, but $a has.

Now that you are paused right around the line of code you want to check out, you can use the “Step Into” Feature.

This will execute the next line of code in the script (the highlighted line) and then stop.

Now you can see that $b has been set but $c doesn’t have a value yet.

You can continue to step through as much as many lines as you need to until you see something that is not quite right.

This is just the beginning of what we can do in regards to debugging scripts and functions. In the next couple weeks I plan to share more as I learn about debugging and the ISE. Just to whet your appetite, you can run the command get-command –noun psbreakpoint to see what kinds of goodies await!