One of the things I mentioned was that when setting a breakpoint on a script, the script specified must be the same script that breaks. For example, if I set a breakpoint for the c:\\fso\\mydebug.ps1 script, the only script that breaks when a breakpoint reaches is the c:\\fso\\mydebug.ps1 script. This is the exact script, from the exact location.<\/p>\n
If, on the other hand, I do not specify the script when I create the breakpoint, any script I run causes the breakpoint to trigger. To test this out, I create a script with several commands in it. The script is shown here:<\/p>\n
Get-Process.ps1<\/b><\/p>\n
Get-EventLog application -Newest 1<\/p>\n
get-process powershell<\/p>\n
Get-Date<\/p>\n
I also use the test script from yesterday. The mydebug.ps1 script is shown here:<\/p>\n
MyDebug.ps1<\/b><\/p>\n
$cn = “localhost”<\/p>\n
$process = “notepad”<\/p>\n
Get-WmiObject -Class win32_bios -cn $cn<\/p>\n
Start-Process $process<\/p>\n
Get-Process $process<\/p>\n
I use the Set-PSBreakpoint<\/b> cmdlet to create a breakpoint that will break when the command Get-Process<\/b> appears in a script. The command and associated output are shown here:<\/p>\n
PS C:\\> Set-PSBreakpoint -Command get-process<\/p>\n
<\/p>\n
ID Script Line Command Variable<\/p>\n
— —— —- ——- ——–<\/p>\n
1 get-process<\/p>\n
<\/p>\n
<\/p>\n
PS C:\\><\/p>\n
When the Get-Process<\/b> command from the MyDebug.ps1 script appears, the debugger breaks into the script. This allows for the use of debugging commands (the commands appear in a table from yesterday’s article). The C <\/i>command tells the debugger to continue. In the Get-Process.ps1 script, the script also contains a call to Get-Process<\/b>, so that script causes the breakpoint to break as well. These two scripts and the associated output including debugger are shown in the following figure.<\/p>\n
One of the really cool things to do with a breakpoint is to specify an action to take when a condition occurs. The action to occur is placed inside a scriptblock. In the following command, I specify that when the Get-Process<\/b> command appears, the debugger will start the notepad<\/b> process:<\/p>\n Set-PSBreakpoint -Command get-process -Action {notepad}<\/p>\n I modify the Mydebug.ps1 script so that I comment out the Start-Process<\/b> line. The revised script is shown in the following figure.<\/p>\n When run, the script generates an error because it attempts to use Get-Process<\/b> to retrieve a nonexistent process. In the breakpoint previously specified, however, when the breakpoint is reached, the scriptblock creates the notepad<\/b> process, so the script works without causing an exception. This is shown in the following figure.<\/p>\n When debugging a script, often I am concerned about the value of a variable. There are three ways to break on a variable. The three ways are read<\/b>, write<\/b>, and readwrite<\/b>. The default value is write<\/b>. When working with breakpoints on variables, read<\/b> <\/i>or write<\/b> <\/i>do not talk about the way the variable is declared in the script, but each determines when the script breaks. For example, when breaking on a variable in write<\/b> <\/i>mode, it means the script breaks before a new value is written to a variable. In the case of a variable that is not yet declared, the script breaks just before a value is written or assigned to the variable. I used the code that follows to set a breakpoint on the variable cn<\/b> <\/i>when a value is written to the variable:<\/p>\n Set-PSBreakpoint -Variable cn -Mode write<\/p>\n I run the script, and the script breaks before the value “localhost” is assigned to the $cn<\/b> variable. I then check the value of the $cn<\/b> variable; nothing is displayed because the variable has not been created. Next, I use the L<\/i> command to see the code, and I see the script is on the first line, waiting to assign a value to the $cn<\/b> variable. I then use the C <\/i>command, and continue execution of the script. The error is generated because I have commented out the Start-Process<\/b> command (this can be seen in the code listing from the previous command).<\/p>\n In the following figure, I run the C:\\fso\\debug.ps1 script. The script hits the $cn<\/b> variable breakpoint and breaks into the script. I check the value of the $cn<\/b> variable and see it has not been set; thereforem nothing returns. I then assign the value mred<\/span><\/b> <\/i>to the $cn<\/b> variable, and I use the L <\/i>command to view the code. Next, I use the S <\/i>command to step to the next line in the script. I see that it sets the value notepad<\/b> <\/i>for the $process<\/b> variable. I then step (S<\/i>) to the next line in the script where I see that it will make a WMI call to retrieve BIOS information via the Win32_BIOS<\/b> WMI class. I then step past that (S<\/i>) and see that the script is getting ready to retrieve process information about the notepad<\/b> <\/i>process. However, Notepad is not running because the Start-Process<\/b> command is commented out. I therefore type Start-Process $Process<\/b> <\/i>and then step into the remainder of the script.<\/p>\n When I break on a variable in read<\/b> <\/i>mode, the value of the variable has already been read. This means I can inspect the value of the variable to ensure the script works as intended. In the code that follows, I remove all the current breakpoints, and then I create a new breakpoint that watches the variable $cn<\/b> to see when it reads the value of the variable. When the value of the $cn<\/b> variable is read, the script breaks and enters the debugger:<\/p>\n Get-PSBreakpoint | Remove-PSBreakpoint<\/p>\n Set-PSBreakpoint -Variable cn -Mode read<\/p>\n When I query the value of the $cn<\/b> variable inside the debugger, I see that the variable contains the value “localhost.” That is what I want, so I step over the remainder of the code, thereby executing the remainder of the script. These commands and associated output appear in the following figure.<\/p>\n That’s it for now. Join me tomorrow for more fun with Windows PowerShell.<\/p>\n <\/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 <\/p>\n Ed Wilson, Microsoft Scripting Guy<\/b><\/p>\n<\/p>\n <\/p>\n","protected":false},"excerpt":{"rendered":" Summary: Learn how to inspect variable values by using the Windows PowerShell debugger. Microsoft Scripting Guy Ed Wilson here. In yesterday’s post, I talked about using the Set-PSBreakpoint cmdlet to set a breakpoint on a specific script. Today, I want to continue looking at the Set-PSBreakpoint cmdlet. One of the things I mentioned was […]<\/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":[295,3,4,45],"class_list":["post-12001","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-scripting","tag-debug","tag-scripting-guy","tag-scripting-techniques","tag-windows-powershell"],"acf":[],"blog_post_summary":" Summary: Learn how to inspect variable values by using the Windows PowerShell debugger. Microsoft Scripting Guy Ed Wilson here. In yesterday’s post, I talked about using the Set-PSBreakpoint cmdlet to set a breakpoint on a specific script. Today, I want to continue looking at the Set-PSBreakpoint cmdlet. One of the things I mentioned was […]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/posts\/12001","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=12001"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/posts\/12001\/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=12001"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/categories?post=12001"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/tags?post=12001"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}![\"Image](\"https:\/\/devblogs.microsoft.com\/wp-content\/uploads\/sites\/29\/2019\/02\/5751.hsg-11-23-11-1.png\" "\\"Image")
<\/a><\/p>\n![\"Image](\"https:\/\/devblogs.microsoft.com\/wp-content\/uploads\/sites\/29\/2019\/02\/6404.hsg-11-23-11-2.png\" "\\"Image")
<\/a><\/p>\n![\"Image](\"https:\/\/devblogs.microsoft.com\/wp-content\/uploads\/sites\/29\/2019\/02\/0268.hsg-11-23-11-3.png\" "\\"Image")
<\/a><\/p>\n![\"Image](\"https:\/\/devblogs.microsoft.com\/wp-content\/uploads\/sites\/29\/2019\/02\/8750.hsg-11-23-11-4.png\" "\\"Image")
<\/a><\/p>\n![\"Image](\"https:\/\/devblogs.microsoft.com\/wp-content\/uploads\/sites\/29\/2019\/02\/2337.hsg-11-23-11-5.png\" "\\"Image")
<\/a><\/p>\n![\"Image](\"https:\/\/devblogs.microsoft.com\/wp-content\/uploads\/sites\/29\/2019\/02\/7801.hsg-11-23-11-6.png\" "\\"Image")
<\/a><\/p>\n