The Missing .NET #5: Tracepoints

The .NET framework is huge, but not so huge that it does everything for everyone; there are things that they in Redmond miss or don’t do for whatever reason but is still generally applicable to many developers. So, dear reader, I present to you a series of posts on stuff I find missing in .NET, typically where even the Google fails to find the answer. It could be a useful class, a technique, a good practice or documentation that should be in the framework but isn’t or isn’t widely publicized. Click here for a complete list of Missing .NET entries.

---

Lately, I’ve been debugging windowing code often. Windowing code is stuff like window sizing, resizing, painting, etc.; code that has something to do with drawing the window. Debugging that code used to be fairly arduous because anytime you stepped into your method, looked around, then started execution again, the windowing code would need to be re-run because you had Visual Studio focused and not your app; since you have a breakpoint in the windowing code, Visual Studio would break into your method which you probably didn’t want this time because you were already there, so you hit F5 again to continue execution and start the cycle over.

Do that for 10 minutes and you soon wise up; you strew print statements all over the place to get at the data you want to debug, figure out what you’re doing wrong, stop, fix, run and repeat. Once you’ve fixed your bug, then you delete the print statements if you’re not totally pressed for time, in which case, all kinds of debugging code just hangs around there forever and ever for everybody to ignore until someone comes around to delete it. Then, and only then, another drawing bug comes in starting the whole process all over again. Wouldn’t it be awesome if there was a way to break into a method to see the data without breaking in and without all those print statements? Fortunately, Microsoft thought that this scenario was painful enough that they put this feature in. It’s called Tracepoints; it’s been around since Visual Studio 2005.

We’re doing something a little different in this Missing .NET edition: highlighting something that is in the framework (well, peripheral to it, technically, but isn’t VS synonymous to .NET in everyone’s mind?), but that most people probably don’t know about, but should because it’s so useful.

I find this feature useful for the above scenario but also for bug source hunting. It’s a great way to find the source of an issue without breaking into the code and stepping into everything.

To setup a tracepoint, there are, of course, many ways to do it. My favourite is to create a breakpoint by clicking in the margin on the right of the code window, then right-clicking and choosing When Hit…

You’re presented with the following dialog:

The dialog pretty much says it all.

I always choose Print a message and delete the default. The $FUNCTION keyword prints the whole method name including namespace and parameter types which is a little too talky for me. I write out the method name, typically, and then any variables I’m interested in.

For example, the last bug fix was in a SizeChanged event handler that I traced with the following: "mainMenu_SizeChanged: {Size}, {RestoreBounds.Size}"

This prints out the Size and RestoreBounds.Size properties of the Window class in which I’m tracing.

For more on breakpoints and tracepoints, check out the MSDN documentation here.

Got any tips for using the debugger?