{"id":72172,"date":"2015-07-14T00:01:00","date_gmt":"2015-07-14T00:01:00","guid":{"rendered":"https:\/\/blogs.technet.microsoft.com\/heyscriptingguy\/2015\/07\/14\/more-powershell-script-tracing-and-strict-mode\/"},"modified":"2019-02-18T09:47:00","modified_gmt":"2019-02-18T16:47:00","slug":"more-powershell-script-tracing-and-strict-mode","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/scripting\/more-powershell-script-tracing-and-strict-mode\/","title":{"rendered":"More PowerShell Script Tracing and Strict Mode"},"content":{"rendered":"

Summary<\/b>: Ed Wilson, Microsoft Scripting Guy, talks more about Windows PowerShell script tracing and enabling strict mode.<\/span><\/p>\n

Microsoft Scripting Guy, Ed Wilson, is here. It can be somewhat painful to troubleshoot intermittent errors with Windows PowerShell. Two things that can lead to this are variables that do not get initialized properly (and therefore their values change over subsequent running of the script) and functions that do not get accessed properly. To solve both of these problems, we can use Windows PowerShell cmdlets.<\/p>\n

Yesterday in Tracing the Execution of a PowerShell Script<\/a>, I introduced the tracing levels and discussed working with trace level 1. Today, I'll investigate working with trace level 2.<\/p>\n

When the trace level is set to 2, each line in the script that executes is displayed in the Windows PowerShell console. In addition, each variable assignment, function call, and outside script call is displayed. These additional tracing details are prefixed with an exclamation mark to make them easier to see. When the -trace<\/b> parameter from Set-PSDebug <\/b>is set to 2, an extra line is displayed, indicating a variable assignment.<\/p>\n

When I run the CreateRegistryKey.ps1 script (which I published yesterday), the function trace points first to the script, stating that it is calling a function called CreateRegistryKey.ps1. Calls to functions are prefixed with ! CALL<\/b>, which makes them easy to see.<\/p>\n

Windows PowerShell treats scripts as functions. The next function that is called is the Add-RegistryValue<\/b> function. The trace also states where the function is defined by indicating the path to the file. This is shown here:<\/p>\n

PS C:\\> Set-PSDebug -Trace 2<\/p>\n

PS C:\\> C:\\fso\\CreateRegistryKey.ps1<\/p>\n

DEBUG:    1+  >>>> C:\\fso\\CreateRegistryKey.ps1<\/p>\n

DEBUG:     ! CALL function '<ScriptBlock>'<\/p>\n

DEBUG:   30+  >>>> Add-RegistryValue -key forscripting -value test<\/p>\n

DEBUG:     ! CALL function '<ScriptBlock>'  (defined in file<\/p>\n

'C:\\fso\\CreateRegistryKey.ps1')<\/p>\n

DEBUG:   12+  >>>> {<\/p>\n

DEBUG:     ! CALL function 'Add-RegistryValue'  (defined in file<\/p>\n

'C:\\fso\\CreateRegistryKey.ps1')<\/p>\n

The ! SET<\/b> keyword is used to preface variable assignments. The first variable that is assigned is the $scriptRoot<\/b> variable:<\/p>\n

DEBUG:     ! SET $scriptRoot = 'HKCU:\\software\\ForScripting'.
DEBUG:   15+  if( >>>> -not (Test-Path -path $scriptRoot))
DEBUG:   23+     >>>> Set-ItemProperty -Path $scriptRoot -Name $key -Value
$value | `
DEBUG:   27+  >>>> } #end function Add-RegistryValue
PS C:\\><\/p>\n

When the CreateRegistryKey.ps1 script is run with trace level 2, the detailed tracing shown here is displayed:<\/p>\n

\"Image<\/a><\/p>\n

Enabling strict mode<\/h2>\n

One easily correctable problem that can cause debugging nightmares in a script involves variables. Variables are often used incorrectly, are nonexistent, or are initialized improperly. An easy mistake to make when using variables is a simple typing error. Simple typing errors can also cause problems when they are contained in a large complex script.<\/p>\n

Enabling strict mode causes Windows PowerShell to display an error if a variable is not declared. This helps you avoid the problem of nonexistent or improperly initialized variables.<\/p>\n

Using Set-PSDebug -Strict<\/h3>\n

An example of a simple typing error in a script is shown in the SimpleTypingError.ps1 script:<\/p>\n

SimpleTypingError.ps1<\/p>\n

$a = 2
$b = 5
$d = $a + $b
'The value of $c is: ' + $c<\/p>\n

When the SimpleTypingError.ps1 script is run, the following output is shown:<\/p>\n

PS C:\\> C:\\fso\\SimpleTypingError.ps1
The value of $c is:
PS C:\\><\/p>\n

As you can see, the value of the $c<\/b> variable is not displayed. If you use the -Strict<\/b> parameter from the Set-PSDebug<\/b> cmdlet, an error is generated. The error tells you that the value of $c<\/b> has not been set:<\/p>\n

PS C:\\> Set-PSDebug -Strict<\/p>\n

PS C:\\> C:\\fso\\SimpleTypingError.ps1<\/p>\n

The variable '$c' cannot be retrieved because it has not been set.<\/p>\n

At C:\\fso\\SimpleTypingError.ps1:13 char:26<\/p>\n

+ 'The value of $c is: ' + $c<\/p>\n

+                          ~~<\/p>\n

    + CategoryInfo          : InvalidOperation: (c:String) [], RuntimeExceptio<\/p>\n

   n<\/p>\n

    + FullyQualifiedErrorId : VariableIsUndefined<\/p>\n

When you go back to the SimpleTypingError.ps1 script and examine it, you can see that the sum of $a<\/b> and $b<\/b> was assigned to $d<\/b>, not $c<\/b>. The way to correct the problem is to assign the sum of $a<\/b> and $b<\/b> to $c<\/b> instead of $d<\/b> (which was probably the original intention).<\/p>\n

It is possible to include the Set-PSDebug -Strict<\/b> command in your scripts to provide a quick check for uninitialized variables while you are actually writing the script. You can therefore avoid the error completely.<\/p>\n

If you routinely use an expanding string to display the value of your variables, you need to be aware that an uninitialized variable is not reported as an error. The SimpleTypingErrorNotReported.ps1 script uses an expanding string to display the value of the $c<\/b> variable.<\/p>\n

The first instance of the $c<\/b> variable is escaped by the use of the backtick character ( ` ). This causes the variable name to be displayed, and does not expand its value. The second occurrence of the $c<\/b> variable is expanded. Here is the line of code that does this:<\/p>\n

"The value of `$c is: $c"<\/p>\n

When the SimpleTypingErrorNotReported.ps1 script is run, the following is displayed:<\/p>\n

PS C:\\> Set-PSDebug -Strict<\/p>\n

PS C:\\> C:\\fso\\SimpleTypingErrorNotReported.ps1<\/p>\n

The value of $c is:<\/p>\n

PS C:\\><\/p>\n

The complete SimpleTypingErrorNotReported.ps1 script is shown here:<\/p>\n

SimpleTypingErrorNotReported.ps1<\/p>\n

$a = 2
$b = 5
$d = $a + $b
"The value of `$c is: $c"<\/p>\n

To disable strict mode, you use the Set-PSDebug -off<\/b> command.<\/p>\n

Now you know how to use trace level 2 and strict mode in a Windows PowerShell script. Debugging Week will continue tomorrow when I will talk about more cool debugging stuff.<\/p>\n

I invite you to follow me on Twitter<\/a> and Facebook<\/a>. If you have any questions, send email to me at scripter@microsoft.com<\/a>, or post your questions on the Official Scripting Guys Forum<\/a>. See you tomorrow. Until then, peace.<\/p>\n

Ed Wilson, Microsoft Scripting Guy<\/b><\/p>\n","protected":false},"excerpt":{"rendered":"

Summary: Ed Wilson, Microsoft Scripting Guy, talks more about Windows PowerShell script tracing and enabling strict mode. Microsoft Scripting Guy, Ed Wilson, is here. It can be somewhat painful to troubleshoot intermittent errors with Windows PowerShell. Two things that can lead to this are variables that do not get initialized properly (and therefore their values […]<\/p>\n","protected":false},"author":596,"featured_media":87096,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[294,3,4,45],"class_list":["post-72172","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-scripting","tag-debugging","tag-scripting-guy","tag-scripting-techniques","tag-windows-powershell"],"acf":[],"blog_post_summary":"

Summary: Ed Wilson, Microsoft Scripting Guy, talks more about Windows PowerShell script tracing and enabling strict mode. Microsoft Scripting Guy, Ed Wilson, is here. It can be somewhat painful to troubleshoot intermittent errors with Windows PowerShell. Two things that can lead to this are variables that do not get initialized properly (and therefore their values […]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/posts\/72172","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/users\/596"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/comments?post=72172"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/posts\/72172\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/media\/87096"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/media?parent=72172"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/categories?post=72172"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/tags?post=72172"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}