Debugging, in computer programming and engineering, is a multistep process that involves identifying a problem, isolating the source of the problem, and then either correcting the problem or determining a way to work around it. The final step of debugging is to test the correction or workaround and make sure it works.In software development, the debugging process begins when a developer locates a code error in a computer program and is able to reproduce it. Debugging is part of the software testing process and is an integral part of the entire software development lifecycle.

In hardware development, the debugging process typically looks for hardware components that are not installed or configured correctly. For example, an engineer might run a JTAG connection test to debug connections on an integrated circuit.

DEBUGGING IN VISUAL STUDIO 2019

1. Attaching the debugger

Debugging in Visual Studio occurs automatically when you run from Visual Studio with F5 or select Debug | Start Debugging.

When doing, so Visual Studio attached itself as a debugger to the program. Alternatively, you can attach to a running process with Debug | Attach to Process… (Ctrl+Alt+P).

2. Debugger Break Mode

The debugged process has to be in “Break Mode” for debugging. That means the program is currently paused on a specific line of code. More accurately, all the running threads are paused on a specific line of code.

You can get to break mode with Debug | Break All menu item (Ctrl+Alt+Break) or by placing breakpoints.

We’re usually going to use breakpoints because in most debugging scenarios we will want to debug when the program reaches a certain line of code.

You can place breakpoints by clicking on the margin, pressing F9, or Debug | Toggle Breakpoint. Once set, when your program reaches that line of code, Visual Studio’s debugger will stop execution and enter “Break Mode”:

In break mode, the yellow line represents the next line of code to execute.

3. While in Break Mode – Navigate through code

When in break mode, you can debug interactively and see how your execution of code progresses. The basic features of code navigation are:

1. Continue (F5) will quit break mode and continue the program’s execution until the next breakpoint is hit, entering break-mode again.
2. Step Over (F10) will execute the current line and break on the next line of code.
3. Step Into (F11) is used when the next execution line is a method or a property. When clicked, the debugger will step into the method’s code first line. By default, properties are skipped. To enable stepping into property code go to Tools | Options | Debugging and uncheck Step over properties and operators.
4. Run execution to here allows you to continue execution, and break in a specified location without a breakpoint. It’s like creating a breakpoint and removing it after first break. You can do it in 3 ways:
   • Hover and click on the green arrow that appears on the start of each line

   

   • Stand on the desired line of code and click Ctrl + F10
   • Right click on the desired line of code and click on Set next statement
5. Run to a cursor location allows you to forcefully set the next line of code to execute. The current (yellow) line will not be executed. It can be a line that was executed before or after, but it’s best for the new line of code to stay in the current scope. There are 2 ways to do this:
   • Drag the yellow arrow to any line of code
   • Stand on the desired line of code and click Ctrl+Shift+F10

4. Investigate variables

When in break mode, you can investigate the value of local variables and class members. This is as easy as hovering over a variable:

The hover popup is called a Data Tip. You can get to the same popup by right-clicking the variable and select QuickWatch (Shift+F9 or Ctrl+D, Q) in the context menu.

The data-tip and QuickWatch are very similar, except that you can edit the expression in QuickWatch.

An expression is a sequence of variables and operators that evaluate to a single value. For example, discountPercentage is an expression, initialPrice / 100 * discountPercentage is also an expression, literals like "Hello world" and 5 are also expressions.

For complex objects, you can expand into fields and properties.

5. DataTip and QuickWatch notable Features

The DataTip and QuickWatch have several useful features:

• Pinning DataTips – You can leave a DataTip pinned to the editor by clicking on the pin icon. Useful when you hit the same breakpoint many times (maybe in a loop)

• Holding Ctrl will make the DataTip transparent
• By right clicking on an expression in the DataTip, you can open a context menu with several options:

• Copy – Copies to clipboard both Expression and Value (alex = {DebuggingPillars.Person})
• Copy Expression – Copies expression (alex)
• Copy Value – Copies expression ({DebuggingPillars.Person})
• Edit Value – A useful feature where you can change the value during debugging. Most useful for primitives (strings, integers, etc.).
• Add Watch – Adds expression to Watch window (more on that later)
• Add Parallel Watch – Adds expression to Parallel Watch window (more on that later)
• Make Object ID – Creates a scope-independent expression that starts with ‘$’ ($1, $2, and so on). You can evaluate this expression at any time, regardless of the current scope, in QuickWatch, Watch Window or the Immediate Window. A very useful feature and can be used to detect memory leaks.

6. Breakpoint advanced features

The breakpoints has several very useful lesser known features. By right-clicking a break you will see a context menu:

• Conditions allows you to break on this breakpoint only when a condition is met. For example, when in a loop I can break only on even numbers:

• Actions allow you to log a message to the output window whenever the breakpoint is hit. You can continue execution, without stopping on the breakpoint.

This is most useful when debugging multi-threaded scenarios. More on multi-threading debugging later.

• Edit labels… allows to categorize breakpoints into labels. This makes it easier later to organize them in the breakpoints tool window:

Debugging in Visual Studio Code

function addNumbers() {
  // Get the numbers out of the text boxes.
  var numberA = document.getElementById("numA").value;
  var numberB = document.getElementById("numA").value;  // Perform the calculation.
  var result = numberA + numberB;  // Show the result on the page.
  document.getElementById("result").innerHTML = result;
}

var numberA = document.getElementById("numA").value;

var numberB = document.getElementById("numB").value;

var result = Number(numberA) + Number(numberB);

–The Visual Studio debugger helps you observe the run-time behavior of your program and find problems. The debugger works with all Visual Studio programming languages and their associated libraries. With the debugger, you can break execution of your program to examine your code, examine and edit variables, view registers, see the instructions created from your source code, and view the memory space used by your application.

5 Awesome Visual Studio Debugger Features

1. Step Out of the Current Function

So you’ve written a function call, like so:

And the compute_average function is not returning the correct value. If you were to use a debugger, and you wanted to step into compute_average, you could, of course, put a breakpoint inside compute_average, but what if it were called from several places? Visual Studio has a very convenient feature of its debugger, that will allow you to step into compute_average very quickly.

Set a breakpoint on that line:

Once the debugger hits it, then step into the function. getSum and getCount will both be called before compute_average. Normally, you’d keep hitting next to get out of getSum and getCount, but with Visual Studio, you can quickly hit Shift-F11 to step out of the current function and return to the next call.

Once you step out of the current function, you’re taken back to the original breakpoint. But now you can step in again, to go to the next function. Repeat until you’ve drilled down into the function you want.

When to Use This Trick

Obviously, there are times when it makes more sense to just set a breakpoint in your target function. But when doing so would require ignoring hundreds of calls to that function to find the one you want, it might not be worth it. Using step out provides a quick way of getting into a function without having to find the function and set a temporary break point (or use run to cursor).

2. Use the Auto Window to See Result of Functions

One of the most frustrating parts of debugging is when you have a function call whose result isn’t stored anywhere, and you really want to know what it returned.

Sometimes, programmers write code like this, just to work around the issue:

(Obviously, in this case, the program prints out the value, so all is not lost. This is rarely true in the general case.)

Fortunately, the autos window has good courtesy to display the result of a function evaluation:

When to Use this Trick

Whenever you want to see a return value! Note that you the autos window will eventually erase the return value as you execute code, so be sure to check your return value immediately.Most return values are also stored in the EAX register–you can look in EAX to find the return value, if you need it.

3. Run to Cursor

Run to cursor is a great way of avoiding the step-step-step-step-step-oh-no-I-stepped-over-it problem, where you know where you want to be, getting to it requires stepping multiple times, and you get impatient.

In effect, run-to-cursor is just a shortcut for setting a breakpoint that is immediately cleared once it’s hit; nevertheless, it’s a very convenient feature. It is most useful when you have a piece of code that is called frequently from different places, and you only care about one code path. Then you can place a breakpoint at the start of that path and use run-to-cursor to get to the point you really care about.

Going back to our sample program, we can use run-to-cursor rather than the step-out trick, to get into compute_average. (Of course, we could just put a breakpoint in compute_average; for the purpose of making this example sensible, please imagine 15-20 calls to compute_average that all work correctly, taking place before the broken call.)

When to Use this Trick

Any time you want a throwaway breakpoint or want to avoid single-stepping through a lot of code. Be careful, though, that you run to a part of the code that will actually be executed. Watch out for early returns from a function within a loop, for instance.

4. Modify Any Variable

Now that we’re in the compute_average function, and we know that the value being returned is waayyy too big, we can check the arguments to the function. It turns out that sum is very large. We’ll deal with that in a bit. First, let’s test and make sure that the function works if we do get the right value.

Obviously, one way of doing this would be to pass in a new value. But Visual Studio conveniently makes it easy to change any value in memory. In fact, let’s do that with the value of sum, and make sure that it returns the correct value.

All you need to do is click on in the Value column of the auto or watch window and change the value. (You can also do this when the variable’s value pops up while hovering over a variable in the source code.)

and :

Continuing execution of the program demonstrates that, in fact, we still get the wrong answer–this time, it returns the value 1. This suggests that truncation is taking place due to integer division.

Before recompiling, we can add in a cast to solve this problem:

When to Use this Trick

This trick is powerful, and is particularly helpful when you have found one bug, but want to prove that the rest of your code will work. This is particularly handy when your debugging session requires a great deal of setup–for instance, you have to perform a lot of UI to get the right inputs or your code takes a long time to build. (An alternative would be to consider writing a unit test that demonstrates the bug and doesn’t require so much setup.)

On the other hand, you can’t rely on this trick when you are inside a loop or a function that is called frequently–it’s just too much of a pain to have to manually set variables all the time.

5. Set Next Statement

Set Next Statement is a real power tool. If you’re debugging, and you’ve accidentally (or not so accidentally) stepped past the point where something interesting happens, you can sometimes “unwind” execution. What this really means is that, maintaining the current state of the world, you can tell Visual Studio to go back and start executing from a previous instruction.

You can also use set next statement to jump over code that you believe is buggy, or to jump past a conditional test on an if statement to execute a path of code that you want to debug without having to make the condition true.

Setting the next statement can be dangerous and lead to instability if the stack or registers aren’t in a valid state for the line being executed. And because it won’t restore the state of the world, if your code depends on that state, changing the next statement might not be useful. On the other hand, if you want to make a call that you’re pretty confident won’t behave differently, it can be a great way of avoiding recreating a specific failure just because you accidentally stepped too far.

For instance, take the following debugging state, where you’re about to return the value total from getSum:

If you had accidentally run too far, it might be very convenient to be able to simply say, ok, let’s start that again:

and then you can go back through executing the loop, perhaps setting the value of total to 0, since you notice that it wasn’t initialized, and then checking to see if the program gives the correct sum (in which case, you can be pretty confident that the lack of initialization was the problem).

When to Use this Trick

Many of the same considerations that apply to resetting variable values also apply here. However, you should also be aware that the further ahead or back in a function you set the next statement, the more likely the debugger will not be able to compensate and your program will crash.

Major Features of Visual Studio debugger

Unfortunately bugs are a part of software development, and despite our best efforts to write software correctly from the start we spend a lot of time in the debugger. While bugs are an unfortunate fact of life, finding them doesn’t have to be as painful as it often is. For you problem-solvers out there, the Visual Studio 2015 debugger contains a rich set of features that can really increase your productivity…assuming you know they exist, and how to use them! To help with you learn more about our debugging tools, I recently gave three talks on “Debugging Tips and Tricks for .NET developers”, at Microsoft’s Build Conference (60 minutes), at Microsoft’s Ignite Conference (75 minutes), and most recently on Visual Studio Toolbox (38 minutes). So check them out!

Debugging with VisualStudio 2015