Is there any tool I can use to view the values of variables live as the code executes in VS?
Right now I can see them only when I keep a breakpoint.But,the problem is that the code works perfectly fine when I keep a breakpoint.it messes up only when it runs fast.
Any help would be appreciated.
Thanks
You can only view variables when you have a breakpoint, however you could just manually write the variable values to the Visual Studios Output window:
System.Diagnostics.Debug.WriteLine(variable);
I my opinion , rather than setting break points, you can use Debug.Write(yourVariable) under the Debug mode, so you can watch the value in the output windows.
Cheers.
Sounds like you need a conditional breakpoint. Aside from printing the values (console, debug output, trace) as the code runs there is nothing that will show you live data slow enough for you to see it. Put a conditional statement in detecting when the values are no longer valid and stick a programmatic break point on that.
Use Debug.Write to print out the variables. You can also use profiler.
All the aforementioned methods (dumping to console, using Debug.Write, custom logging, etc. etc.) to dump the contents of variables will do the trick .
From your problem description however (i.e. "...works fine with breakpoints, fails when left alone to run..."), it sounds like you have a threaded scenario with synchronization issues. If that's the case, inspecting the synchronization methods used might yield better results.
In visual studio 2010 (maybe in earlier versions, I didn't check) the conditional breakpoint can be set to print a variable value and continue running. It is done by right clicking the breakpoint and choosing 'When hit'. Then it opens a dialog in which you can specify what and how to print.
It worked fine for me in a native C project.
Related
I am writing a C# application. I have some objects with some lazy properties that actually do quite some work when you request their values.
I want to be able to check if they are called by the visual studio debugger when debugging and not execute them at all. For example when I click on an object with these properties then it shouldn't load them at all.
How can I do this?
Consider using DebuggerBrowsableAttribute:
[DebuggerBrowsable(DebuggerBrowsableState.Never)]
The docs state:
Never -> Never show the element.
https://lostechies.com/jamesgregory/2009/08/18/debugger-property-evaluation-side-effects/ also briefly discusses the attribute.
Besides the excellent suggestion of #mjwills, if you don't have the source code or don't want to modify it at this point in time, turn the feature of in VS:
Hi I have been shifted from VS 2013 to 2015 presently. So I am not too much familiar with in depth specifications.
I like VS 2015 as it allows me to evaluate lambda expressions and also it allow to me to change values runtime.
Scenario:
In some apps (winforms tested only) I am able to edit code while debugging and yes latest code is executed always i.e I don't need to stop and run the program again and againe. Yes it is very excellent feature.
But in case of my first experience at controller in MVC I am unable to edit code and it shows me multiple reasons behind this.
Can someone explain in what scenarios I can add/delete code while debugging?
Thanks in advance!
In your visual studio go to Tools->Options-> expand debugging -> select Edit and continue and then check Enable edit and continue.
here is image of that:
see screenshot
You normally cannot edit and continue if you attached to an already running process which maybe your case if you are attached to a running MVC web project. If something was load using Reflection you will not be able to edit it as well.
I have also seen sometimes a similar message appearing during debug. I found the following from MSDN regarding code changes during debugging:
The following changes cannot be applied to C# code during a debugging session:
- Changes to the current statement or any other active statement.
- Active statements include any statements, in functions on the call stack, that were called to get to the current statement.
- The current statement is marked by a yellow background in the source window. Other active statements are marked by a shaded background and are read-only. These default colors can be changed in the Options dialog box.
- Changing the signature of a type.
- Adding an anonymous method that captures a variable that hasn’t been captured before.
- Adding, removing, or changing attributes.
- Adding, removing, or changing using directives.
- Adding a foreach, using, or lock around the active statement.
More information: https://msdn.microsoft.com/en-us/library/ms164927.aspx
So, after alot of R&D i came to know that Edit and continue is NOT available for Asp.net yet. It would be released in the final version of Visual studio 15.
source: https://blogs.msdn.microsoft.com/visualstudioalm/2015/04/29/net-enc-support-for-lambdas-and-other-improvements-in-visual-studio-2015/
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.
I've been seeing this in my Visual C# 2008 RSS Feed forever now:
http://lincolnfair.net/oldLincolnFair/mad.jpg
I'm pretty sure this is a VS 2010 only feature, but I was wondering if there is anyway to replicate this in VS 2008?
Similar to #Relster I have a code snippet with the following
#if DEBUG
if( node.Name == "Book" )
System.Diagnostics.Debugger.Break();
#endif
Where node.Name == "Book" changes based on the condition I want to test for. the #if DEBUG wrapper makes sure the checks never make it to release code.
This is also a lot faster than using the conditional breakpoints in Visual Studio. When you use the built in conditional bp visual studio has to break into the app, pause all the threads, evaluate the expression and determine if it is true each time it hits the breakpoint. In a tight loop this can be the difference between near full execution performance and running at a crawl.
You can do it in VS 2008 too. I'm sure there's many ways to do it, but one way is to right click on the red dot in the margin of an existing breakpoint & select condition..., then just give it a condition that evaluates to a bool and it will only break if that's true. The conditional statement should have access to anything that's in scope at the line where the breakpoint is set.
There's also other options in that context menu that allow you to filter what will cause a break (for example only certain threads), break based on the number of times the breakpoint has been hit, run macros when you hit the breakpoint, etc.
The other way to do this is make your own conditions and use a call to:
System.Diagnostics.Debugger.Break();
While it may not be as sophisticated as the VS2010 way of setting breakpoints, you can get the same effect with minimal code overhead. Just remember to take that stuff out when you build release code.
Note: In VS2008 and VS2005, you can set a conditional breakpoint by setting a regular breakpoint (F9 or double click in gutter), and then right clicking on that breakpoint to set the "condition...". The ability to set conditional breakpoints is NOT available in the VS2008 Express Edition.
I am writing a multi-threaded Windows application in Microsoft Visual C# 2008 Express Edition. Recently, the debugger has been acting strangely.
While I am Stepping Over lines of code using the F10, sometimes it will interpret my Step Over (F10) command just like a Continue command (F5) and then the program will resume running and the debugging session will be done.
Does anyone know why this happening? In what circumstances can the Step Over command result in the debugger stopping?
It's not a problem with the code being debugged: it doesn't just happen on particular lines of code. It happens on a random line that is different each time I run the debugger.
It's not a problem with my keyboard: the same thing happens when I just click Step Over in the Debug toolbar.
It may be a problem with the other threads in my program. Maybe one of them is randomly doing something that has a side effect of interrupting the debugger. Is that possible?
Thanks in advance!
You ought to take a look at this KB article and consider its matching hotfix.
EDIT: the hotfix does solve these kind of debugging problems. Unfortunately, the source code changes for the hotfix didn't make it back into the main branch and VS2010 shipped with the exact same problems. This got corrected again by its Service Pack 1.
I've seen this a few times. It generally happens when there's a context switch to another thread. So you might be stepping through thread with ID 11, you hit F10, and there's a pre-emptive context switch so now you're running on thread ID 12 and so Visual Studio merrily allows the code to continue.
There are some good debugging tips here:
Tip: Break only when a specific thread calls a method: To set a per-thread breakpoint, you need to uniquely identify a particular thread that you have given a name with its Name property. You can set a conditional breakpoint for a thread by creating a conditional expression such as "ThreadToStopOn" == Thread.CurrentThread.Name .
You can manually change the name of a thread in the Watch window by watching variable "myThread" and entering a Name value for it in the value window. If you don't have a current thread variable to work with, you can use Thread.CurrentThread.Name to set the current thread's name. There is also a private integer variable in the Thread class, DONT_USE_InternalThread, this is unique to each thread. You can use the Threads window to get to the thread you want to stop on, and in the Watch window, enter Thread.CurrentThread.DONT_USE_InternalThread to see the value of it so you can create the right conditional breakpoint expression.
EDIT: There are also some good tips here. I found this by googling for 'visual studio prevent thread switch while debugging'.
I find using a logfile is very handy when dealing with multiple threads.
Debugging threads is like the Huysenberg principle - observe too closely and you'll change the outcome !
Try this http://support.microsoft.com/kb/957912. Worked for me.