Say Goodnight

I currently work for Avid Technology as a software engineer in group dedicated to fixing customer issues. We do quite a bit of debugging, both on the Mac and the PC. I thought having a place where I could share some of the learned lessons would be interesting. I’ll share what I can, including code, techniques and thoughts. We’ll see what happens…

First off, thanks to the books Advanced Windows Debugging, and the amazing Memory Dump Anthology, vol 1 & 2, I have grown more comfortable with Windbg. I cannot stress enough the importance of using memory dumps in debugging of large applications.

However, after learning about the true power of Windbg I immediately wanted to write my own extension that would help me pull useful information out of memory dumps. I searched the web for examples, and there are many. It gets confusing due to the different methods of creating an extension. The “old style”, using COM, etc etc. Not to mention that everyone writing windbg extensions seems to love makefiles. Is there no one who both likes windbg AND sees the benefit of using VisualStudio’s IDE? Maybe that is a small category, but it did include me!

So I used the ’simple’ example that ships with the ‘Debugging Tools For Windows’ to create a windbg extension that has a solution file for VisualStudio 2008. I removed all the specific code, all that is left is the skeleton, but it should be obvious how to add the code for your extension.

Download it here: Sample Windbg Extension

It is an “old style” windbg extension, but I was able to do everything I need to do, and to me it is a lot more simple than bringing COM and whatnot into the picture. ReadMemory() works similar to scanf. What is cool is that you can use ReadMemory to read complex structures. So if you are writing a windbg extension for a codebase that you have access too (which I am), you can grab header files for some of the more complex data structures and put them right in your extension code. When you call ReadMemory() it will populate the data structure just as it is in your ‘real’ application! This allows you do reuse much of the parsing code. For example, in Avid’s applications there are things called “MOBs”, which are referenced by “Mob IDs”. Its not super complex, but it is a data structure with ‘major’ parts and ‘minor’ parts, and who knows what the heck else. So I just took the definitions of those structures, put it in my extension and when I do a ReadMemory(), I can use the same code our application uses to print out a MobID, without having to understand the gory details! Sweeeeeeeeeet.

Also, after you write a bit of code with ReadMemory(), you’ll find yourself needing to include offsets to fields in your classes to get specific pieces of information. You can hardcode this information, but then if your program changes the offsets might be wrong. I had written a few extensions before I found the GetFieldOffset() call. This does exactly what you’d want it to. Given a module name and structure, plus a field name, it will return the offset from the beginning. So you find the address of your structure, then add this offset, passing that to ReadMemory() and whammo…..tons of useful data.