Welcome to MSDN Blogs Sign in | Join | Help
Tracepoints!

Now that Beta1 is out, I'd like to draw attention to the little known new debugger feature called tracepoints.  What are tracepoints you ask?  Well tracepoints are a cure for a couple of things I found myself doing countless times while tracking down nasty bugs:

  • Stopping the program to inspect something at a breakpoint meant no-repro of the bug, so I ended up smattering trace statements throughout the code.  Not very helpful when debugging a deployed program with no way to update the binary however.
  • Sitting at breakpoints copying down information onto yellow stickys or notebooks as I hit the breakpoint 50 or more times.  Joyous.  Or worse still, copying down callstacks when you get to ::AddRef and ::Release.  Extra joy.

      Tracepoints are an attempt to overcome this situation by allowing a breakpoint to log information to the debug output window and continue, without pausing at the UI.  Originally I tried to do this with macros, but found it was too expensive

      To set a tracepoint, first set a breakpoint in code.  Then use the context menu on the breakpoint and select the “When Hit...” menu item. 

      You can now add log statements for the breakpoint like “now I'm here”, and switch off the default “Stop” action, so that you “log and go”. 

      As you can see there is a host of other info you can add to the log string, including static information about the location of the bp, such as file, line, function and address.  You can also add dynamic information such as expressions, the calling function or callstack.  Things like adding thread info and process info, can help you track down timing bugs when dealing with multiple threads and/or processes.

      So you are all set.  I hope that this is a useful feature for folks, I know it has already saved me while debugging some tough problems.

       

    1. Posted: Friday, July 02, 2004 1:21 PM by ms_joc

      Comments

      Andy Pennell's WebLog said:

      # July 2, 2004 1:44 PM

      Andy Pennell's WebLog said:

      # July 2, 2004 1:44 PM

      Brad said:

      Now that is a great idea. Also one of those features that I would NEVER find unless I saw it here first! Thanks!
      # July 2, 2004 2:11 PM

      Daniel said:

      This is greeeeat!! I've used this sort of stuff before to track nasty bugs, in Delphi i think, and it's very usefull.
      # July 2, 2004 2:21 PM

      Barry Gervin said:

      I'm in love. This is awesome. The run a macro thing could work out to be a nice angle for punking people too :)
      # July 9, 2004 4:23 PM

      Marcus said:

      Awesome! I didn't realise u could do that with breakpoints!
      # July 16, 2004 12:27 PM

      Chris said:

      There's not much difference between this and a Debug.Assert statement, except that you can easily get rid of a breakpoint...
      # July 19, 2004 2:07 AM

      ms_joc said:

      Thanks for all the positive feedback folks. Seeing this is what has kept me in the developer tools business for 10 years.
      # July 27, 2004 3:50 PM

      GarethJ's WebLog said:

      # August 16, 2004 9:18 PM

      Di .NET e di altre amenit said:

      # August 27, 2004 3:44 AM

      MikeWo's Musings said:

      While I've been looking at the Beta 2 of VS.Net 2005 I have come across Tracepoints.  These is a...
      # May 26, 2005 8:01 AM

      K. Scott Allen said:

      # June 23, 2005 10:53 PM

      Blog said:

      http://blogs.msdn.com/ms_joc/archive/2004/07/02/171960.aspx

      I don't know why I keep writing about VS2005. Currently the CTP and beta has caused me so much grief that I avoid using it at all costs. I do find a certain feature amusing however: tracepoi
      # July 26, 2005 5:04 PM

      Mike Stall's .NET Debugging Blog said:

      Here's a list of things that may slow down execution under a debugger. I've seen a few threads go by

      # October 23, 2006 12:02 PM
      Anonymous comments are disabled
      Page view tracker