{"id":246,"date":"2014-12-05T00:01:00","date_gmt":"2014-12-05T00:01:00","guid":{"rendered":"https:\/\/blogs.technet.microsoft.com\/heyscriptingguy\/2014\/12\/05\/use-the-powershell-debugger\/"},"modified":"2022-06-21T12:41:02","modified_gmt":"2022-06-21T19:41:02","slug":"use-the-powershell-debugger","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/scripting\/use-the-powershell-debugger\/","title":{"rendered":"Use the PowerShell Debugger"},"content":{"rendered":"

Summary<\/b>: Boe Prox shows how to debug scripts in Windows PowerShell.<\/span><\/p>\n

Honorary Scripting Guy and Windows PowerShell MVP, Boe Prox, here today filling in for my good friend, The Scripting Guy. This is the final part in a series of five posts about troubleshooting Windows PowerShell scripts and functions. The series includes:<\/p>\n

    \n
  1. Provide Support by Using Verbose and Debug Streams<\/a><\/li>\n
  2. Troubleshoot by Using Set-PSDebug<\/a><\/li>\n
  3. Enforce Better Script Practices by Using Set-StrictMode<\/a><\/li>\n
  4. Trace Your Commands by Using Trace-Command<\/a><\/li>\n
  5. Use the PowerShell Debugger<\/strong> (this post)<\/li>\n<\/ol>\n

    Over the course of the week, I have been showing you various approaches to troubleshoot your code (or someone else\u2019s code). Today I wrap things up by talking about the Windows PowerShell debugger. I’ll look at the console and the ISE to help troubleshoot different parts of the code.<\/p>\n

    Debugging in the ISE is nicer because you can use keyboard shortcuts to set breakpoints on various lines of code. When you hit that breakpoint, it shows up in the ISE, making it easier to tell where you are. The following table lists the keyboard shortcut.<\/p>\n\n\n\n\n\n\n\n\n\n\n\n\n
    \n

    \n \u00a0Action<\/strong>\n <\/p>\n<\/td>\n

    		\n

    \n \u00a0Keyboard Shortcut<\/strong>\n <\/p>\n<\/td>\n<\/tr>\n

    \n

    \n \u00a0Run\/Continue\n <\/p>\n<\/td>\n

    		\n

    \n \u00a0F5\n <\/p>\n<\/td>\n<\/tr>\n

    \n

    \n \u00a0Step Into\n <\/p>\n<\/td>\n

    		\n

    \n \u00a0F11\n <\/p>\n<\/td>\n<\/tr>\n

    \n

    \n \u00a0Step Over\n <\/p>\n<\/td>\n

    		\n

    \n \u00a0F10\n <\/p>\n<\/td>\n<\/tr>\n

    \n

    \n \u00a0Step Out\n <\/p>\n<\/td>\n

    		\n

    \n \u00a0SHIFT+F11\n <\/p>\n<\/td>\n<\/tr>\n

    \n

    \n \u00a0Display Call Stack\n <\/p>\n<\/td>\n

    		\n

    \n \u00a0CTRL+SHIFT+D\n <\/p>\n<\/td>\n<\/tr>\n

    \n

    \n \u00a0List Breakpoints\n <\/p>\n<\/td>\n

    		\n

    \n \u00a0CTRL+SHIFT+L\n <\/p>\n<\/td>\n<\/tr>\n

    \n

    \n \u00a0Toggle Breakpoint\n <\/p>\n<\/td>\n

    		\n

    \n \u00a0F9\n <\/p>\n<\/td>\n<\/tr>\n

    \n

    \n \u00a0Remove All Breakpoints\n <\/p>\n<\/td>\n

    		\n

    \n \u00a0CTRL+SHIFT+F9\n <\/p>\n<\/td>\n<\/tr>\n

    \n

    \n \u00a0Stop Debugger\n <\/p>\n<\/td>\n

    		\n

    \n \u00a0SHIFT+F5\n <\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

    Let\u2019s image that I have a script that I want to test to make sure it behaves properly. I am going to run this in the ISE to set up a couple of breakpoints and see what everything is doing. Eventually, the first breakpoint will trip and then the console will enter the debugger.<\/span><\/p>\n

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

    Now that we have hit the debugger, we can start working with some of the available debugging commands to further explore the code and step through various parts. These are the same commands that are available in the console.<\/p>\n

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

    If we have other breakpoints set, we can type c **(continue), and the code will execute to the next breakpoint. We can also find all the available debugging commands by typing **?<\/strong> (questions mark) at the debug prompt.<\/p>\n

    Knowing this, we can begin debugging the code and tracking the progress of each line, if needed, or simply move to the next breakpoint. The nice thing about the ISE is that the tracking for each line is shown as a highlighted row. In the console, we would be making liberal use of \u2018list\u2019<\/strong> to see where we actually are. I can also use Get-PSCallStack<\/strong> to see where we are in the current call stack.<\/p>\n

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

    Another thing worth noting is that there are a few variables that hold a value in the debugger that is different from the value they would have in the script or function. Those variables are: \u00a0<\/p>\n