Is it possible to set a starting point for the debugger so that every debugging session
will start immediately from that point (instead of starting from the beginning of the code)?
Or to express it differently:
Isn't it possible to somehow store everything until the breakpoint so that next time the debugger could just instantly resume to that specific breakpoint (instead of starting from the beginning of the code and pausing at the breakpoint)?. Is there any debugger that can do this?
I am using Microsoft Visual Studio Express 2012.
Thank you.
Use a Debugger in visual studio.
In your code, click on the line number, you will see a dot on the line.
When you run the program, it will 'pause' at the line you specify, you can then walk through your program line by line from there
You can use a breakpoint at a line that you want to inspect.
You have a description how to do it here.
You could attach a debugger to a running process, but i'm afraid that it will be on a random place of execution. You could make a wait for a key or button press in your code and attach to your program before continuing.
No. It would have to run the code up to the point you want to get all the variables etc in the right state. If you just set a breakpoint where you're interested from and hit F5 it should get there quickly enough.
If it doesn't get there quickly enough, jot down the variables used and make some unit tests round the troublesome functions instead. That will skip the 10 minutes.
Related
Is it possible that Pycharm 'save' the whole staus at a breakpoint and allow the customer repeat debugging from there?
Occasionally I may need to debug a complicate bug which need ~2 hours to reach the target function. The multi-process code consists of many nested invoking and loops. The narrowing down process is pretty tricky. The first breakpoint is easy to set up. But if the second breakpoint was not set up correctly. Or there was one more clicking on 'step over' button. The debug session may exit since there was error. That is terrible since I may need another two hours to start another debugging. If Pycharm allow me to 'save' the debug status at the first breakpoint and allow me back to there whatever the current session ends or not it will be great helpful.
If I could catch up abnormal result before the session exit, then I need to step back during Pycharm debugging to figure out the issue. I searched and found out that both visual studio and IntelliJ has this ability. 'Jumping to Cursor' in Pycharm looks a similar solution. So far I don't have a chance to verify it by using a complex case.
So in genearal, what is the best strategy to debug those bugs which take long time to reach the starting point but failure point/reason is unclear? Thanks a lot.
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.
I want to see which line my program is using. For example, the program is on line 231, but I don't know that. Is there a way to do this?
While running in debug mode from Visual Studio you can:
Set a breakpoint. The debugger will kick in and pause execution on
that line.
Press the "Pause" button on the VS toolbar. Program
execution will immediately pause and the debugger will show you what
line its on.
Write code involving System.Diagnostics.Debugger (such as Debugger.Break();) where you beed the debugger to pause execution. This method has the added bonus of not relying on Visual Studio to be the debugger - if you're one of those weird-os. ;-)
Tools->Options->Text Editor->C# and the check line numbers.
Then set a breakpoint.
Only thing that comes to mind is for you to put a comment at the end of each line with the line number, then look at the comment as you step through. But that would only work in debug mode and only after hitting a breakpoint.
One major problem trying this in regular mode, running as normal, is that C# does not run. It compiles into byte code, and there is not a one-to-one correlation between C# lines and IL lines. So I'm afraid in that sense, this cannot be done.
When you break the debug in Visual Studio (through the Break All menu or the shortcut CTRL+ALT+BREAK by default), it jumps to the line of the call return.
(In my case, using winforms, it jumps to the Application.Run(); line of the Program.cs file).
It's kind of annoying when you're debugging a method and every time you hit Break All, the focus is set back on a file you weren't working on.
Is it possible to disable that jump? I couldn't find any option in the Debugging part of the VS options.
It's not "jumping" - it's breaking to the currently executing line of code. This is the behavior, and is not configurable.
If you want to have it stop at a specific line of code where you're working, you can just set a break point there, instead. This will cause it to break at your breakpoint as soon as it executes the code there.
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.