{"id":72192,"date":"2015-07-13T00:01:00","date_gmt":"2015-07-13T00:01:00","guid":{"rendered":"https:\/\/blogs.technet.microsoft.com\/heyscriptingguy\/2015\/07\/13\/tracing-the-execution-of-a-powershell-script\/"},"modified":"2019-02-18T09:47:01","modified_gmt":"2019-02-18T16:47:01","slug":"tracing-the-execution-of-a-powershell-script","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/scripting\/tracing-the-execution-of-a-powershell-script\/","title":{"rendered":"Tracing the Execution of a PowerShell Script"},"content":{"rendered":"

Summary<\/b>: Ed Wilson, Microsoft Scripting Guy, talks about using a cmdlet to trace the execution of a Windows PowerShell script.<\/span><\/p>\n

\"Hey, Hey, Scripting Guy! I am having a problem with a script. It does not generate any errors, but dude, it does not seem to work either. Can you help me debug it?<\/p>\n

—DR<\/p>\n

\"Hey, Hello DR,<\/p>\n

Microsoft Scripting Guy, Ed Wilson, is here. When I see a script that doesn’t work, I think, "Cool…it is easy to troubleshoot." Often this is the case because the error message helps locate the source of the error. But if a script simply doesn’t work, it can be more difficult to troubleshoot. If the error is a logic error, it can be very difficult to troubleshoot.<\/p>\n

Most of the time, examining the values of variables does not solve the problem because the code itself works fine. The problem often lies in what are called "the business rules" of the script. These are decisions the code makes that have nothing to do with the correct operation of, for example, a switch statement. At times, it may appear that the switch statement is not working correctly because the wrong value is displayed at the end of the code. But quite often the business rules themselves are causing the problem.<\/p>\n

The problem with logic errors<\/h2>\n

For a simple example of a logic error, consider the function called My-function<\/b> that is shown here:<\/p>\n

My-Function.ps1<\/p>\n

Function my-function<\/p>\n

{<\/p>\n

 Param(<\/p>\n

  [int]$a,<\/p>\n

  [int]$b)<\/p>\n

  "$a plus $b equals four"<\/p>\n

}<\/p>\n

The My-function<\/b> function accepts two command-line parameters: a<\/b> and b<\/b>. It then combines the two values and outputs a string that states the value is four. The tester performs four different tests, and each time the function performs as expected. These tests and the associated output are shown here:<\/p>\n

PS C:\\> C:\\fso\\my-function.ps1<\/p>\n

PS C:\\> my-function -a 2 -b 2<\/p>\n

  2 plus 2 equals four<\/p>\n

PS C:\\> my-function -a 1 -b 3<\/p>\n

  1 plus 3 equals four<\/p>\n

PS C:\\> my-function -a 0 -b 4<\/p>\n

  0 plus 4 equals four <\/span><\/p>\n

PS C:\\> my-function -a 3 -b 1<\/p>\n

  3 plus 1 equals four<\/p>\n

When the function goes into production, however, users begin to complain. Most of the time, the function displays incorrect output. However, the users also report that no errors are generated when the function runs.<\/p>\n

What is the best way to solve the logic problem? Simply adding a couple of Write-Debug<\/b> commands to display the values of the variables a<\/b> and b<\/b> will more than likely not lead to the correct solution. A better way is to step through the code one line at a time and examine the associated output. The easy way to do this is to use the Set-PSDebug<\/b> cmdlet.<\/p>\n

Using the Set-PSDebug cmdlet<\/h2>\n

The Set-PSDebug<\/b> cmdlet has been around since Windows PowerShell 1.0. This does not mean it is a neglected feature, but rather, that it does what it needs to do. The Set-PSDebug<\/b> cmdlet is not designed to do heavy debugging; it is a lightweight tool that is useful when you want to produce a quick trace or rapidly step through a script.<\/p>\n

For performing basic debugging quickly and easily, you cannot beat the combination of features that are available. There are three things you can do with the Set-PSDebug<\/b> cmdlet:<\/p>\n