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.
Related
Currently i'm on a project which has some main loop which is quite slow. Putting a breakpoint into it implicates i have to press F9 each time, and there are a lot of iterations. What i imagine is to see the program 'move' on one of my screens, without wondering if it is stuck or not.
I already have log outputs and so on, my question really focuses on this 'show debug without stop' feature.
What i imagine is to see in this main loop the current line highlighted as i it was a line-by-line execution, but without breakpoints and without going down in the subcalls.
Does any of you know a way to do something like this or wish the same thing ?
Thanks !
Your Debug tool window has a "Mute breakpoints" control:
If you leave it ON, your application won't stop at breakpoints. You can switch it off later once you reach the point where you actually want to start debugging (e.g. mute breakpoints while the app is doing all the initial loading tasks, while you navigate to the screen you want to debug etc. and then unmute them).
I'm not quite sure this is it but , how about disabling focus on breakpoint:
Put your cursor on the line you'd like to breakpoint and hit ctrl-shift-f8 (on a pc). You can choose not to suspend when a breakpoint is hit, and/or you can add logging that the breakpoint was triggered. If you need to, you can add a condition that must be met before the breakpoint is triggered.
Here's what this looks like for me:
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.
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.
I would like to know if there is any command or tool that can be used to start a process and then pause it immediately.
I need this function so that I can have time to attach a debugger to it. I have tried visual studio's /debugexe feature, but the behavior of the program seemed changed. So I need to find other way to attach it and debug.
Thank you.
You can use CreateProcess() with CREATE_SUSPENDED flag. This will start the process with the main thread suspended. Then you call ResumeThread() after having attached.
In your main routine insert the line:
System.Diagnostics.Debugger.Launch();
Compile in debug mode.
Run your program and it will break and prompt you to attach a debugger. If you have studio open it will ask if you want to use it to debug.
How about adding a Sleep() call as the very first statement.
You can also add a call to
System.Diagnostics.Debugger.Break();
in the code. It will suspend the program and then ask you to choose the debugger you want to use. You can then attach to a running Visual Studio instance. If you're already running from a debugger, it will simply break as if it would have hit a breakpoint.