Debugging complex data structures with Visual Studio

Right now I'm struggling with an extremely annoying bug that has cost me more than a week of work and numerous headaches. When dealing with problems like this one it is good to at least have a good IDE. As for debugging, Visual Studio does pretty good job, although it has its weaknesses, too. Of course it does.

I blame it all to the C++ language. It seems that C++ is just too complex for any tools. While compilers rarely got confused by creepy features of C++ like macros, nested templates, name spaces, polymorphism or multiple inheritance, auxiliary tools are often completely lost when they encounter certain geeky constructs on their way.

The bug I'm fighting now has something to do with reference counting in the video driver object of the Irrlicht engine. I wanted to add the driver's reference counter to the Watch window in Visual Studio. Then I'd append an ampersand to the counter to obtain its physical address, so I can create a data breakpoint (a common and extremely useful technique that allows to see when a value is modified by someone). Unfortunately I wasn't able to add the watch. For the debugger, it was a mission impossible to understand what I had on mind writing:

device->VideoDriver

CXX0017: Error: symbol "device" not found. I hate this message. My idea was too simple, I guess. For a human, it is fairly clear what we are referring to here, but not for the debugger. The variable was in different process (Irrlicht.dll) than the debugger was looking at (Fame.exe). In this case it would be enough to step into the DLL in the Call Stack window and there proceed with adding the watch. However, sometimes the problem is deeper (for instance, when we DON'T want to go anywhere in the call stack). The solution?

• Add a local variable (here: device) to the Watch window
• Expand it and find the member you're interested in (here: VideoDriver->ReferenceCounter)
• Use Drag&Drop on the member to create a stand-alone watch!

It might be quite shocking what you usually receive using the above technique. I needed to create a screen shot, because SourceForge denies to parse such stuff:

Looks like a monkey has been randomly pressing buttons on my keyboard, doesn't it? Well, it works. The debugger now thinks "Wow, at last some readable input!" and produces a nice watch entry for the reference counter!

Now several more hours spent on investigating those damn counters and the bug gets finally fixed. Or not.