There is an annoying bug in VS 2008 that it will stop at some portion of the code that does not have a breakpoints. Even if I remove all the breakpoints. It will still stop at those points for unknown reasons (No exception or any problems like that). The only way for it not to stop is disabling the breakpoints. It is time consuming for me in some cases; I need to go through lots of clicks in order to go through them. Any help is appreciated.
I found out I did something silly. Instead of hitting the "continue" (F5) button, I hit the "stepping out" button instead. It might be a bug in VS 2008. I thought if I had removed all the break points, stepping out means "continue" because it should never had "stepped in" in the first place. But apparently it is not the case for VS. It will stop at some part of the code even though there are no break points set.
Related
I have been given a project that is the biggest pile of spaghetti I have ever seen, with 0 unit tests or any obvious naming conventions.
I find it hard to believe there is still no way while running in Debug to have Visual Studio automatically break on the next executing line of solution code.
In this case, I know the code is hitting a specific 5000 line of code file - but there isn't even an easy way to just write a breakpoint to every single line!
Is there any logical reason why in 2017 (or even 2010) this functionality doesn't exist?
Or perhaps it does and I haven't found out how!
Is there any logical reason why in 2017 (or even 2010) this functionality doesn't exist?
Please Put a break point in your code -> debug, then Right click on the text editor in VS, you will see below:
You can use the "Break all" button in the visual studio (Ctrl+Alt+Break is the default shortcut).
You might need to switch between the running threads in order to see highlighted instruction within your code.
Then you can just continue debugging, as usual.
If you do not see any of those two controls, go to View->Toolbars and check both "Debug" and "Debug Location".
I am using the Visual Micro extension for Microsoft Visual Studio, which allows me to debug my Arduino project (in opposed to the Sketch IDE).
For some strange reason, when no breakpoints are present, it automatically adds a breakpoint at the beginning of the loop function.
When running via the debugger, I can simply remove it and continue running.
However, I cannot do the same when running without a debugger (i.e., upon power-up), since breakpoints seem to be "embedded" into the code as additional code segments (though I'm not really sure how explain the fact that the debugger allows me to remove a breakpoint).
Here is an illustration of the problem:
Now, I've been able to work-around it by adding a piece of "dead code" with a breakpoint:
if (0)
{
// insert a breakpoint here
}
But this feels kinda "clumsy".
I suppose that if there is a solution to this problem, then it lies somewhere in here:
But I have not able to find it, so any help will be highly appreciated.
Found the answer!
It turns out that all I needed was to hover on top of the breakpoint and read the tooltip carefully:
As you can read on the bottom line of this tooltip, in order to switch off that automatically-generated breakpoint, we only need to disable the Visual Micro's Tutorial Mode:
And voilà - we're all done!
It seems as though my breakpoints in Visual Studio 2012 have been persisting forever. No matter if I clear them during debugging, the red dots seem to re-appear the next time I attach to my IIS process. How can I permanently clear them? How do they get permanently set like that?
As mentioned in this link, go to Debug menu then Delete All Breakpoints Ctrl+Shift+F9 to get rid of all break points.
Or If you want to get rid of any particular break point, remove it before you start debugging (not during debugging)
If you are running in debug when you delete all break points, they won't really be deleted. After you get out of debug, and the project is not running, try to 'Delete all breakpoints' again, and it should clear them.
Recently I noticed some strange behavior when debugging ASP.NET application. When I press F10, sometimes it doesn't go to the next code line, but just stays on the same until you press it 2-3 times. And sometimes it goes to the previous line. It happens only in one library, used for this application, all other code I can debug as usual. Is it some kind of bug? Can it be fixed?
This is not a bug in Visual Studio Debugger but probably a standard behavior that is resulting from calling a multithreaded code.
This might have very obvious solution but I'm afraid I cannot find out how to disable this specific page which pops up each single time I use the break command whilst debugging. Every time I have to close it because I don't need it; moreover, it pops up any next time I use the break command on the toolbar.
I'm using Visual Basic Express Edition 2010
How can this be disabled?
Thanks.
Just don't use Debug + Break All. It is typically useless anyway because it is pretty unlikely that you'll break your own code. Which is what the window is telling you. Set a breakpoint on a line of your own code, the code you want to debug or verify. Clicking in the left margin will set one.