Question

Windbg fans claim that it is quite powerful and I tend to agree. But when it comes to debugging STL containers, I am always stuck. If the variable is on the stack, the !stl extension sometimes figures it out, but when a container with a complex type (e.g. std::vector<TemplateField, std::allocator<TemplateField> >) is on the heap or part of some other structure, I just don't know how to view its contents.

Appreciate any tips, pointers.

Was it helpful?

Solution

You might also want to give this debugger extension a try. It is a library called SDbgExt, developed by Skywing.

OTHER TIPS

I often find debugger support for STL data types inadequate. For this reason I'm increasingly using logging frameworks and logging statements. I used to think that these are for people who can't use a debugger, but I now realize that they offer real value. They allow you to embed portable debugging knowledge in your code and maintain it together with the code. In contrast, work you do in the debugger is typically ephemeral.

Python extension for WinDbg (pykd) have snippet stlp.py which can dump map contents.
Currently it supports STLPort map implementation. Tested on x86 and x64. This article demonstrates how to use it (its on Russian, but, examples are self-explanatory).

I had the exact same question some time ago. My answer is that Visual Studio is truly a better debugger for STL and complex types (just like Visual Studio is just a plain better debugger than MDbg).

This is not to say WinDBG is less powerful, just that it's lower level (e.g. try doing anything useful with crash dumps using Visual Studio -- you can't).

Anyway, to answer your question, you can use Visual Studio to look at the data types using some tricks:

  1. Start another instance of WinDBG, attach non-invasively: cdb -p <PID> -pv. This will suspend the threads of the debugee. Now you can safely detach the original WinDBG qd
  2. Attach Visual Studio to it, and then detach the non-invasive WinDBG qd. Look at the STL and continue as you wish.
  3. When you need to go back to WinDBG, goto step 1, swap with an invasive WinDBG.

I usually end up sticking a toString() method in a lot of my classes. This shows all the info that I deem important, any containers can then call this to display the class information in the console

Use dt -r i.e dt yourapp!class 7ffdf000 -r5

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top