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
Related
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).
In my solution (partly c#, partly VB.NET), I am suspecting that somewhere during the execution there is a Response.Redirect that I am unaware of that destroys my page context.
There are currently 218 Response.Redirects in my code. I have set breakpoints to the usual suspects, but I'd prefer a way to tell Visual Studio to stop whenever a line with Response.Redirect is hit. Is there a way? Or an alternate debugging practise?
A more generic version of that question would be: is there a way to add breakpoints to a solution through a Find action, similar to the "Bookmark All" button? Or to "convert" bookmarks to breakpoints?
IMHO the cleanest way would be to refactor the redirect functionality into a helper, and add your logging/debugging there where there's a single point.
If you just want something quick, you could turn on Exceptions in the debugging menu, and there should be a thread abort exception that you can break on.
In Visual Studio, go to Debug/New BreakPoint/Break at Function.... Type in System.Web.Response.Redirect.
Now the debugger will break whenever Redirect is called.
If you want a specific overload of Redirect, you can add the parameters, e.g., System.Web.Response.Redirect(string)`. See MSDN for more information.
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.
Does Eclipse have an analog to Visual Studio's "Immediate Window", a window where I can evaluate statements while in the debugger?
Yes. The view name is "Display".
Window->Show View->Other
It is under the Debug folder.
Once in there you evaluate statements while in the debugger.
Eclipse has a really cool concept call Scrapbook Pages where you can evaluate statements even when you're not debugging. However, if you want to eval code using values from the current program, go to Window->Show View->Expressions. There you can put in any expression you want and track it as your program executes.
Inspect ctrl-shift-i or Display ctrl-shift-d?