Lessons Learned from Debugging Excel

Use your IDE's debugger.
Use your IDE's debugger.

I spent the past few weeks debugging Microsoft Excel. This was my first time intensely debugging through such a massive codebase, and I learned a few tricks along the way. These tips will largely be common sense for seasoned developers, but may be useful for someone who’s seriously debugging for the first time.


Use the Immediate Window

The Immediate window allows you to call functions, while your program is frozen at a breakpoint. This is useful when you call debugging functions that print out data for critical variables, as opposed to manually inspecting those variables themselves.

This is especially true when you’re working in a heavily object-oriented codebase, and you’ll need to sift through multiple objects in order to inspect important variables. Just have a function do that for you.


Skip Lines of Code

In the Visual Studio Debugger, you can drag the next statement cursor to another line of code. This is obviously useful for forcing the program through a specific code path – entering one if statement rather than another.

But this is also useful for tracing down the exact source of a bug. By setting the next statement cursor, you can skip lines of code. If skipping a line of code stops a being from repro-ing, that line of code (and the functions called on that line) may be worth investigating.

It absolutely isn’t always the case, but it could give good insight into how a function changes the program state. Skipping lines of code also happens to be a good way of seeing how well your program handles errors.


Inspect Memory

This is a critical tool for tracking down potential data corruption. Using the memory window, you can inspect values stored at memory addresses, and view them in binary, hex, and ASCII format. Memory inspection won’t be useful for every situation, but when you need to see your data at a low level, it will be your best friend.


Label your Breakpoints

Visual Studio lets you label your breakpoints – this is incredibly useful when you’re investigating multiple potential sources for a bug. Labelling your breakpoints lets you separate your breakpoints into groups. For example, Shipment Processing makes more sense than ShipmentController.cpp Line 64