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. Comments (14)

      1. Brad says:

        Now that is a great idea. Also one of those features that I would NEVER find unless I saw it here first! Thanks!

      2. Daniel says:

        This is greeeeat!! I’ve used this sort of stuff before to track nasty bugs, in Delphi i think, and it’s very usefull.

      3. Barry Gervin says:

        I’m in love. This is awesome. The run a macro thing could work out to be a nice angle for punking people too 🙂

      4. Marcus says:

        Awesome! I didn’t realise u could do that with breakpoints!

      5. Chris says:

        There’s not much difference between this and a Debug.Assert statement, except that you can easily get rid of a breakpoint…

      6. ms_joc says:

        Thanks for all the positive feedback folks. Seeing this is what has kept me in the developer tools business for 10 years.

      7. While I’ve been looking at the Beta 2 of VS.Net 2005 I have come across Tracepoints.  These is a…

      8. Blog says:

        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

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