What are tracepoints used for?

Use case where it can prove really helpful in debugging:

There could a case when you want to debug a function which gets called numerous number of times (say in hundreds), and you may just want to see the trend in which a local variable is changing. Doing this is possible by putting breakpoint, but think about stopping(while debugging) at that function hundreds of times and taking the pain of noting down the values in notepad. Doing this is so easy by using tracepoint, it directly puts the logs in "Output" window, which can be easily analysed or even cleared. Saving hours of manual effort and patience.

Example log at Output window(can run to hundreds of lines):

keyframeNo = 2, time = 1100
keyframeNo = 1, time = 0
keyframeNo = 1, time = 1
keyframeNo = 1, time = 1
keyframeNo = 1, curTime =22
curTime=1132835, keyframeno=15
keyframeNo = 2, time = 1
keyframeNo = 2, time = 1

How to use it:

right-click mouse at code > BreakPoint > Insert TracePoint

Advantage of using TracePoint:

• There is no need to add code for generating logs. So, no tension to build the code, also no overhead of cleaning the code.
• It doesn't obstruct the flow of code under execution, unlike breakpoints.
• It can print value of local variables as well. Enter {local_variable} after clicking "When Hit"
• You can also insert tracepoints in Debugging state, just as you can do for breakpoint.

The Debugger team has a good blog post on this subject with examples as well: http://blogs.msdn.com/b/visualstudioalm/archive/2013/10/10/tracepoints.aspx

https://web.archive.org/web/20190109221722/https://blogs.msdn.microsoft.com/devops/2013/10/10/tracepoints/

Tracepoints are not a new feature at all (they been in Visual Studio since VS 2005). And they aren't breakpoints per se, as they don't cause the program execution to break. That can be useful when you need to inspect something, but not stop the program as that causes the behavior of a bug not to repro, etc.

Tracepoints are an attempt to overcome the case when you can't stop the program to inspect something as that will cause some behavior not to repro, by allowing a breakpoint to log information to the debug output window and continue, without pausing at the UI. You can also do this with macros, but it can be more time consuming.

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 and switch off the default Stop action, so that you log and go. 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.