Know Your Debugger
Know Your Debugger
Join the DZone community and get the full member experience.Join For Free
If there is anything I have learned as a developer that has helped me greatly, it has been to learn to use my debugger and how it works. Visual Studio 2010 has some enhanced tools for debugging that have saved my life (not literally of course) on several occasions. If intellitrace and the historical debugger weren't enough, there is a slew of other things that can make your life as a developer so much better. I am going to start a multi-part series on using the debugger, specifically in Visual Studio 2010. A lot of what I am going to cover is also applicable to previous versions, but my focus will be Visual Studio 2010.
When I first started writing code, I didn't know what a debugger was. I was using mostly PHP and wasn't aware of any debugging tools for PHP. When I moved into the Microsoft space working with Visual Basic and C++, the debuggers were there, I just didn't know it. Then one day, I was working with another developer and I was having a problem. He asked me if I stepped through the problem with the debugger. I told him I hadn't and would try that. Google to the rescue. I tend to be pretty good at finding things through searches so I quickly found some basic tutorials on how to use the debugger and found my issue by stepping through my code one line at a time. I tend to be one of those people who won't necessarily admit that I don't know how to do something, especially if I haven't tried, and I got lucky that day. To my defense, I would have asked for help had I not found it on Google. It's just the way I learn and I'm pretty sure I'm not alone on that either.
So enough history, on to debugging with Visual Studio. I am going to assume no real experience with the debugger so I'm going to start with the basics and give you the lay of the land if you will. Each part in this series will build on the basics, so I want to get them out first.
If you notice in Visual Studio, when you run an application in debug mode, there are some toolbar buttons that appear:
If it doesn't show up, you will need to enable the "Debug" toolbar, but it should be there by default. If your application is not "broken" or paused you will see this toolbar as is. If you pause the application by clicking the pause button on this toolbar of if your code hits a breakpoint, the toolbar will change:
There are several items now available. I'll go over them in order from left to right:
- Continue (F5)
- Break All (Ctrl + Alt + Break)
- Stop Debugging (Shift + F5)
- Restart (Ctrl + Shift + F5)
- Show Next Statement (Alt + Num *)
- Step Into (F11)
- Step Over (F10)
- Step Out (Shift + F11)
I'll break these down in a moment, first I want to explain about this thing called a breakpoint. A breakpoint is literally a point in the program where execution is broken or paused. It will happen after a line of code is executed and the indicated location will be on the line that is about to be executed. While your execution is broken, you can inspect variable values and manipulate the execution of your program. If you pause your application manually, you may break on a line of code or you may not, it depends on what your application is doing. If you break on an idle web application, you will likely not break on source code. If you have a long running console app, you will break during the execution. When breaking in this manner, you can't guarantee where your breakpoint will occur so you can set them using Visual Studio. There are many ways to do this, but the common way is to click on the left gutter next to your code and you will see a red circle appear:
This is a standard breakpoint and tells Visual Studio to break before executing this line of code. On execution, your application will run to the first defined breakpoint and the debugger will break. There are several other types of breakpoints that I will cover in a future article. Once execution is broken, you can start really playing with stuff. Note, when your application is broken, the entire process and all threads are broken, not just the thread that your breakpoint is on.
Once your application is broken, you can start using the eight options I listed above:
Continue (F5) will resume normal execution of the application and it will run at intended until it reaches another breakpoint. If you have multiple breakpoints, to check various areas of your application, you will likely just use this to move to the next point in execution.
Break All (Ctrl + Alt + Break) will break the application the moment you press it and is the manual pause I mentioned above.
Stop Debugging (Shift + F5) will stop debugging but also stop execution of the application and kill the process.
Restart (Ctrl + Shift +F5) will stop the process and restart it. This is helpful if you miss something and need to restart the process.
Show Next Statement (Alt + Num *) will take you back to point at which your application is broken to show you the next line of code to get executed. This is helpful if you are looking at a different code file to quickly get back to where you are debugging.
The next three deal with stepping through your code once it is broken, line by line. This is extremely helpful and one of the fastest ways to find problem as you can inspect objects in memory from your source. All three below deal with a line by line "stepping through" of your code.
Step Into (F11) will take you into a method that your code is broken on and allow you to step line by line into that method. It can be in another class or another code file. When the method returns, you will be taken back to the place you stepped into the method from.
Step Over (F10) will execute the next line of code in the execution sequence. This is really the true line by line debugging. Once your application is broken, you can follow the flow of your application one line at a time. You will likely use this more than any other of the eight options.
Step Out (Shift + F11) does the reverse of Step Into. It will take you out of the current method that you are stepping through back to the code that called it. I rarely use this one, but it is handy if you are stepping into a large method and only need to inspect the first part of it.
If you have never learned how to use the debugger in Visual Studio, or didn't even really know that is was there ( as I did at first), I would highly recommend that you explore it. Take some code, set a breakpoint and explore. Right click and mouse over things to see what options you get. When I learned how to use it, the articles I found online basically only covered what I have presented, the rest I learned through trial and error and through other developers. The next article in this series will go over what you can do once your application is broken and I will touch on the types of breakpoints you can set with in Visual Studio. The debugger is one of the most important tools that any IDE can give you.
Opinions expressed by DZone contributors are their own.