views:

116

answers:

9

I am trying to debug a windows form application which has a large number of events: button presses, timers, etc..

Is there a way to catch every line of code being executed by the application without setting a break point?

edit: The program was not written by me, so I am unfamiliar with the code. I wish to step through the entire program, catching every line of code being executed. Setting break points in every event is impractical as various controls are created dynamically.

A: 

Not really, but you can set one breakpoint and single-step (F10/F11) through the rest of the code.

klausbyskov
Thanks for the fast reply. But the problem is that I can't catch code thats being run within events
Ying Chan
@Ying - You need to set your breakpoint inside the method event handler (unless I have miss-read you)
Kragen
The problem is that this solution is highly impractical as the program is large and complex
Ying Chan
You can set breakpoints programatically on all event handlers - see eg http://stackoverflow.com/questions/841782/programmatically-apply-deactivate-breakpoints-in-visual-studio
Stuart Dunkeld
+1  A: 

Nope 'fraid not - you need to set each breakpoint yourself.

If it helps F9 is the shortcut key for assigning a breakpoint - just set a breakpoint on the start of each method and use step through (F10) / step into (F11) from there.

Kragen
+1  A: 

Why would you want to break on every line? This would be very onerous and time consuming. If you want to see the activity of your program as it executes, use a logging mechanism or Debug.Writeline to output information to the Immediate window.

Dave Swersky
I've misused the term debugging. The program was not written by me, so I am unfamiliar with its operation. I wanted to be able to step through every line to see how it works.
Ying Chan
You can set a breakpoint at the first line of execution, then step through the execution line-by-line (can't remember the keyboard shortcut.)
Dave Swersky
I might be doing it wrong.. but from my experience this doesn't catch code that is run within events without the use of breakpoints.
Ying Chan
+1  A: 

You cannot trace lines of code, but you can use Trace.TraceInformation calls where you want to have an idea of what's executed. There's also Debug.Write. Both output will write in the output window of Visual Studio.

Another solution would be to add logging to your application, for example with log4net, but that may be overkill for your needs.

samy
+1  A: 

This isn't exactly what you're asking for, but in case you didn't know you can toggle an existing breakpoint on or off. In your case, you could add break points at key places throughout your code and just disable them when you don't want to debug them. That way, you'll be able to re-enable them later when you want to use them again.

Enabling/disabling is available through the Breakpoints window found under the Debug > Windows > Breakpoints menu (CTRL+D, B). You can also include "Function" and "File" columns in the window, which might help you identify which breakpoints are in the event handlers that you care about

Dr. Wily's Apprentice
A: 

Hi there.

You could also try a code coverage tool.

For example, if you have Resharper and dotCover, you can run your application (via the dotCover->Cover Application... menu item) and when the application finishes, dotCover will show you which lines of code were run in the VS IDE by highlighting them in green. Lines of code which where not run are coloured in red.

I don't know if there are other tools which do this, but it's an option.

Cheers. Jas.

Jason Evans
+2  A: 

If you're using the Ultimate edition of your Visual Studio 2010 you can use its new feature called IntelliTrace (previously Historical Debugger). This will allow you to do exactly what you want - be able to see all method calls and events that happened during execution of your program, and you'll be able to jump back to the event which you need.

To enable IntelliTrace, go to Tools → Options → IntelliTrace, and check the "Enable IntelliTrace" checkbox, and select one of two modes: "events only" or "events and call information", then run your application with a debugger (F5).

The difference between the two modes is that the later uses the profiler to collect all runtime information, so you get a complete call stack, however you won't be able to use edit-and-continue features of the debugger.

You can find more in this series of articles, and of course, on MSDN.

hmemcpy
this sounds like the perfect solution for me. Is it available for Professional? I'm currently researching this and will update
Ying Chan
Unfortunately not, this is one of the features that's only available with Visual Studio Ultimate :(
hmemcpy
Also, I believe you can download the [trial version of Ultimate](http://www.microsoft.com/downloads/en/details.aspx?FamilyID=06a32b1c-80e9-41df-ba0c-79d56cb823f7).
hmemcpy
thats what i'm doing right now :) I'm particularly excited about the "time travelling" feature. if intellitrace is enabled, are you still able to step through code at the same time?
Ying Chan
Yup, IntelliTrace is a debug-time feature, I believe you can step through the code either normally with F10.
hmemcpy
A: 

For debugging a button click without setting breakpoints:

  1. Start the app with the debugger.
  2. Get to the state immediately before the intended click.
  3. Go back to the debugger and press Pause then F11 (Step Into) -- nothing will happen.
  4. Go to the app and press the button -- the debugger should take over and drop you into the event handler.

Note: This will not work if Paint, any Mouse event, or probably some other events are handled. The debugger will drop you into those handlers any time you attempt the steps above.

Austin Salonen
A: 

I developed the Runtime Flow tool to solve exactly this problem - to understand a large unfamiliar .NET codebase via realtime function calls monitoring. It's similar to IntelliTrace, but places more emphasis on control flow than on debugging.

Sergey Vlasov