Breakpoint Window Visual Studio

0 views

Skip to first unread message

Pernille Pennebaker

unread,

Aug 3, 2024, 6:00:12 PM8/3/24

to ansinchangperc

Breakpoints are one of the most important debugging techniques in your developer's toolbox. You set breakpoints wherever you want to pause debugger execution. For example, you may want to see the state of code variables or look at the call stack at a certain breakpoint. If you are trying to resolve a warning or issue while using breakpoints, see Troubleshoot breakpoints in the Visual Studio debugger.

You can set a breakpoint on any line of executable code. For example, in the following C# code, you could set a breakpoint on the line of code with the variable assignment (int testInt = 1), the for loop, or any code inside the for loop. You can't set a breakpoint on method signatures, declarations for a namespace or class, or variable declarations if there's no assignment and no getter/setter.

At the breakpoint in the following example, the value of testInt is still 3. So, the value hasn't changed since the variable was initialized (set to a value of 3) because the statement in yellow hasn't yet executed.

At the breakpoint in the following example, the value of testInt is still 1. So, the value hasn't changed since the variable was initialized (set to a value of 1) because the statement in yellow hasn't yet executed.

To disable a breakpoint without deleting it, hover over or right-click it, and select Disable breakpoint. Disabled breakpoints appear as empty dots in the left margin or the Breakpoints window. To re-enable a breakpoint, hover over or right-click it, and select Enable breakpoint.

Set conditions and actions, add and edit labels, or export a breakpoint by right-clicking it and selecting the appropriate command, or hovering over it and selecting the Settings icon.

A tracepoint is a breakpoint that prints a message to the Output window. A tracepoint can act like a temporary trace statement in the programming language and does not pause the execution of code. You create a tracepoint by setting a special action in the Breakpoint Settings window. For detailed instructions, see Use tracepoints in the Visual Studio debugger.

You can control when and where a breakpoint executes by setting conditions. The condition can be any valid expression that the debugger recognizes. For more information about valid expressions, see Expressions in the debugger.

If you set a breakpoint condition with invalid syntax, a warning message appears. If you specify a breakpoint condition with valid syntax but invalid semantics, a warning message appears the first time the breakpoint is hit. In either case, the debugger breaks when it hits the invalid breakpoint. The breakpoint is skipped only if the condition is valid and evaluates to false.

There are times when you want to observe the behavior of a specific object. For example, you might want to find out why an object was inserted into a collection more than once. In C# and F#, you can create object IDs for specific instances of reference types, and use them in breakpoint conditions. The object ID is generated by the common language runtime (CLR) debugging services and associated with the object.

If you suspect that a loop in your code starts misbehaving after a certain number of iterations, you can set a breakpoint to stop execution after that number of hits, rather than having to repeatedly press F5 to reach that iteration.

Under Conditions in the Breakpoint Settings window, select Hit Count, and then specify the number of iterations. In the following example, the breakpoint is set to hit on every other iteration:

You can break execution when a function is called. This is useful, for example, when you know the function name but not its location. It is also useful if you have functions with the same name and you want to break on them all (such as overloaded functions or functions in different projects).

You can use the address of an object to set a function breakpoint on a method called by a specific instance of a class. For example, given an addressable object of type my_class, you can set a function breakpoint on the my_method method that instance calls.

In the Byte Count dropdown, select the number of bytes you want the debugger to watch. For example, if you select 4, the debugger will watch the four bytes starting at &avar and break if any of those bytes change value.

Data breakpoints depend on specific memory addresses. The address of a variable changes from one debugging session to the next, so data breakpoints are automatically disabled at the end of each debugging session.

If you set a data breakpoint on a local variable, the breakpoint remains enabled when the function ends, but the memory address is no longer applicable, so the behavior of the breakpoint is unpredictable. If you set a data breakpoint on a local variable, you should delete or disable the breakpoint before the function ends.

Dependent breakpoints break execution only if another breakpoint is first hit. So, in a complex scenario such as debugging a multi-threaded application, you can configure the additional breakpoints after another breakpoint is first hit. This can make debugging code in common paths such as game loop or a utility API much easier because a breakpoint in those functions can be configured to enable only if the function is invoked from a specific part of your application.

This breakpoint lets you break the code only once. When debugging, the Visual Studio debugger only pauses the running application once for this breakpoint and then removes it immediately after it has been hit.

You can use the Breakpoints window to see and manage all the breakpoints in your solution. This centralized location is especially helpful in a large solution, or for complex debugging scenarios where breakpoints are critical.

Breakpoints are an essential tool for debugging your applications. You set the breakpoints whenever you want to pause the execution. When paused you can investigate the program's state - check the values of variables or look at the call stack.

You can set a breakpoint on any line of executable code by clicking in the margin of the code editor, or by right-clicking on a line of code and selecting Breakpoint, Insert Breakpoint, or simply by pressing F9 (This is a typical shortcut; check the Debug, Toggle breakpoint in the settings menu).

When the breakpoint is placed on a location without PHP executable code, breakpoint resolution mechanism is used to move the breakpoint to a line where it can break (it has to be within 5 lines). This feature is supported since Xdebug version 2.8 and higher.

In Breakpoint Settings window check Actions and provide a log message. The log message can contain variables (placed between and ), including predefined special variables listed below:

You can break execution when a function is called. This is useful when you know a function or method name, but you don't know the location (or you do know and you just don't want to search for it). The other use case would be if there are multiple methods or functions with the same name (e.g. same function in different namespaces or method implemented on multiple classes) and you would like to break on all of them.

When providing a function name, you can be more specific. The syntax for the function breakpoint is !::(), where type_name and function_name can be fully qualified or the namespace part can be omitted.

Have you ever had a situation when you are debugging a complex scenario with a huge list of breakpoints, and you find yourself scrolling and tapping in the breakpoints windows to disable/enable them individually and repetitively?

Then the new Breakpoint Groups feature in Visual Studio may be the answer for you. This feature will allow you to create named breakpoint groups with any number of breakpoints in them. This provides a way to customize the breakpoint configuration and toggle breakpoints individually or in combination making debugging, testing, and troubleshooting faster and more effective.

Breakpoint groups can simplify and organize the debugging process by allowing you to create separate breakpoint groups that correspond to distinct aspects of the application, such as individual functions, modules, or even projects. This organization makes it easy to switch between different debugging scenarios, test different theories, and track the results of each debugging session.

To sum it up, breakpoint groups can play a pivotal role in software development since they allow developers to quickly narrow down sources of issues and bugs and enable the seamless working of multiple projects and investigations simultaneously.

The Breakpoint Groups feature in Visual Studio is a game-changer for both experienced developers and those new to the platform. As the feature continues to evolve, we invite you to test it out in 17.6 Preview 2 and provide your feedback on the Allow creation of breakpoint groups ticket on Developer Community.

@Jonas Brekle, thanks for reaching out. Can you please file a feedback ticket ( -us/visualstudio/ide/how-to-report-a-problem-with-visual-studio?view=vs-2022) so I can pass this on to our Engineering team?

This article is based on an EMail message I sent to the software development team at Vispero on August 26, 2008. I had just spent hours debugging an odd bug in JAWS. When focus was in a particular window while JAWS was running I heard constant, rapid fire, beeping. I searched the JAWS source code for calls to the Beep and MessageBeep functions and was not able to determine the cause of the bug. I was at a loss. Then I asked the following question, is there a way I can just set breakpoints in the Beep and MessageBeep functions? This article discusses what I found during my quest for an answer to that question.