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).
Related
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.
I'm trying to debug a C++ class. It's a class that gets SWIGged for Python, then I attach debugger to python.exe. No problems there. Breakpoints are hit fine.
But in the 'Locals' window 'this' is completely empty apart from its _vfptr (which does not look right either, just values, no function names). 'this' should have a few member variables!
Function parameters are showing fine. Functions appear to, well, function properly.
Trying to 'Watch' or 'Quickwatch' a variable from the editor window gives 'inaccessible!'.
What foul Visual Studio crime have I committed? This was working fine earlier on!
I'm using VS 2010 to code native C++.
Sometimes when debugging, I have stuff like :
myFunction(arg1->getValue(),arg2->getValue(),arg3->getValue());
When steping in, the debugger goes through all the getValues() (it's a schematic example) before entering myFunction code. If I step over, it never enters myFunction code. Is there a way to make it go directly into myFunction code ?
Right-click, select the menu item Step Into Specific/myfunction
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.
Is there a way to follow a program's execution through DLL code in hex?
For example, I want to see what sections have just been read when I press a button. It has to work for x64 DLL's.
Thanks!
Yes you load the process into debugger and single step it.
Load the project in visual studio.
Press 'Play' or F5 to start the program in the debugger.
You will need to eventually halt execution sometime so you can start stepping through code or assembly code. You can do this by inserting a breakpoint, or breaking the execution by hitting the break command in the visual studio IDE.
Once halted, you can right click in the code view window, and select "Show Disassembly". Then it will show you the machine instructions.
Also in the watch window in the visual studio debugger, the right click pop up menu has an option to display all variables as hexidecimal. I'm beginning to prefer hex myself lately, because I can see invalid memory patterns easier.
You can use the tool at http://ircdb.org to log function calls arbitrary DLLs.
It's name is SocketSpy, because initially it was created for tracing winsock.dll only, but it does allow you to trace other dlls.
From http://fixunix.com/programmer/95098-tracing-library-dll-calls-win32.html
Use Option->Default Break Point List
Menu to add or remove soft breakpoints
from attached DLLs. Put soft
breakpoints only at function you need
to maximize execution time.
Soft breakpoint means that socketspy
does not stop at this breakpoint, only
log breakpoint information. Hard
breakpoint means that socketspy DOES
STOP at this breakpoint, and
Breakpoint dialog is opened. Specify
what calls should be captured ALL,
FROM EXE FILE or from DLLs (Combobox).
Specify log file File->Open Log File
menu if you want to save function
DLLs' calls into the text file, enable
logging (check box).
Then select a new or already action
process (Select Process button). The
tool can be used in NT/2000/XP only
Alternatively, there is StraceNT, which can trace arbitrary Dlls. It is available for free from http://www.intellectualheaven.com/default.asp?BH=projects&H=strace.htm
I've not used it, but I once stumble upon an Intel tool, which samples the context of the Instruction Pointer, and is able to use symbol files to convert IP to an actual function name... VTune maybe?
I guess there might be other such tools
UPDATE: aka. "statistical profilers"...
Debugging using IDE does not show you the assembly language equivalent of the execution of an IL instruction. You need to write your own hooks to a proper disassembler.