I recently started having problems with breakpoints in Visual Studio 2010. When I set a breakpoint and then start debugging, another breakpoint appears on some other line nearby. The screenshots below shows the editor after I set a breakpoint, as well as the breakpoints window:
As soon as I start debugging, the breakpoint duplicates, as seen in the following screenshots:
Why is this happening and how can I stop it?
It looks like there is a child breakpoint set up, as described in the following MSDN articles:
http://msdn.microsoft.com/en-us/library/b98cwcyw.aspx (Link dead, see
Child breakpoints VS 2010)
http://msdn.microsoft.com/en-us/library/02ckd1z7%28VS.71%29.aspx#vctskbreakpointswindowchildbreakpoints
Here is a similar question on StackOverflow, for which one of the answers contains a macro to remove child breakpoints. Perhaps that might work for you?
Disable/remove child Breakpoints?
Alternatively, deleting the parent breakpoint (which will also remove the children) and re-creating it might help to resolve the problem.
I suspect it is because of mismatched newline endings. I had similar issue - multiple lines were marked as breakpoint location (say, 10 lines). Later I found it was because of only \n or \r present, instead of CRLF sequence.
Use Save-As, select Save With Encoding.. option under Save button in SaveAs dialog box.
I had the same problem in VS 2008 and I resolved by getting rid of the duplicated .dll files in the compiling / debugging folders.
Please refer to my full response here: https://stackoverflow.com/a/50063517/3603386
Do you use F10 (step over) when debugging?
F9 is the shortcut to add/remove a breakpoint, you may be inadvertently hitting that.
Related
I am working with Visual Studio 2015.
I have a big c# class file with lot of properties and methods. I want to set breakpoints to all possible lines (set and get of properties, methods) at once. How can I do that?
You could add Debugger.Break() on the end of every single line. Therefore you could use the search and replace function of visual studio and replace \n with Debugger.Break()\n (Remember activating the regular expression option). This would cause the debugger to break at every single line, even though you won't have an indicated breakpoint.
I don't think that there's a method to add normal vs breakpoints to every single line though, due to the fact that it's quite useless, considering that you normally just step through the code with F11.
I think you are looking for this,
steps to follow:
1) Add a break point on the first line of code you want to debug.
2) Run the application.
3) When you want to run the next line of code, Select Debug | Step Into
4) Repeat step #3 for each line of the code
With vim (vsvim) you can set a breakpoint, move down a line, then repeat however many times you like, eg:
{Escape}qq:vsc Debug.ToggleBreakpoint{Enter}jq100#q
will set breakpoints on the next 100 lines
edit: here is example video, wouldnt let me embed gif https://imgur.com/SFhlEr7
Step Into(F11) or use the Debugger.Break() or add breakpoint directly would be the workarounds for you, of course, I suggest you use the Step Into(F11) which was much more convenient.
If you could use the latest VS2017 version, it has a new feature "Run to Click" which is also a better workaround for you during debugging.
Actually you don't have to debug every line code, that's also the reason I suggest you use this new feature.
Run to Click: Simply click the icon next to a line of code while debugging to run to that line. No longer set temporary breakpoints or
perform several steps to execute your code and stop on the line you
want. Now while stopped at a break state under the debugger, the Run
to Click icon subtly appears next to the line of code that your mouse
is hovered over. Move your mouse to the icon and click the button, now
your code will run and stop on that line the next time it is hit in
your code path. Turn it off from Debug> Options > Enable Run to
Click.
Reference:
https://www.visualstudio.com/en-us/news/releasenotes/vs2017-relnotes
Open a feature request with Microsoft https://learn.microsoft.com/en-us/visualstudio/ide/suggest-a-feature?view=vs-2022
There should be a mode that visual studio can be put in so that it automatically stops on every line of code in a particular project. This would be VERY valuable when you attach the debugger to a pre-existing process and you don't know where in the app is the current point of execution is, ie: web apps where you do not know the entry point.
Hello, I don't know where I should ask this question, but I found hard to continue my C# project while I can't debug it. When I start I see "Unexpected character" instead of objects in my watch. You can see problem on picture linked above. But when I move cursor to objects, I see what they have. What should I do?
Thanks in advance.
Watch != Locals window.
Simply delete that entry from watch window (it is probably what is left from previous debug session). It's not necessarily existing variable name (you can insert any text into watch window):
I recently started having problems with breakpoints in Visual Studio 2010. When I set a breakpoint and then start debugging, another breakpoint appears on some other line nearby. The screenshots below shows the editor after I set a breakpoint, as well as the breakpoints window:
As soon as I start debugging, the breakpoint duplicates, as seen in the following screenshots:
Why is this happening and how can I stop it?
It looks like there is a child breakpoint set up, as described in the following MSDN articles:
http://msdn.microsoft.com/en-us/library/b98cwcyw.aspx (Link dead, see
Child breakpoints VS 2010)
http://msdn.microsoft.com/en-us/library/02ckd1z7%28VS.71%29.aspx#vctskbreakpointswindowchildbreakpoints
Here is a similar question on StackOverflow, for which one of the answers contains a macro to remove child breakpoints. Perhaps that might work for you?
Disable/remove child Breakpoints?
Alternatively, deleting the parent breakpoint (which will also remove the children) and re-creating it might help to resolve the problem.
I suspect it is because of mismatched newline endings. I had similar issue - multiple lines were marked as breakpoint location (say, 10 lines). Later I found it was because of only \n or \r present, instead of CRLF sequence.
Use Save-As, select Save With Encoding.. option under Save button in SaveAs dialog box.
I had the same problem in VS 2008 and I resolved by getting rid of the duplicated .dll files in the compiling / debugging folders.
Please refer to my full response here: https://stackoverflow.com/a/50063517/3603386
Do you use F10 (step over) when debugging?
F9 is the shortcut to add/remove a breakpoint, you may be inadvertently hitting that.
Suddenly when I am debugging, say I remove a break point I no longer need then hit play or restart my program, and suddenly the same break point is back.
I clear it again save, and it is back again.
In some cases I remove a break point in others I add a break point.
It seems at random it either brings back or removes the break point or moves the existing break point a line or 2 to the wrong spot.
I have tried restarting VS a few times which works at first but for only a short time.
I have never seen this before and it scares me VS could be behaving so badly.
Is there any easy solution such as clean break points (I would rather not remove all of them)?
In my experience, the behavior you describe is a sign that the .suo-file (solution-wide user options - located in the solution folder) is corrupt. To test this, you can rename or move the file to an other folder. After that, all your breakpoints and many other settings (e.g. which code-files were opened) will be gone, but the breakpoints should behave as usual again.
Edit:
If you don't want to lose your breakpoints, you can export and import them from the breakpoints-window. I think this is a new feature of VS2012 (I tried it in the Premium Edition).
An other possibility is that you are encountering a "feature" that is described here:
http://connect.microsoft.com/VisualStudio/feedback/details/391642/permanently-remove-a-breakpoint-in-visual-studio-during-debugging
I am trying to debug a windows form application which has a large number of events: button presses, timers, etc..
Is there a way to catch every line of code being executed by the application without setting a break point?
edit:
The program was not written by me, so I am unfamiliar with the code. I wish to step through the entire program, catching every line of code being executed. Setting break points in every event is impractical as various controls are created dynamically.
For debugging a button click without setting breakpoints:
Start the app with the debugger.
Get to the state immediately before the intended click.
Go back to the debugger and press Pause then F11 (Step Into) -- nothing will happen.
Go to the app and press the button -- the debugger should take over and drop you into the event handler.
Note: This will not work if Paint, any Mouse event, or probably some other events are handled. The debugger will drop you into those handlers any time you attempt the steps above.
If you're using the Ultimate edition of your Visual Studio 2010 you can use its new feature called IntelliTrace (previously Historical Debugger). This will allow you to do exactly what you want - be able to see all method calls and events that happened during execution of your program, and you'll be able to jump back to the event which you need.
To enable IntelliTrace, go to Tools → Options → IntelliTrace, and check the "Enable IntelliTrace" checkbox, and select one of two modes: "events only" or "events and call information", then run your application with a debugger (F5).
The difference between the two modes is that the latter uses the profiler to collect all runtime information, so you get a complete call stack, however you won't be able to use edit-and-continue features of the debugger.
You can find more in this series of articles, and of course, on MSDN.
You could also try a code coverage tool.
For example, if you have Resharper and dotCover, you can run your application (via the dotCover->Cover Application... menu item) and when the application finishes, dotCover will show you which lines of code were run in the VS IDE by highlighting them in green. Lines of code which where not run are coloured in red.
I don't know if there are other tools which do this, but it's an option.
I developed the Runtime Flow tool to solve exactly this problem - to understand a large unfamiliar .NET codebase via realtime function calls monitoring. It's similar to IntelliTrace, but places more emphasis on control flow than on debugging.
Why would you want to break on every line? This would be very onerous and time consuming. If you want to see the activity of your program as it executes, use a logging mechanism or Debug.Writeline to output information to the Immediate window.
You cannot trace lines of code, but you can use Trace.TraceInformation calls where you want to have an idea of what's executed. There's also Debug.Write. Both output will write in the output window of Visual Studio.
Another solution would be to add logging to your application, for example with log4net, but that may be overkill for your needs.
This isn't exactly what you're asking for, but in case you didn't know you can toggle an existing breakpoint on or off. In your case, you could add break points at key places throughout your code and just disable them when you don't want to debug them. That way, you'll be able to re-enable them later when you want to use them again.
Enabling/disabling is available through the Breakpoints window found under the Debug > Windows > Breakpoints menu (CTRL+D, B). You can also include "Function" and "File" columns in the window, which might help you identify which breakpoints are in the event handlers that you care about
Not really, but you can set one breakpoint and single-step (F10/F11) through the rest of the code.
Nope 'fraid not - you need to set each breakpoint yourself.
If it helps F9 is the shortcut key for assigning a breakpoint - just set a breakpoint on the start of each method and use step through (F10) / step into (F11) from there.