If you’re old school like me and you write Powershell scripts using ISE or Notepad++, it gets a little tricky to troubleshoot issues with your scripts when you are dealing with many variables.
When I’m writing long complicated scripts, I like to put some useful error trapping in to show me where my script is failing and why. In this blog I will show you the basics of error trapping and then show how to make a popup window that will show the error message and the variables that were used at a particular point in your script’s execution.
Let’s say you have a script with some variables and you are trying to do some mathematical operations on those variables:
$VARIABLE1 = 10
$VARIABLE2 = 0
$RESULT = $VARIABLE1 / $VARIABLE2
Write-host $RESULT
It’s pretty obvious in this simple script why you are getting an error, the variable you are trying to divide by has a value of zero. Dividing by zero is not defined in mathematics, so it errors out.
This is helpful if you are running your script in ISE, but if you’re running the stand-alone .ps1 file on a server, it’s going to open a command window, error out and close before you can see what’s going on. You could put a Read-Host command at the end of the script to keep the command window open until you press enter on the keyboard. This will at least give you time to read the error message before the window closes.
Simple scripts like this are very easy to troubleshoot, but let’s say you have a bunch of variables that you are doing operations on and the final result of those is causing your script to error out. Powershell isn’t going to give you much useful information in that case and you’ll have to mine it out the information you need yourself.
I like to use the Try{…}Catch{…} feature of Powershell along with a Windows Popup to capture the error and variables and present them to me in a GUI popup window.
The Try{…}Catch{…} feature in Powershell is much like other coding languages, it lets you wrap your code in a Try statement, and then “Catch” the error information generated, assuming there is an error.
The general form is this:
Try{
Some Powershell code
}Catch{"Do something if there is an error"}
The errors are caught in a field called $_.Exception.Message which you can output to the console with a write-host command or to a popup window. If you leave the Catch statement blank it will capture the error, but it won’t do anything with it, so you will not see any error output.
I like to put a windows Message box in the Catch Statement which will show me the error message and the variables used that caused the message. You can do this with the [System.Windows.MessageBox]::Show command.
Here’s an example:
Try{
$VARIABLE1 = 10
$VARIABLE2 = 0
$RESULT = $VARIABLE1 / $VARIABLE2
}Catch{[System.Windows.MessageBox]:: Show($_.Exception.Message +" VARIABLE1 = " + $VARIABLE1 + " VARIABLE2 = " + $VARIABLE2 + " RESULT = " + $RESULT) }
If you run this, it will pop up a window with the error message and the variable values at that point in the script:
Be sure to leave plenty of space around your output text “ VARIABLE1 = “ so Windows doesn’t cram all the words together in the popup.
This error trapping method is helpful when are trying to troubleshoot a long script and you aren’t sure what values your variables are getting at a particular point in the script. Obviously, you could also output the information to a file or do a write-host to output the info to the command window, but I like this method because it’s quick and clean and once you are done troubleshooting the script and ready to deploy it, you can modify the message so that it will continue to trap errors and show users any error message that a particular part of the script is generating. This is useful if you are writing the script for other users to run and you are unable to anticipate every scenario that will arise.
One thing I should point out about the Try{…}Catch{..} command, it’s only useful if it’s put in strategic points in your script. You could put the Try at the beginning of your script and the Catch at the very end, but it’s probably not going to give you much useful information in a very long script, especially if your script is capable of generating multiple errors.
In a later blog I’ll show you how to put the line number of the error in your popup for better troubleshooting.