Debugging PowerShell Scripts in Visual Studio Code

in this video we're going to talk about how to debug powershell scripts in visual studio code we'll be using the microsoft powershell extension for visual studio code and we're kind of going to go through the basics up through some more advanced topics we'll start with how to run your powershell scripts how to set breakpoints then we'll look at how to step through your powershell scripts then we'll talk about how to look at variables in the variable window how to add watches for both variables and expressions talk a little bit about what the call stack is then we'll look at how to use weight debugger to actually invoke the debugger next we will execute commands from the terminal and break in the powershell debugger then we'll look at some advanced breakpoints such as conditional breakpoints hit count breakpoints and log points and then finally we're going to configure some launch.json um files to actually set up different configurations that you can use to launch in various ways inside visual studio first let's just look at the basics of executing powershell script in visual studio code so in my environment here i'm running visual studio code and i have the powershell extension installed so this is just the microsoft powershell extension that you can get and install so once that's installed you're going to have things like intellisense and the ability to execute code so in my environment you can see in the top right side here i actually have this run button that i can now click to execute this script i'm getting a random value between 10 and 100 and then i'm just using write host to output that value so clicking the run button will just run your script you can also run your script by clicking f5 on the keyboard so you can see again it output a random value next what you can actually do is you can set breakpoints just like you can in the ise so on the left hand side here you're going to see there's this little gutter with the little break point icon showing up if i click that and now i press f5 it's going to break into the debugger so the the view kind of changes a little bit when this happens you can see that the terminal has gone into debug mode on the left hand side the run and debug window has opened up we have access to things like variables and the watch window and the call stack and then a list of breakpoints at the bottom if i were to press f5 or click continue it's going to continue executing the script until it either hits another breakpoint or completes this section successfully the other ways you can execute scripts inside visual studio code are by using uh control f5 and that will actually run the script without invoking the debugger so even if i have a break point set like this if i hit ctrl f5 it's going to run my script and not hit the breakpoint so you may want to like do that occasionally but leave all your break points in there and then if i just hit f5 again it's going to hit the breakpoint the other way to execute scripts is the the f8 or execute selection command and when you execute selection you actually will not hit breakpoints at all so if i hit f8 here you'll see it's executing my my script and it's not hitting my break point that i have set in there now let's talk a little bit about stepping through your scripts so once you set a breakpoint you actually can take some actions inside the debugger when that breakpoint has been hit so some things you can do is evaluate variables kind of look at the state of your current powershell script or you can start moving through your script as it executes so stepping allows you to move line by line to see how each line is kind of changing the state of the powershell process and your script so i have an invoke random function here that gets a random value between 10 and 100 and then it goes from one to that random value and it outputs each value in between um i've set a break point on line eight where we're actually calling invoke random and we're going to see how this behaves so when i press f5 it hits my breakpoint and again i have access to all these things like the watch window and variables in the call stack but i also have access to this toolbar on the top right side here so you can see i have options like continue step over step into step out of uh restart and finally stop so if i continue the script it's just going to execute to completion so for example if i were to set a breakpoint somewhere else and then i hit f5 it's going to go to that next breakpoint if i remove that breakpoint it's just going to continue to the end if i were to execute that again without that inner breakpoint and i press f5 it's just going to execute the script and no longer hit any break points um step over works by stepping over the current line that you're on so if i press f5 and hit my breakpoint again if i press f10 it's not going to step into the invoke random function the idea with step over step into and step out of is that you're stepping either over the current line step into will step into that scope and you'll see the call stack change and step out of or step out we'll step out of the current scope and go back to the parent scope so if i press f10 at this point it's just going to step over everything pretty much because it didn't go into the invoke random function and that's where all the contents of the script pretty much are but if i press f5 again hit the break point and press f11 now you can see that i've entered the invoke random function so now if i start pressing f10 it's stepping through the lines inside this particular function so you have to keep in mind the scopes that are going on here because if i press f10 here it stepped over the for each because we didn't step into that four each's scope and then it exits out of the script but if i were to press f11 and i continue to press f10 and then f11 you can see now i'm stepping into the for each block scope so now that i'm in this scope i could continue to press f10 and it's going to continue to go through each one of the items inside my for each block if for some reason i wanted to leave this i could either continue by pressing f5 or i could press the step out of button which is shift f11 so if i hit shift f11 it steps out of my 4h and back into my invoke random scope and if i press f5 then that will go to completion obviously there's two other options that we can select when debugging that being restart which will just literally restart the script or we can stop debugging at this point in time and it won't execute the rest of the script so that's kind of the idea with stepping is that you can step through individual lines in your script and kind of step in and out of the different scopes as as you go one thing you may have noticed on the left hand side as we were doing that process of stepping through our script was that the variables on the left-hand side were changing so if we get back into our debugger by pressing s f5 we can actually look at various you know states of the powershell process and the uh run space that we're running these scripts in so you can see all the variables are available to us we have you know you see all your built-in variables and that kind of thing and as we like step into our script you'll see new variables are going to start being defined it's going to start highlighting things that are changing so you can see random has shown up and now it's 62. and if we were to like step into our for each it's going to start highlighting things like dollar underscore which shows you know the current iterator value for my for each which is then being updated the other thing that you can do is also watch variables and expressions so let's say for example i had some variable and some other scope that i wanted to just kind of put in this watch window or even my random variable just to kind of make it look easier to see i can put dollar sign random into the watch and it's going to actually show me the value of that random so what's cool about watches are they're actually just powershell expressions so you could go you know real crazy if you wanted to and do something like get process id you know the id of this process and then the name and if i hit enter there it's actually going to evaluate that particular watch um command every single time i step through my script so it's going to keep you know iterating and executing those commands so the process is not going to change but you might have something where you want to execute a command to see if the state of something is changing while that's happening the other section here that you want to look at is actually the call stack so the call stack pretty much shows how we got here from the start of the script you can see that interactive session is the top level call stack and that's kind of like how visual studio code started this and then from there we can actually click through these places and it'll show you how you got to where you are so this script block was started on line eight here and that's what this little number is here and then invoke random we're inside invoke random on line three and now we're inside this script block uh on line four um and i believe this is the um the column that is it's starting on so you can see in the bottom here the line in column is nine and that's what four comma nine means so we're on line four column nine so the cost that kind of provides you history of how you got to the place that you are um and it's the same thing that's returned by get ps call stack so now that we've looked at some of the the basics of the you know the bugging tools that you have available while you're debugging scripts i want to show you some other ways to kind of get into the debugger and then we'll talk about some um additional ways to set break points and hit points and log points so i am going to stop my script now and you can see that my running debug has gone away and what i'm actually going to do is just bring back more of a simple script just for purposes of this demonstration and in the middle here i'm going to put a weight debugger weight debugger is cool because it actually causes the script to break and wait for the debugger to attach to it but the visual studio code um extension is like smart enough to pick up on the fact that that's happening so even if i were to do control f5 you're going to see that the weight debugger breakpoint gets hit if you recall before when i had break points set if i hit ctrl f5 it wouldn't hit the break point but with weight debugger it will so we'll let that go and the other cool thing with weight debugger is if i actually took this script and like copy the path of that script and put it into my interactive console down here and i hit that you're going to see that wait debugger also executes there because it realizes this script is open inside visual studio and it hits my breakpoint for weight debugger so that's kind of cool way to execute things from the terminal so now let's talk a little bit about different types of breakpoints you can actually add to break as well so right there is a a line break point is what it's called when you actually just set a break point on a line inside powershell it's saying like inside test script.ps1 line two i want to hit a breakpoint but there's other options that you can actually set for breakpoints if you right click on this you can say edit breakpoint and then from there you have three options you have an expression a hit count and a log message so an expression will break when it's true so if our random value is less than i don't know 60 then our break point will hit you can see the icon for the break point changes a little bit and if you hover over it it gives you some information about what that condition is so let's save that and hit f5 so that time it didn't break because you can see that the random value was 72 and my breakpoint said if it's under 60 then we should break so let's see there we go so now it broke and we can actually go look at our variable um i local where's random i don't know but i'm gonna do random and you can see random is 59 and because random is 59 that is um why my breakpoint hit so that's how you can use expression breakpoints and you can put a bunch of stuff into your expression breakpoint it's just a powershell command and you can use the current state of your script to uh evaluate that expression so it's a great way to set breakpoints on things that like hit a lot and you don't want to like press f10 a bunch of times through your script so another type of breakpoint we can hit is called a hit count breakpoint so the hit count break point is the idea that you just want to um you want to break after this break point has been evaluated or has been run a couple a certain amount of times so like let's say we said 30. so you just want to put a number in there so once this line has run 30 times then we want to hit the break point so put that in there and then if i were to do something like 1 to 100 and just do a 4 each on this right host line oh and now my break point moved so i'm actually going to remove that and put that back here we'll do hit count of 30. and now um let's run our script and now you can see the breakpoint hits and what we can do to actually check to see what you know how many times it's been hit is the dollar underscore since we're in a for each loop and you can see dollar underscore is 30. so we've hit this 30 times and now my break point triggers so that's another good way to kind of evaluate the state of your script without having to press f10 a whole bunch of times you know like after 25 times my script stops working for some reason you could put a hit count breakpoint in there uh the last type of um like special break point that you can create in visual studio at least through the ui is um what they call log point and the idea with a log point is it just outputs some text um based uh or when it hits this particular line so uh this is just a string like a powershell string that you can type in here so if i just did like random and i hit enter there you can see it's a little um triangle now instead of a little square instead of a circle and then if we hit run you can see random was output down in my terminal that's because it hit that breakpoint or log point and output that to the console so you could do the same thing with like you know right host or write for most messages but this is nice because this is like tweakable and it's just for your visual studio experience and not for uh inside your script itself so let's edit this log point the other thing that you can do is like this is like a um an expandable string in powershell so i could actually put in dollar sign random and now when i run my log point you can say it said random15 and that's because it actually evaluated that uh variable so just think of it kind of like an expandable string and powershell and you can put those types of expressions inside your log point all right so now i want to look at um a couple more advanced scenarios so we're gonna remove my log point and we're actually going to go back to this run and debug section here and you can see right now it's like wants you to customize a launch.json file i think back in the early days of the powershell extension you would have to configure this yourself just to get started but we already have like this automatic configuration set up and you no longer need to do that but if you did want to set that up this is where you would come so when you're not debugging if you go to run and debug you can click this create a launch.json file and what that's going to do is provide you some options that are kind of provided by the powershell extension launch current script launch script interactive session or attach the debugger to a running powershell host so by default you know it's pretty much the launch and debug the currently active window but if you wanted to you do something like launch script so it generates the launch.json um script for you here and what's nice about this is uh there's intellisense so you don't have to like totally like figure this out all by yourself if you actually start typing it's gonna provide you with some information some of it's straightforward some of it you might need to look up but in this case we're just doing a launch request and it's pretty much saying like i want to use the current folder and then i want to launch something um you know for this script you know like not the current script but some script in my uh environment so it doesn't matter where i am if i press f5 this is what i want to happen so i have this other script in here so there's nothing cool except start process and weight debugger so that's what i'm going to do i'm going to launch that script here so i'll just do script.ps1 inside my launch config and then you can see here we have the running debug launch script here i could also like update the name like launch script ps1 and that'll actually update the name that you see in there so now when i press f5 it doesn't matter where i am it's going to run that script and you'll notice a couple things that happened i saw my notepad start up and it also broken the debugger so it was smart enough to actually hit that weight debugger call and now um now uh the visual studio code debugger is attached to that script and we could like go ahead and do all the evaluating that we want to for our script.ps1 the other really handy one is attaching to another process so we actually have this attached to powershell host process and this by default will attach to the current process and if you have a background run space that you want to attach to you could put that run space id in here so it's a little tricky because the run space ids change all the time so you'd have to like update your launch.json file all the time but i'll show you kind of an easier way to do that in a sec so now we could say you know attached to a process i want to attach to the process id that i'm going to specify here and i'm going to open another powershell process so we have this additional powershell process running here the id of this process is 21 592. we can copy that put that into our process id and now when we do attach to process or attach to host process it's going to actually attach to that powershell process and you can see the debugger now is like waiting inside here and it's not super interesting because nothing's really going on but if we were to take for example this script and i am going to copy the path to that script and then i am going to do start thread job and run that script you can see it started notepad so the script is running and if i do get run space on this you'll see that this script is in breakpoint so that's because i have that weight debugger column there and you can see the run space id is three so if i come back here i can change this run space id to three and save that and now when i come in here and i do attach the host process you can see that it broke into this other process so if you look down here you can see that the process id is actually this other powershell process so it's pretty much a remote debugging scenario where i've attached to this other place and i'm in run space 3 i can see that the pid here is not the current process id of this local terminal it's actually the process id of that remote process which means that i can like debug you know other powershell processes on my machine so now if i were to just continue that and we do get run space over here again you can see that run space 3 is no longer here and that's because we actually use that weight debugger and it let the script continue after i disconnected from that that session this remote host is actually visual studio code connecting to this powershell process so that's just what happens when you connect to a powershell process like that and now i can hit ctrl c and exit the debugger and if we check the pit again you'll see that i'm back in my my local powershell process another way you can do this is we actually have some tools in visual studio or powershell pro tools where if we do start thread job again it's going to start a background process remember that this pit is 21 592. and if you actually click i don't know why this icon is a watch right now but if you click that and we actually go to host processes and we'll just refresh this and you can see that we have process id 21 592 and if i expand that you're going to see that the run spaces actually show up and you'll be able to connect to those with this little debugger icon and it's doing all the same commands as visual studio code does but you don't need to modify the launch.json file you can just do those directly from this little helper window here and then connect to the powershell process that way and start debugging just with a couple clicks so in this video we went through all the various ways that you can debug powershell scripts in visual studio code

Channel: Adam Driscoll

Views: 14,126

Keywords: powershell, debugging, devops, it, visual studio, visual studio code, microsoft

Id: K2Rl5GxAzv4

Length: 22min 15sec (1335 seconds)

Published: Tue May 31 2022