I like how you can capture breakpoints as Intellitrace events. Breakpoints are easy to add/enable/disable, and can be added/removed at runtime (as opposed to say Console events).
However, of course breakpoints stop the flow of execution, and I have to press F5 F5 F5 F5 F5 F5 constantly while I debug the running application. I'd love to be able to capture breakpoint events in intellitrace and just let the code execute without actually breaking on the breakpoints.
I've also used Console statements as captured intellitrace events, but breakpoints are much easier to add (F9 as opposed to pasting a Console.WriteLine("...") everywhere), and I can add and disable new breakpoints at runtime, whereas if I want to add or remove a Console based event at runtime, I have to stop the program, add/delete, and restart.
Are there any good ways to capture intellitrace events in this way?
I think this is what you are looking for:
http://geekswithblogs.net/sdorman/archive/2009/02/14/visual-studio-2008-debugging-tricks-ndash-advanced-breakpoints.aspx
Basically, you can use an advanced breakpoint to do a number of different things. In your case, you would probably want to use the tracepoint that simply gives a hit count. In other cases, you might want to specify that the breakpoint only occurs after a certain number of hits (maybe you want to be sure a loop isn't infinite).
Visual Studio has a ton of great features inside of the breakpoint option. I'm sure that even if the above option didn't solve your problem that there is still something that is included in the above article that will solve your problem.
Related
Currently i'm on a project which has some main loop which is quite slow. Putting a breakpoint into it implicates i have to press F9 each time, and there are a lot of iterations. What i imagine is to see the program 'move' on one of my screens, without wondering if it is stuck or not.
I already have log outputs and so on, my question really focuses on this 'show debug without stop' feature.
What i imagine is to see in this main loop the current line highlighted as i it was a line-by-line execution, but without breakpoints and without going down in the subcalls.
Does any of you know a way to do something like this or wish the same thing ?
Thanks !
Your Debug tool window has a "Mute breakpoints" control:
If you leave it ON, your application won't stop at breakpoints. You can switch it off later once you reach the point where you actually want to start debugging (e.g. mute breakpoints while the app is doing all the initial loading tasks, while you navigate to the screen you want to debug etc. and then unmute them).
I'm not quite sure this is it but , how about disabling focus on breakpoint:
Put your cursor on the line you'd like to breakpoint and hit ctrl-shift-f8 (on a pc). You can choose not to suspend when a breakpoint is hit, and/or you can add logging that the breakpoint was triggered. If you need to, you can add a condition that must be met before the breakpoint is triggered.
Here's what this looks like for me:
In all of my searching, I have not come across any trick, plug-in, or setting that would allow me to pre-populate a Watch Window for use during debugging.
The well-known steps to watch a variable in Visual Studio 2017 is to set a breakpoint (perhaps on the first instance of a variable being assigned a value), then, adding the variable to a Watch Window. On subsequent runs, that watched variable should remain in the Watch Window.
Is there a way to accomplish pre-populating the Watch Window before a debugging session? I have code that runs in a timed sequence. Taking the extended time during an execution break to pause and set up a watch causes the program to crash. Such timeout crashes while setting up variable watch objects makes for difficult interaction with the debugger. Pre-populating the watch list would help considerably.
I know that I could use a technique such as using Debug.Print(...) statements, which are printed to the Output Window during code execution. However, this doesn't allow me the control and visual feedback to my debugging efforts that comes from a Watch Window.
Watches can only be evaluated when you are paused in the debugger, say on a breakpoint. They can't be evaluated during normal execution. Your options to get around this limiation are:
Add Debug.Print(...) or something similar to your code that outputs a value.
Similar to #1 add a TracePoint which you'll find in the actions setting of a breakpoints setting (that's the gear icon when you hover over a breakpoint). When the TracePoints are hit they will then evaluate the expression that you specficied in the actions window and log it to the Output window. The advantage of TracePoints over adding your own logging is that you can turn it off and on without building your code. More info at: https://learn.microsoft.com/en-us/visualstudio/debugger/using-breakpoints?view=vs-2019#BKMK_Print_to_the_Output_window_with_tracepoints
Use the VS Enterprise only feature Snapshots which is part of IntelliTrace. Basically set your breakpoints but rather than stopping on them to look at the watch just continue. Each time you stop a snapshot of the process will be taken capturing the state of your application at that time. Then once you're finished use the Diagnostic Tools window to select each of the snasphots and activate them. For each snapshot you can use the debugger just as if you stopped the application. So you can use watches and inspect etc. Of course you can't step as the app has already ran but you can go to the next snapshot etc. More info at: https://learn.microsoft.com/en-us/visualstudio/debugger/view-snapshots-with-intellitrace?view=vs-2019 and https://devblogs.microsoft.com/visualstudio/step-back-while-debugging-with-intellitrace/
How Can Watch Variables be Configured in a Watch Window Before Running
a Debug Session in VS2017?
I'm afraid the answer is negative.For now,the Watch window can only be configured after the debug session start.It's like a runtime window only occurs during debugging.
So we can't pre-populate it before debug session for now. In other words, it's by design.
As alternative ways,you can follow Andy's detailed suggestions above.
And since your needs is meaningful in some specific debugging situation, you can also post your suggestion on development community like a user voice to add a new feature.
When I am debugging in Microsoft Visual Studio 2017 my "Registers" window shows no data available. What can I do to fix this?
As Sneftel stated, you cannot inspect data in the debugger unless you break the execution of the process. During execution, things would be changing far too quickly for any data display to be meaningful.
You can use the "Pause" button in the toolbar to break execution, and then you will see everything in the debugger: the current source line, the contents of registers, your "watch" variables, the full contents of memory in the "Memory" window, etc.
You can also set a breakpoint on a particular line of code, and then execution will break once that point is reached.
Once paused, you can then single-step through your program's code. This means that one line of code (the very next one) will be executed, and then the program will break again so that you can see everything in the debugger. This is an excellent troubleshooting technique—one that you should be well-acquainted with. In fact, I recommend that you single-step through every line of code that you write, just to make sure that it works correctly. You can also modify the contents of registers and variables (or, really, any location in memory) while you are single-stepping, giving yourself a way to test potential bug fixes or even introduce bugs (e.g., invalid input) to see how your code handles them. The default keyboard shortcut for single-step is F11.
You'll find more information about using the debugger, and the available keyboard shortcuts, here on MSDN. As you can see, that article confirms my answer:
Most debugger features, such as viewing variable values in the Locals window or evaluating expressions in the Watch window, are available only while the debugger is paused (also called break mode). When the debugger is paused, your app state is suspended while functions, variables, and objects remain in memory. While in break mode, you can examine the elements' positions and states to look for violations or bugs.
(Edit-and-continue is not available in assembly projects. You will need to stop execution and rebuild if you want to make changes to your code.)
For those with the "No data available" message, you can right click in the Registers window and choose what you want to see (UC, MMX, SSE, etc). It seems like by default there's nothing selected in Visual Studio 2019. At least, on mine there was nothing selected.
I'm not talking about Disable All Breakpoints or Start without Debugging.
For example, I have my breakpoints set, including some in loops. I get to a point where I just want the code to run through, without having to disable or toggle off each breakpoint. I want the breakpoints to stay enabled for my next run, but I just want the current execution to complete.
If not, definitely nice to have.
You could use Debug -> Detach All which detaches the debugger but leaves the process running.
When i am debugging my program and an error occur, the debug session ends, but the program remains in memory. Using the activity manager of Windows to close it does not work. I need to close Visual Studio in order to kill the process.
Why is this happening?
When during debugging a program error occurs, the program usually does not "end". Instead, the debugger (VS2010) pauses execution, allowing you to inspect the code resulting in the error. Depending on the language used (e.g. C#) and the way you compiled your program, you may even be able to edit the program on the fly, move the execution cursor back a bit and continue the program from there.
If the Debug toolbar is visible (in my case it shows up automatically whenever I'm debugging), you should see a couple of "playback" buttons, allowing you to start/continue, pause, stop your program etc. If you stop your program, it will be gone from the task manager too.
As I mentioned in a comment on your question, you can also use the Debug menu to accomplish these tasks.