Convert breakpoints to tracepoints when debugging multi-threaded apps in Visual Studio

Breaking the code execution on a breakpoint when debugging a multi-threaded application might change the execution flow of the different threads so much that you get a totally different scenario than you will have in production.

This problem can be remedied by converting breakpoints to tracepoints. A tracepoint can write text to the Output window and continue execution without stopping.

Set a tracepoint by first setting a breakpoint, right click it and select "Actions".

The message to be logged can contain predefined variables like
$CALLER - Name of the function calling the current function
$FUNCTION - Name of the current function
$TID - ID of the current thread

You can also get the value of a variable by using curly braces, like this: {variable_name}

When a breakpoint has been changed to a tracepoint the red bullet is changed to a diamond.

One call to the method in the image above results in this text being logged:

In MineSweeper.Program.TryParseDirection(string, out MineSweeper.Direction), called with directionStr = "S"

Are the line numbers missing in the call stack of your logged exceptions?

Sometimes when being on a bug hunt it can be a great help to read the call stack of a logged exception and to be able to see which line the exception was thrown from.

So, if your logs lacks line numbers like this one below, you don't get that extra help...

System.NullReferenceException: Object reference not set to an instance of an object.
   at LineNumberDemo.Program.ThirdMethod(Int32 value)
   at LineNumberDemo.Program.SecondMethod(Int32 value)
   at LineNumberDemo.Program.FirstMethod(Int32 value)
   at LineNumberDemo.Program.Main(String[] args)

To fix that you have to change the Debugging information setting in the project's build settings. 

- Open the Properties for your project. 

- Click Build > Advanced and change "Debugging information" from "None" to "Pdb-only".

The pdb (Program database) files contains the infomation needed to map an instruction in your program to the original line in the source file. After changing that setting the log now looks like this:

System.NullReferenceException: Object reference not set to an instance of an object.

   at LineNumberDemo.Program.ThirdMethod(Int32 value) in C:\Code\LineNumberDemo\LineNumberDemo\Program.cs:line 42

   at LineNumberDemo.Program.SecondMethod(Int32 value) in C:\Code\LineNumberDemo\LineNumberDemo\Program.cs:line 35

   at LineNumberDemo.Program.FirstMethod(Int32 value) in C:\Code\LineNumberDemo\LineNumberDemo\Program.cs:line 29

   at LineNumberDemo.Program.Main(String[] args) in C:\Code\LineNumberDemo\LineNumberDemo\Program.cs:line 16

In Visual Studio 2017, "Pdb-only" is the default setting for the Release configuration, but I'm not sure it always has been, because I've seen lots of projects that did not include the pdb-files. They make the release bigger, but as long as that isn't a problem, I don't see any reason to not include them.

Good bug hunting!