Month of Lunches - Day 23

Day 23 - Debugging Techniques

Todays Chapter covers the various techniques to debug your script. This has the potential to be the most immensely useful chapters in this book. Writing debugging into your script seems like a lot more work but in the end if you are writing a distributable module this could save you and the end users a lot of time troubleshooting issues with its functionality. So lets dive right in.

In debugging PowerShell Don explains that there are only really two types of errors. Syntax Errors and Logic errors. Syntax errors are exactly as they sound. These are a mistyping of a cmdlet, function, or parameter (basically a misspelling)  or a syntax error in the way you type your commands. These error are basic and can be resolved normally by a quick review of the script. Most of the Third party Scripting Environments have a spell check function. In PowerShell v3 it will actually underline a grammatical error as well and there are third party modules that create a function to spell check your script (James Brundages Spell Checker ” http://blogs.msdn.com/b/mediaandmicrocode/archive/2009/12/09/test-spelling.aspx). In going through this book there have been at least three occasions where I got stuck on a script due to one of these errors. Pay attention and read carefully.

The second type of error that Don discusses is a Logic Error. Dons explanation here is great, "This means that the script or command isn't doing what you want it to do". But as he explains these are not always easy to troubleshoot. Sometimes they display I fairly concise error that will lead you directly to the problem, sometimes they give you no error at all, and sometimes with certain commands they give a generic error. Such is the case with WMI if a connection could not be made with the remote computer. All you get in this case is "RPC Server Not Found" The book example of this is a very good illustration of what these can look like and also contains a syntax error. Lets see if you can find them, I caught the easy one.

                $Name = Read-Host "Enter Computer Name"

                          If (test-connection $name) (

                                get-wmiObject Win32_Bios -computername $Nmae

                          )

The First step in debugging is to identify your expectations. What exactly is it that you want the script to do.

The Second is to put in the pieces for the actual debugging. There are two ways we cover on how to do this. The first is Trace Code. With Trace Code you first need to set the $DebugPreference variable in PowerShell to allow you to see it. This can be done in the script so that you do not have to manually set it. As with the $ErrorActionPreference you set this to "Continue". The cmdlet for the Trace Code is Write-Debug and allows you to actually view what the script is doing. Book Example.

                $Debugpreference = "Continue"

                $Name = Read-Host "Enter Computer Name"

                Write-Debug "`$Name contains $name"

                          If (test-connection $name) (

                                Write-Debug "Test-Connection was True"

                                get-wmiObject Win32_Bios -computername $Nmae

                          ) else (

                                Write-Debug "Test-Connection was False"

                         )

The Second way of handling debugging is with Breakpoints. These are a defined area where a script will pause, allowing you to check what the script is doing at that exact moment (Properties of Variables, current output, etc…). These can be defined at particular lines, at the changing of a variable, or when a specific cmdlet completes. The easies way to set these is in the ISE from the menu or with their hotkey (F9).

All in all debugging in PowerShell is very useful for troubleshooting and you really do need to read up on these to learn more about them and integrate them into your own scripts.