Conditional breakpoints were another really important tool in solving a recent "only happens at the big installations" bug in a big and complicated C++ application. We wanted to debug the code with as few rebuilds as possible and we really didn't know how parts of it worked at all. Tracepoints helped us to figure out a lot of it in a short time. We didn't have a decent repro case though, so here's what we did:

created a script to add an audit table and some triggers that write to it

created a script to remove those triggers and the table

created a batch file to run a server in verbose mode, and redirect the output to a text file (remembering DOS commands sure can be helpful... myapp.exe -verbose >logfile.txt was the magic phrase.)

wrote some instructions for the support guy to grab a backup of the database, run the first script, run the batch file, let it run all night, then in the morning grab another backup of the database, run the second script, and stop the batch file.

Now we ran some queries on the morning version of the database to confirm that at least one X was missing a Y that should have been calculated overnight. We even had the Xid. Thanks to the tracepoint work of the previous day we knew where to be suspicious. A little digging in the trigger output told us whether the problem was "didn't get added" or "got added, but then got deleted". The last step was conditional breakpoints. These let us say "only stop here when you're processing the X with this Xid."

This really saves time when you just need to drill into what's happening in the case that is going wrong. You get to it by right clicking the red dot or diamond and choosing Condition.

The mentoring client I helped solve a big hairy bug using tracepoints does work in C# as well. She asked if tracepoints are available in C# and VB.NET too. They sure are!

As well, you can get to them other ways than just right clicking the red dot. There's a breakpoints window (reach it from the Debug menu: Debug, Windows, Breakpoints) that shows you what is set up for each of your breakpoints and tracepoints, and which you can use to enable, disable, delete, and edit breakpoints. You can also double-click a line in this window to go to that line of source:

I like to add that "Language" column when I'm working on a mixed project. Just click the Columns button and make your choices.

When you have a "mystery" bug to solve, tracepoints are a vital part of your debugging arsenal. Single stepping and looking through code can be S-L-O-O-O-O-W and if you don't even know what you're looking for, it can consume hours and hours of effort. Tracepoints really speed things up. They're like breakpoints that don't break. In a way, they go back to the old "printf debugging" -- but you don't need to make code changes and recompile to change them.

To set a tracepoint, first set a breakpoint, then right-click on the red dot that appears in the margin and choose When Hit:

In the dialog that appears, click the Print A Message box and edit the starter message you are given. You can include any expression in braces and it will be evaluated when control reaches the tracepoint:

Leave the Continue Execution box checked so that you don't break. Tracepoints are identified by red diamonds instead of red dots:

The output from the tracepoints appears in the output window of your debug session:

You can set up something suspicious, let it run, then pore through the tracepoint output and see what you learn. It's a huge timesaver when you're tackling a "we don't even know where to start" bug. Plus, if the issue is related to threading or async issues in any way (and you know me, I keep preaching we will all be facing async issues eventually) then you don't have to worry that pausing execution suppresses the collisions. I recently helped a client solve a big hairy this-stuff-fails-for-our-biggest-customer-only bug using tracepoints... and a few other tricks I will cover in upcoming posts.

Is a blog just for reading? Some blogs have way more life in the comments than the original posts (think Mini Microsoft for example, and I'm not saying the original posts are lifeless, just that the comments really take it up a notch) while others (like the one you're reading now) have very few comments. I like to think that people wander off and think about what they read, or go fix the problem in their code (hello all you broke-your-sql-reporting-services-installation people, I see your search terms in my activity list) and think nicely of me.

But here's a rather interesting blog entry. It's one word long. And that word is not all that unusual. Now I love self-reference, Godel, Escher, Bach etc, so I laughed. And I'm not alone. The commenters got it right away, drawing on a long tradition back to Usenet (at least 20 years) and then bringing in some more recent traditions. Good fun for as long as you can stand it.

From the "did you know" department: Aero is (sort of) AERO because it actually stands for "Authentic, Energetic, Reflective and Open".

These are words that can be interpreted however you like. Does authentic mean "not fake" or does it mean "true to the thoughts the user has about how to interact with the OS?" How can a UI be energetic? Does that just mean lots of bright colours, glowing jelly buttons, and animations? What does the UI reflect? And open to what?

I will say this though, they are all positive and pleasant words, and if a team held those words up as goals while working on software for me, I would expect that they would make me pleasant software. In a UI, that's a good thing.

We've all heard that we shouldn't model ourselves against pictures we see in magazines, because "they're all airbrushed and retouched". But you won't believe how true that is until you check out this portfolio by a fellow who does it for a living. He swaps new pictures in from time to time, but there's pretty well always some excellent eye bag removing, skin smoothing, and general thinning.

Before: After:

He has a nice effect on the site: first you see the "after" picture as it was used in print, then when you mouseover you see the original. Wow! Bags pop out under eyes, breasts move down, wattle, wrinkles, and pimples appear. Move the mouse off and they're back to perfection. Just astonishing. He also tackles "the clothes didn't really fit the model" and "the background is all wrong" as well as "they couldn't all come to the studio on the same day" but it's the anti-aging work I found most astonishing.

In case you had any doubt how much hard work it is to do, somebody called Mizuno lays out in a dozen steps or so how to soften up skin features to do just the unpimpling:

Before: After:

The after looks a little fake here in a close-crop, but when you see the whole picture she just looks gorgeous. Now we know.

Those of you who were interested in my loader lock topic at Tech Ed this year should probably get this whitepaper from Windows Hardware Developer Central (not actually a place I hang out regularly.) It's a downloadable Word document (8 pages) that tackles things like "what you should not do from DllMain" (this list is a page long), deadlocks, and threading considerations (and remember, we are all going to have to tackle threading considerations eventually). While it doesn't say it's C++-specific advice, in what other language could you "Use the memory management function from the dynamic C Run-Time (CRT)" or "Set global pointers to NULL, putting off the initialization of dynamic members"? It even has Vista-specific advice.

Catherine Heller, Windows Vista Technical Evangelist, is now blogging. She started during TechEd just before her session (one of the very few I attended) and so far has covered tips for interop to native APIs and some Search material. I'm looking forward to more as the summer progresses.