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:

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

Comments (5)

  1. hrmm, sounds interresting.

  2. sriram says:

    finally u did it thats great.Patience and cool mmind is required thats it