In VS2010, I set a break point (from the left gutter of the editor) on a line of code. After I removed the break point, the debugger always breaks on that line of code. After starting visual studio, the debugger still breaks at the point.
Thanks in advance!
Are you removing the breakpoint while the program is running? I find that VS 2008 (and 2010) only disables the breakpoint then, but re-enable it on the next program invocation. If so, try removing it while the program is not running. Otherwise I have no idea.
use control+shift+f9 or goto your Debug menu and delete all breakpoints. It might be some weird bug..
Is there a debugbreak statement in there or an asm int 3 call?
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!
I need to stop at breakpoint in case when other breakpoint was passed. Is it possible realize in VC++?
Why did you debug your two breakpoint using this way? If the debugging runs to the specific code line, it would call the conditional, and then trigger the conditional breakpoint, if it just runs to A code line, I don't think it could call the conditional in B code line unless it really calls/runs to this line.
I do c#, and I know JetBrains Rider has exactly the feature you want. Called Dependent breakpoints. So I guess their c++ IDE CLion also has the feature.
In Visual Studio, you can manually do this. Set up the two breakpoints, disable B first. Run the code, after A got hit and the execution suspends, then enable B, press continue.
How can I find out which line will be executed after performing any action?
If I know what will be executed I can put break point there. But what if I am not sure where to set breakpoint or just I need to go to the executing line faster (without setting breakpoints).
"Break All" is not what I look for. It is pausing debugging, so I cannot perform any action (just after which I want Visual Studio sets breakpoint automatically)
In other words, for example I want to start debugging each line after clicking a button, without putting breakpoints. Is it possibile?
For a .NET application you can use my Runtime Flow tool (30-day trial) to see code that is executed after some action.
Set a breakpoint at the line you want to stop after. Then once the breakpoint is hit Step Into or press F11 in Visual Studio. This takes you to the very next line of code that executes, no matter where it is in the project.
This is occurring in Visual Studio 2005, in an ASP.NET Web Application.
For example, if I try to set a breakpoint in the following code:
if (frustrated)
{
bool cry = true;
} <-- breakpoint here
It will set the breakpoint on the indicator margin, but when I actually hit F5 to debug the application, the breakpoint will flicker on and off (the little red circle literally vanishes then reappears) before disappearing altogether. Other breakpoints will work, just not ones ending on a closing bracket. This used to work, until I installed then uninstalled ReSharper (either it broke it, or its just coincidence).
EDIT: Just to reiterate - this is something that used to work, but doesn't anymore. I know I can put the breakpoint on a different line, but this is not what I want to do. I want it to work normally again.
EDIT 2: Resetting all of my settings did not help.
Any ideas?
Set the breakpoint on the line above it, instead of a closing brace.
If the breakpoint turns from a solid circle to an empty circle it indicates that the breakpoint could not be set usually because of a mismatch between the code and the actual binary module being loaded. This can be fixed by building or rebuilding suspect modules.
All projects opened while ReSharper was installed were affected. I went through each project and deleted the .suo file. After that, life was good - I can set breakpoints again!