When debugging in Visual Studio you can see the local variables for the current function that is running in the Locals window. You can also watch specific variables by right clicking them and clicking Add Watch.
However, when watching a variable in a recursive function, it will only show the value for that variable for the latest iteration of the function call the recursion has progressed to.
Is there a way to view the variable contents of each iteration of a recursive function call and have them displayed together in the Local/Watch windows?
I've researched the problem further and found the Parellel Watch functionality within Visual Studio.
While in Debug mode, once hitting a breakpoint you can click
Debug > Windows > Parallel Watch
Which keeps track of multiple threads open for the watched function, allowing you to select and inspect the local variables for each thread.
https://learn.microsoft.com/en-us/visualstudio/debugger/how-to-use-the-parallel-watch-window?view=vs-2019
This is not possible in Visual Studio. You may consider other ways, such as logging/outputting(Debug.WriteLine, Trace.WriteLine…) the value of variables in the function, or installing some extensions to help log value of variables.
Related
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.
I installed the Unity Tools for Visual Studio.
Now I created a variable x which is incremented on every frame at the Update function.
private int x = 0;
void Update()
{
x++;
}
However, if I go to visual studio and press "Attach to unity and play" and then hover over x at x++ then I don't see any value.
If I right click on x then there is no option add watch or similar.
I can only see the value if I set a breakpoint, but then I have to hit continue after every frame.
Is it possible to add a watch and see the value how it is updating live while I play? Otherwise I have to add many Debug.Log() statements everywhere in my code for each variable which I need to watch, but I don't think that this is the intended way.
There is an article where the author says:
When I was in school the first way I learned how to debug a wonky
application was by sticking “print()” statements all over the place,
running my code, and looking back through the log of output seeing if
I noticed that something looked wrong. Then if I wanted to look at the
value of another variable I would have to add a new “print()”
statement, recompile, and re-run the application again. This can be a
tedious process, so I am pleased to tell you there is a better way
than littering your code with a slew of “print()” statements you’ll
have to remove later. You can use the tools of the Visual Studio
debugger to inspect variables on the fly.
But this does not seem to be true.
You can't inspect variables without pausing at a breakpoint. Alternatively you can observe them in Unity's inspector. To do so:
Switch the inspector to debug mode (right click on the tab)
Set it public temporarily
Use the [SerializeField] attribute temporarily
This does not work with visual studio, you need to use Debug.Log() for every variable which you need to track.
void Update()
{
x++;
Debug.Log(x);
}
Let's say I have function A(//Code: To Catch Some Error) in a class and that function A() is being called in 100 different pages.
I have put one breakpoint at that function A().
When I run the solution in the visual studio, this breakpoint is being hit.
Q: Is there any way to find from which page did this function A() was called before hitting the breakpoint?
Your best option is looking at the call stack. When you hit a breakpoint Visual Studio will by default include Call Stack window among the windows that appear below your main code window. You will see a list of nested function calls that took you to the breakpoint. Double-clicking on any of the functions should open it in the debugger, assuming you have the source code for it (some of them will be system functions).
Basically my problem is that I expect Visual Studio (2010 Professional) to be able to evaluate any Visual C++ expression in the watch window that it handles in the code I'm debugging, but apparently there's something preventing this from happening. For example, when dealing with CStrings, evaluating the method IsEmpty on the CString in the watch window gives me a Member function not found error, as does a basic equality comparison (in the code being debugged obviously no problems).
Am I missing something here, or is what I'm asking for too much? Obvious solution would be to put debugging statements in my code for whatever CString operation I'm looking for, but I would prefer not to have to do this.
Update/Example:
CString blah = _T("blah");
Calling blah.IsEmpty() in my code works fine, but in the watch window of the debugger I get the error above (CXX0052). The contents of the variable blah can be seen the watch window.
I could reproduce your problem, and, indeed, the VS watch window shows Member function not found alongside with the error code CXX0052.
In the MSDN documentation I found that this problem arises due to a call of a inlined function, the CString::IsEmpty() member function is probably somehow inlined (this is what the Watch Window evaluator sees), to solve the problem, first open your project Configuration and disable inlining
Second, still in the project Configuration, choose Use MFC in a Static Library (somehow the Watch Window keep seeing the called function as an inlined one if you use it as shared library, maybe this is because in the Shared Library the code is inlined and the Watch Window evaluator don't use the Debug builds of such runtime libraries).
Third, clean and Rebuild your Solution.
After that, the problem should be fixed (remember to refresh the expression if you see the value grayed out in the watch panel) during debugging. Remember to switch back to your original Debug options or better, create a new Debug profile to keep this settings.
Normally in Visual Studio, a watch cannot be evaluated unless the debugger is stopped at a breakpoint. Is there a trick or add-on to make Visual Studio evaluate a watch while the application is still running? For example, evaluate the watch every time execution passes a point in the code while it's still running and without changing the code to insert statements like Debug.WriteLine.
Not sure this is possible, but I thought I'd ask.
Yes, this is possible. Set a breakpoint at the location where you'd want to see the value. Right-click the breakpoint and choose "When Hit...". Tick "Print a message" and write an expression like { value }. The message is displayed in the Output window while your program runs.
I would do that using compiler directives.
#if DEBUG
Debug.WriteLine
#end if
No this is not possible to do. The evaluation feature in Visual Studio is a stack frame based mechanism. That is that every evaluation is done in the context of a given stack frame (as viewed through the stack window). When the program is running the set of stack frames is currently changing and hence it's not possible to do a stable evaluation.
Additionally there are other limitations in the CLR which prevent this from managed code. It's not possible for instance to execute a function unless the debugee process is in a very specific state.