If you don’t blow up a debug session every so often, you’re not debugging hard enough

I was helping a customer live-debug an assertion failure in an automated test running in a lab. I messed up an attempt to unwind the stack to restart a call and ended up corrupting the process state. Undaunted, I realized that the issue at hand was that one specific API call was failing, so I said to myself, "That's okay if I can't restart the call. I can just simulate the call!" so I patched registers and manually pushed data onto the stack and all that stuff.

And then I stepped through the code, and it crashed because I messed up one detail: When virtually pushing the return address on the stack, I had a mental lapse and subtracted 4 from the stack pointer even though this was a 64-bit machine and I should have subtracted 8. Due to the stack misalignment, the code eventually crashed on a movaps instruction several stack frames deep into the function.

I blew up the debug session not once but twice.

If this happens to you, don't beat yourself up. If you don't blow up a debug session every so often, then you're not debugging hard enough.

(That punch line is a ripoff of something I heard the Car Talk guys say: "If you don't stall a manual transmission every so often, then you're not driving it right.")

Comments (9)
  1. alegr1 says:

    My saying:
    “If you don’t crash Windbg, you’re not debugging hard”

    The darn thing crashes once in a while on the target reboot. I suspect because of use of .kdfiles.

  2. J. Peterson says:

    I’m glad I don’t work in a place where manually patching stack frames in the debugger is routine procedure. It’s nice to know there are people who can do it, though.

  3. Ivan K says:

    A friend let me use his brand new car (over $40K) a couple times while I was still learning how to drive a manual a decade or so ago. When I asked him if he was sure about letting me drive, he replied “There’s no point in having teeth if you can’t grind them once in a while”.

  4. not an anon says:

    At least you didn’t blow up the debug session before it even got off the ground! Did that to the Tandem debugger back when I was an intern — turns out, drive-relative Windows paths in NonStop debug symbols blow up INSPECT’s ThirdEye symbol processing library because it thinks they’re Tandem paths that can only be oh, 31 chars long. Whoops!

  5. So true. The fact that you blew it twice may indicate you’re working at the limit of your abilities. It might be more effective to carefully script the call simulation (and through each failure debug the script), rather than trying again and again to manually perform this delicate and dangerous dance.

  6. Joshua A. Schaeffer says:

    XDesProc.exe is the bane of my debugging existance.

  7. McBucket says:

    +1 for the Car Talk reference. One of the most fun hours on the radio, even if it’s in reruns now, and despite the fact that I’m not a car person. Why there isn’t an analogue show for computers is a mystery, and a shame.

    1. JAHA says:

      There used to be the Computer Guys on Kojo Namdi tech tuesdays…not sure if they still do it.

  8. Raymond the best fix for those types of bugs is inc rsp :P

Comments are closed.

Skip to main content