Set Next Statement is your friend

Yesterday I identified a symbol loading issue with the current internal drop of the VS debugger.  Within minutes, I had Steve Steiner from the debugger team here in my office, stepping through the code with me.  It was a tricky situation because we were using the Visual Studio debugger to debug another instance of the VS debugger operating against yet another instance of VS.  It was a trip trying to remember the context across three separate IDE instances.

Although I consider myself pretty proficient with debuggers, I always enjoy watching other hard core debugging folks do their magic because every once in awhile I learn something new, or some prior lesson gets reinforced.   Yesterday's experience yielded two nuggets:

  • Set Next Statement is very handy
  • Using the “,hr” syntax in expressions

I've used the debugger's Set Next Statement for years ago, but watching an actual debugger developer use it much like I do was very cool.

Set Next Statement has a variety of uses.  My favorite is when I've stepped over a function that I expected to work correctly, yet it failed instead.   If the function hasn't mucked with any of its input parameters, or caused side effects, it's usually safe to just set the next statement back to the desired statement and step into it.

Another cool use for Set Next Statement is when a block of code causes the function to exit with an error or crash. If it isn't absolutely essential to execute that code, set a breakpoint at the beginning of the code, and after it's hit, use Set Next Statement to set control to a point after the bad code.   I used this functionality yesterday when a code parser refused to work properly in the context I was in.  The underlying problem is already slated to be fixed, but in the meanwhile, I needed to get past that point to focus on the code I'm working on.

As for the “,hr” syntax, it's great when you're working with HRESULTS in COM.  For the longest time I used the IDE's error lookup feature to convert HRESULT values into readable strings.  Now I know that you can just tack “,hr” on to the end of an expression (for instance:  “myHresultValue,hr”), and the IDE does its best to look up the HRESULT string for you.

Comments (8)

  1. BlackEnd says:

    Hardcode guy like you don’t know ,hr!!??

    You might also want to take a look at @err which is equal to GetLastError()

  2. mikeb says:

    Now, Matt, I think you’re being a bit too modest here:

    "Although I consider myself pretty proficient with debuggers…"

  3. Kim Gräsman says:

    A non-obvious life-saver is that ,hr works for most Windows error codes as well, such as the result of GetLastError().

    So, @err,hr shows the last error code _with a nice, friendly description_.

  4. Seth McCarus says:

    Entering eax and @err,hr in my watch window easily lets me see the result of a given function, plus its error code if it fails. Not that I don’t *always* check return values, but…

  5. John Maver says:

    That card in the back of John Robbins’ book(1st edition) has a slew of great hr like tips.

  6. What does it mean to make code more maintainable? Certainly obfuscated code is hard to understand, by

Skip to main content