When debugging, changes to breakpoints are only persisted for that debugging session. Once the debugger detaches the breakpoints are restored to their 'pre-debug' state.
I can appreciate this is sometimes useful, and understand why it defaults this way.
However - does anyone know if there is an option to disable this functionality (in VS2010) such that if I delete/disable/add a breakpoint during debugging the changes will persist the next time I start debugging?
You can remove the breakpoint whilst debugging by using the Breakpoint Management Window (Debug -> Windows -> Breakpoints).
From there you'll be able to remove the breakpoint in question by right clicking the relevant breakpoint and hitting 'delete'.
During debugging hit F9 on active breakpoint.
Related
I am currently debugging large project, I put a breakpoint on the starting point of the application, but it takes forever to hold f10 until it gets into the location I want it to get.
Is there any way to tell the debugger to hold f10 until it gets to a project or the namespace that I want to stop it on?
just right click on your breakpoint, there are various options for filters, location, etc.
http://msdn.microsoft.com/en-us/library/5557y8b4.aspx
When a breakpoints hits, the VS window is showed automatically and points to the line with the breakpoint. For my case that's not helping. Is it possible to prevent the VS studio window from showing when the breakpoint hits ? Thanks
EDIT: he problem is that I'm reading from a barcode scanner gun. While reading, the breakpoint hits thus switching to the VS window and some portion of the barcode is printed in the source file :) That's why I don't want it to switch to the VS window
If you set the breakpoint in the Visual Studio, you can change it to "tracepoint" by specifying "Continue execution" as "When hit".
If the breakpoint is present in the executable, it can be disabled as described in How to disable a programmatical breakpoint / assert?
You can start your application as Start Without Debugging or use (Ctrl + F5) for that.
Or If you want to debug, but not for a condition, you can provide the condition on breakpoints when to hit.
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.
I know the title is a bit ambitious, but I am wondering if there is a way, after displaying a previous state in the call stack window (Visual Studio 2010) when debugging a C# program, to restart (like when hitting "Continue"/F5) from there.
This would be particularly useful to debug a lambda expression that generates an exception, as there is no way to move outside.
For a real OO code time machine, the historical state of all objects would need to be stored in memory, so I doubt it is feasible at this stage.
Now if the state of all objects has not changed much, then we could keep the current state and jump back in time (as a shortcut to doing the same thing with "edit and continue").
Some times, you can right click on a stack frame and choose "Unwind to here" (or very similar wording). It's not always possible, and I'm not sure what the necessary conditions are, but I'm going to make a guess as to what might prevent it:
A native code frame on the call stack in the middle
Being halted at a StackOverflowException (obviously, death to a process in any case)
Maybe lambda expressions or other things that prevent Edit-and-Continue from working (?)
Basically, anything "unusual".
Other than that, if it works, then there you go!
This is a bit kludgy but:
While viewing the previous state in the call stack window, open the disassembly window (Debug | Windows | Disassembly or CTRL+ALT+D). Now you should be able to create a breakpoint which will stop execution when you get back to that location.
If you don't care what else executes, press F5 and allow the code to run back to your new breakpoint.
Now right click on the statement you want to restart from and select Set Next Statement. Press F5 to restart from there.
If you do care about what else executes on your way back to the new breakpoint you could use Set Next Statement to set the program counter to the end of the function you are in and use Shift+F11 to step out of that function (thus not executing any of the remaining logic in that function). Repeat as needed until you get back to your new breakpoint.
Note the various dire warnings about using Set Next Statement
Edit 6/18 When I tested the above I was running Visual Studio 2010 Ultimate. I just checked Visual Studio Express C# and it does not support the Disassembly Debug Window. When I can I'll check Visual Studio 2010 Professional and update this answer again. If you have Visual Studio Ultimate then the Intellitrace suggestion by #Hans is maybe a better bet.
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.