A debugging tale
In my opinion, one of the best feelings in life is when you finally solve a great bug. I have a hyper-focus personality, so I really hate it when I have to go home with my problem unsolved. I have a really hard time not thinking about it. For six days now, I have had to go home without solving my bug. But not today. Today, I know why the debugger sometimes waits for 1 second in the middle of processing a command. Today, is a wonderful day. I love it.
Anyway, I figured I would give a few tips that I have learned/re-learned over the last six days:
- Don’t spend hours randomly poking around with the debugger. This works fine for the easy bugs. For the hard bugs -- get a theory as to what is going wrong, and try to prove or disprove it. You can spend forever in a debugger otherwise.
- Use in memory tracing for races. If you have a sensitive race, make yourself a circular buffer and do some in-memory tracing. You can attach the debugger after the problem has happened to look at the trace.
- Detours can be a great debugging tool. I used Detours to trace calls to a bunch of interesting APIs. Sure, I could have set a function breakpoint on them, but that would have been way too slow.
- Debug across boundaries. Its hard to convince other teams to spend days looking into bugs that are important to you, and not them. If you want a bug fixed, be prepared to read their code, and debug through it.
- I will spare you all the details, but don’t after six days, I have this piece of advice for people using cross-thread COM: don’t install a WH_FOREGROUNDIDLE hook into your STA thread.