Saving Private Bytes https://docs.microsoft.com/archive/blogs/ambrosew/feed.xml Bitbucket from Real World Encounters Wed, 17 Apr 2019 03:39:51 GMT en-US hourly 1 Debugging STL Containers with WinDbg Part 4: Pair https://docs.microsoft.com/archive/blogs/ambrosew/debugging-stl-containers-with-windbg-part-4-pair Fri, 18 Jan 2013 04:12:01 GMT https://blogs.msdn.microsoft.com/ambrosew/2013/01/18/debugging-stl-containers-with-windbg-part-4-pair/ For previous posts of this series, check out the following links:

Debugging STL Containers with WinDbg: Prolog
Debugging STL Containers with WinDbg: Prolog 2
Debugging STL Containers with WinDbg Part 1: Vector
Debugging STL Containers with WinDbg Part 2: List
Debugging STL Containers with WinDbg Part 3: Map

I should’ve blogged this post before part 3 as maps use pair to store each tree node’s value, but then I originally intended to fire and forget, so bare with me for now.

A pair is a template class that wraps a pair of values. Simply, pair::first stores the first value, and pair::second stores the second value.

Take the following example:

C:\Projects\STL>type pair.cpp
#include <iostream>
#include <string>

using namespace std;

int main() {
    pair<string, string> mypair("pair1", "pair2");
    cout << "mypair: " << mypair.first << " " << mypair.second << endl;
}
C:\Projects\STL>cl /EHsc /nologo /W4 /MTd /Zi pair.cpp
pair.cpp

C:\Projects\STL>pair
mypair: pair1 pair2

First you need to look at the type of the values. Do a dt on the pair variable and the debugger should tell you:

0:000> dt mypair
Local var @ 0x32fae0 Type std::pair<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::basic_string<char,std::char_traits<char>,std::allocator<char> > >
   +0x000 first            : std::basic_string<char,std::char_traits<char>,std::allocator<char> >
   +0x01c second           : std::basic_string<char,std::char_traits<char>,std::allocator<char> >

In this case since both of my pair values are strings, if you just do a dt -r on the pair variable, you can already see the values:

0:000> dt -r mypair
Local var @ 0xe7fe6c Type std::pair<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::basic_string<char,std::char_traits<char>,std::allocator<char> > >
   +0x000 first            : std::basic_string<char,std::char_traits<char>,std::allocator<char> >
      +0x000 _Myproxy         : 0x00ff2e68 std::_Container_proxy
         +0x000 _Mycont          : 0x00e7fe6c std::_Container_base12
         +0x004 _Myfirstiter     : (null) 
      +0x004 _Bx              : std::_String_val<std::_Simple_types<char> >::_Bxty
         +0x000 _Buf             : [16]  "pair1"
         +0x000 _Ptr             : 0x72696170  "--- memory read error at address 0x72696170 ---"
         +0x000 _Alias           : [16]  "pair1"
      +0x014 _Mysize          : 5
      +0x018 _Myres           : 0xf
      =00ce1d0c npos             : 0xffffffff
   +0x01c second           : std::basic_string<char,std::char_traits<char>,std::allocator<char> >
      +0x000 _Myproxy         : 0x00ff2a68 std::_Container_proxy
         +0x000 _Mycont          : 0x00e7fe88 std::_Container_base12
         +0x004 _Myfirstiter     : (null) 
      +0x004 _Bx              : std::_String_val<std::_Simple_types<char> >::_Bxty
         +0x000 _Buf             : [16]  "pair2"
         +0x000 _Ptr             : 0x72696170  "--- memory read error at address 0x72696170 ---"
         +0x000 _Alias           : [16]  "pair2"
      +0x014 _Mysize          : 5
      +0x018 _Myres           : 0xf
      =00ce1d0c npos             : 0xffffffff

You can expand each value individually as well:

0:000> dt -r mypair first..
Local var @ 0xe7fe6c Type std::pair<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::basic_string<char,std::char_traits<char>,std::allocator<char> > >
   +0x000 first   : 
      +0x000 _Myproxy : 
      +0x004 _Bx     : 
         +0x000 _Buf    : [16]  "pair1"
         +0x000 _Ptr    : 0x72696170  "--- memory read error at address 0x72696170 ---"
         +0x000 _Alias  : [16]  "pair1"
      +0x014 _Mysize : 5
      +0x018 _Myres  : 0xf
      =00ce1d0c npos    : 0xffffffff

0:000> dt -r mypair second..
Local var @ 0xe7fe6c Type std::pair<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::basic_string<char,std::char_traits<char>,std::allocator<char> > >
   +0x01c second   : 
      +0x000 _Myproxy : 
      +0x004 _Bx      : 
         +0x000 _Buf     : [16]  "pair2"
         +0x000 _Ptr     : 0x72696170  "--- memory read error at address 0x72696170 ---"
         +0x000 _Alias   : [16]  "pair2"
      +0x014 _Mysize  : 5
      +0x018 _Myres   : 0xf
      =00ce1d0c npos     : 0xffffffff

Or you can use the C++ expression evaluator to access _Buf directly:

0:000> ?? mypair.first._Bx
union std::_String_val<std::_Simple_types<char> >::_Bxty
   +0x000 _Buf             : [16]  "pair1"
   +0x000 _Ptr             : 0x72696170  "--- memory read error at address 0x72696170 ---"
   +0x000 _Alias           : [16]  "pair1"

0:000> ?? mypair.second._Bx
union std::_String_val<std::_Simple_types<char> >::_Bxty
   +0x000 _Buf             : [16]  "pair2"
   +0x000 _Ptr             : 0x72696170  "--- memory read error at address 0x72696170 ---"
   +0x000 _Alias           : [16]  "pair2"

Let’s look at a pair of containers with the following example:

C:\Projects\STL>type pair.cpp
#include <iostream>
#include <string>
#include <vector>
#include <list>

using namespace std;

int main() {
    vector<string> myvector;
    myvector.push_back("1");
    myvector.push_back("2");
    myvector.push_back("3");

    list<string> mylist;
    mylist.insert(mylist.end(), "one");
    mylist.insert(mylist.end(), "two");
    mylist.insert(mylist.end(), "three");

    pair<vector<string>, list<string>> mypair(myvector, mylist);
    cout << mypair.first[0] << " " << mypair.second.front() << endl;
}
C:\Projects\STL>cl /EHsc /nologo /W4 /MTd /Zi pair.cpp
pair.cpp

C:\Projects\STL>pair
1 one

Again, you need to look at the type of the values. Do a dt on the pair variable and the debugger should tell you:

0:000> dt mypair
Local var @ 0xf3f938 Type std::pair<std::vector<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char> > > >,std::list<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char> > > > >
   +0x000 first            : std::vector<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char> > > >
   +0x010 second           : std::list<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char> > > >

In this case my first value is of type std::vector<std::basic_string>, and my second value is of type std::list<std::basic_string>.

From here, I can move forward in two ways:

1. Use the C++ expression evaluator for both first and second:

0:000> ?? mypair.first
class std::vector<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char> > > >
   +0x000 _Myproxy         : 0x01586760 std::_Container_proxy
   +0x004 _Myfirst         : 0x01586aa8 std::basic_string<char,std::char_traits<char>,std::allocator<char> >
   +0x008 _Mylast          : 0x01586afc std::basic_string<char,std::char_traits<char>,std::allocator<char> >
   +0x00c _Myend           : 0x01586afc std::basic_string<char,std::char_traits<char>,std::allocator<char> >

0:000> ?? mypair.second
class std::list<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char> > > >
   +0x000 _Myproxy         : 0x01586c70 std::_Container_proxy
   +0x004 _Myhead          : 0x01586c10 std::_List_node<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,void *>
   +0x008 _Mysize          : 3

2. Use the offsets to get the addresses and use dt to display the type instances:

From the output of dt mypair above,  the pair is at 0xf3f938. The first value is at offset 0x000, and the second value is at offset 0x010. With this info, I can ask the debugger to display the specific types at the specific addresses

0:000> dt mypair
Local var @ 0xfbf730 Type std::pair<std::vector<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char> > > >,std::list<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char> > > > >
   +0x000 first            : std::vector<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char> > > >
   +0x010 second           : std::list<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char> > > >

0:000> dt 0xfbf730 std::vector<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char> > > >
pair!std::vector<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char> > > >
   +0x000 _Myproxy         : 0x01586760 std::_Container_proxy
   +0x004 _Myfirst         : 0x01586aa8 std::basic_string<char,std::char_traits<char>,std::allocator<char> >
   +0x008 _Mylast          : 0x01586afc std::basic_string<char,std::char_traits<char>,std::allocator<char> >
   +0x00c _Myend           : 0x01586afc std::basic_string<char,std::char_traits<char>,std::allocator<char> >

0:000> dt 0xfbf730+0x10 std::list<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char> > > >
pair!std::list<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char> > > >
   +0x000 _Myproxy         : 0x01586c70 std::_Container_proxy
   +0x004 _Myhead          : 0x01586c10 std::_List_node<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,void *>
   +0x008 _Mysize          : 3

From here I can conveniently reference part 1 and part 2 of this series to traverse the containers.

]]> Debugging STL Containers with WinDbg: Prolog 2 https://docs.microsoft.com/archive/blogs/ambrosew/debugging-stl-containers-with-windbg-prolog-2 Fri, 18 Jan 2013 01:13:00 GMT https://blogs.msdn.microsoft.com/ambrosew/2013/01/18/debugging-stl-containers-with-windbg-prolog-2/ In the original prolog of the Debugging STL Containers with WinDbg series, I started off with a simple main.cpp source, compiled it with the Visual Studio compiler, and debugged the executable with WinDbg.

A few folks mentioned that there ought to be some info that covers the steps from having an executable to seeing the debugger output. I had the assumption that if readers were interested in those blog posts they’d probably have some experiences with WinDbg. But I do agree that no matter how trivial some things might be, documenting the exact steps could be helpful one way or the other.

So here are my steps.

1. Prepare the Operating System, Compiler, and WinDbg:

a. Install Windows 8 Version 6.2 Build 9200.

b. Install Visual Studio Ultimate 2012 Version 11.0.50727.1 RTMREL.

c. Install Windows Software Development Kit (SDK) for Windows 8.

2. Open a Visual Studio command prompt.

In Windows 8, press Windows logo key Windows logo key+Q, and type "Developer Command Prompt for VS2012". Select the resulting app.

Here’s what my command prompt looks like where I create main.cpp:

C:\Program Files (x86)\Microsoft Visual Studio 11.0>cd\
C:\>md Projects
C:\>cd Projects
C:\Projects>md STL
C:\Projects>cd STL
C:\Projects\STL>notepad main.cpp
C:\Projects\STL>

3. Write some code in main.cpp. Here’s an example:

#include <iostream>
#include <string>
#include <vector>

using namespace std;

int main() {
    vector<string> ss;
    ss.push_back("1");
    ss.push_back("2");
    ss.push_back("3");
    for (int i = 0; i < (int)ss.size(); i++)
        cout << ss[i] << endl;
}

4. Save the file, and run the following command to compile it:

C:\Projects\STL>cl /EHsc /nologo /W4 /MTd /Zi main.cpp

5. Start WinDbg. In Windows 8, press Windows logo key Windows logo key+Q, and type "windbg". Select "WinDbg (X86)".

6. In WinDbg, press Ctrl+E (or go to File..Open Executable), type in C:\Projects\STL\main.exe for File name, and then click the Open button. If you receive a Workspace prompt, click Yes to save information for workspace.

7. Type in the following commands, one after another, in WinDbg:

!sym noisy
!symfix c:\symbols
.reload /f ntdll.dll
.reload /f kernel32.dll
bp main!main
g

At this point here’s what your WinDbg Command window might look like (I’ve highlighted the commands you need to type in):


Microsoft (R) Windows Debugger Version 6.2.9200.16384 X86
Copyright (c) Microsoft Corporation. All rights reserved.

CommandLine: C:\Projects\STL\main.exe
Symbol search path is: *** Invalid ***
****************************************************************************
* Symbol loading may be unreliable without a symbol search path.           *
* Use .symfix to have the debugger choose a symbol path.                   *
* After setting your symbol path, use .reload to refresh symbol locations. *
****************************************************************************
Executable search path is: 
ModLoad: 00a90000 00b81000   main.exe
ModLoad: 772e0000 77437000   ntdll.dll
ModLoad: 770f0000 77220000   C:\Windows\SysWOW64\KERNEL32.DLL
ModLoad: 76830000 768d6000   C:\Windows\SysWOW64\KERNELBASE.dll
(fac.d10): Break instruction exception - code 80000003 (first chance)
*** ERROR: Symbol file could not be found.  Defaulted to export symbols for ntdll.dll - 
eax=00000000 ebx=00000003 ecx=a0e10000 edx=00000000 esi=00000000 edi=00a900e8
eip=7738054d esp=0059f4e4 ebp=0059f510 iopl=0         nv up ei pl zr na pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000246
ntdll!LdrResolveDelayLoadsFromDll+0xa86:
7738054d cc              int     3
0:000> !sym noisy
noisy mode - symbol prompts on
0:000> !symfix c:\symbols
DBGHELP: Symbol Search Path: 
DBGHELP: Symbol Search Path: SRV*c:\symbols*http://msdl.microsoft.com/download/symbols
DBGHELP: Symbol Search Path: SRV*c:\symbols*http://msdl.microsoft.com/download/symbols
0:000> .reload /f ntdll.dll
DBGHELP: ntdll - public symbols  
        c:\symbols\wntdll.pdb\2806B41638B04D8989F13322DD34573A2\wntdll.pdb
0:000> .reload /f kernel32.dll
DBGHELP: KERNEL32 - public symbols  
        c:\symbols\wkernel32.pdb\CFACA818EC334A5EAD707CD86C847B4A1\wkernel32.pdb
0:000> bp main!main
SYMSRV:  c:\symbols\main.pdb\2AA57E80024F4D219D902A73C78FEA2D2\main.pdb not found
SYMSRV:  http://msdl.microsoft.com/download/symbols/main.pdb/2AA57E80024F4D219D902A73C78FEA2D2/main.pdb not found
*** WARNING: Unable to verify checksum for main.exe
DBGHELP: main - private symbols & lines 
        C:\Projects\STL\main.pdb
0:000> g
Breakpoint 0 hit
eax=00d42d98 ebx=7efeb000 ecx=00000001 edx=00d45700 esi=00000000 edi=00000000
eip=00a91820 esp=0059f958 ebp=0059f9a0 iopl=0         nv up ei pl zr na pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000246
main!main:
00a91820 55              push    ebp

Here’s a sample picture of it:

WinDbg

Here’s what happened:

!sym noisy - Activates noisy symbol loading so that when the debugger loads symbols you get more details like exactly where the symbol was loaded.

!symfix c:\symbols (or .symfix) - Sets the symbol path to point to Microsoft symbol store. I specified c:\symbols to store downloaded symbols there.

.reload /f ntdll.dll and .reload /f kernel32.dll - Since when this debug session starts I didn’t have proper symbol path set, symbols for these two modules were not loaded. After I set the symbol path with !symfix, I’m manually reloading the symbols for these two modules. This is not necessary in this specific case but in general it’s a good practice to have symbols for these two modules.

bp main!main - Sets a breakpoint at main().

g - Go (F5), just like what you’re accustomed to in Visual Studio.

8. At this point you can just press F10 or the Step Over button on the toolbar to step over the source code until you hit the for line. This is where the code added three elements into the vector.

9. Now in the debugger’s Command window you can type commands like dt ss to look at the vector:

0:000> dt ss
Local var @ 0x59f8dc Type std::vector<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char> > > >
   +0x000 _Myproxy         : 0x00b750f8 std::_Container_proxy
   +0x004 _Myfirst         : 0x0059f8ec std::basic_string<char,std::char_traits<char>,std::allocator<char> >
   +0x008 _Mylast          : 0x00ae3b1a std::basic_string<char,std::char_traits<char>,std::allocator<char> >
   +0x00c _Myend           : 0x00000008 std::basic_string<char,std::char_traits<char>,std::allocator<char> >

There you go. The steps that accompany the rest of the series.

You know what, actually I’m glad I wrote these down. I might need to reference these sometime later myself.

P.S. I was tempted to go back to the prolog and add a section with an "Update" label. Sounded logical, but I didn’t want to bloat that blog post into a book. Hence this post, Prolog 2. I’ve tagged this post with the same tags as the other posts in the series, so at least the tag cloud works as it’s supposed to. There are so many other questions that could spawn from this little post, like "why not use Visual Studio to create main.cpp", "why X86 and not X64", "why c:\symbols and not d:\symbols", or even "why Windows 8 and not Windows XP or Windows 7". I’ll re-evaluate the need to expand on these points at a later time :)

P.P.S. Just a gentle reminder, if you’re still using Windows XP. Its support ends on April 8, 2014!

]]> Debugging STL Containers with WinDbg Part 3: Map https://docs.microsoft.com/archive/blogs/ambrosew/debugging-stl-containers-with-windbg-part-3-map Tue, 15 Jan 2013 02:08:00 GMT https://blogs.msdn.microsoft.com/ambrosew/2013/01/15/debugging-stl-containers-with-windbg-part-3-map/ For previous posts of this series, check out the following links:

Debugging STL Containers with WinDbg: Prolog
Debugging STL Containers with WinDbg Part 1: Vector
Debugging STL Containers with WinDbg Part 2: List

Let’s now look at maps. Like lists, a map container manages a varying-length sequence of elements but as a (nearly) balanced ordered tree of nodes, each storing one element. An element consists of a key, for ordering sequence, and a mapped value. Underneath it’s an implementation of an ordered red-black tree (a special type of binary tree) of {key, mapped} values. The source in Visual Studio 2012 can be found in C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\crt\src\map.

Before we delve into a map in WinDbg, it’s probably a good idea to understand the basic structure of a red-black tree so to make sense out of the output when you debug.

A red-black tree is a special kind of binary tree. In a red-black tree, a node is either red or black. These two "colors" are essentially used for balancing the tree over time when you insert and remove nodes. For tree traversal in this case, the "color" of a node is irrelevant so feel free to set it aside for now.

Each tree node has the following members that are of interest for our purpose:

_Left - Points to left subtree, or smallest element if head.
_Parent – Points to the node’s parent, or root of the tree if head.
_Right - Points to right subtree, or largest element if head.
_Myval - the stored key/value pair.

Just like binary trees, each node can have a left subtree and a right subtree. Left and right branches so to speak.

Each node stores the key and value of a node. Keys are not limited to numerical. You can have a comparison function or less-than operator defined for the key type you desire. When you dereference an iterator, you get back a pair - first corresponds to the key, and second to the value.

I hope it’ll make sense when you look into an instance of a map and draw a logical picture of it.

Take the following example:

C:\Projects\STL>type main.cpp
#include <iostream>
#include <string>
#include <map>

using namespace std;

int main() {
    map<int, string> mymap;
    mymap[1] = "Map1";
    mymap[2] = "Map2";
    mymap[3] = "Map3";
    mymap[4] = "Map4";
    mymap[5] = "Map5";
    for (map<int,string>::iterator mi = mymap.begin(); mi != mymap.end(); ++mi)
        cout << (*mi).first << ": " << (*mi).second << endl;
}
C:\Projects\STL>cl /EHsc /nologo /W4 /MTd /Zi main.cpp
main.cpp

C:\Projects\STL>main
1: Map1
2: Map2
3: Map3
4: Map4
5: Map5

In this example we have 5 nodes so it’s simple enough to traverse, yet it has enough nodes to let us see a tree structure that’s easy to understand.

Let’s start by looking at the map instance:

0:000> dt mymap
Local var @ 0xd2fb70 Type std::map<int,std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::less<int>,std::allocator<std::pair<int const ,std::basic_string<char,std::char_traits<char>,std::allocator<char> > > > >
   +0x000 _Myproxy         : 0x00f56440 std::_Container_proxy
   +0x004 _Myhead          : 0x00f55428 std::_Tree_node<std::pair<int const ,std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,void *>
   +0x008 _Mysize          : 5

_Mysize is obvious, the number of nodes in the tree. _Myhead is a little trickier. _Myhead does not point to the root. _Myhead->_Parent does. Keep this in mind.

To start off the journey, let’s dump out the head node (it helps if you keep your eyes on the _Left/_Right/_Parent values):

0:000> dt 0x00f55428 std::_Tree_node<std::pair<int const ,std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,void *>
main!std::_Tree_node<std::pair<int const ,std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,void *>
   +0x000 _Left            : 0x00f56778 std::_Tree_node<std::pair<int const ,std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,void *>
   +0x004 _Parent          : 0x00f56830 std::_Tree_node<std::pair<int const ,std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,void *>
   +0x008 _Right           : 0x00f56a58 std::_Tree_node<std::pair<int const ,std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,void *>
   +0x00c _Color           : 1 ''
   +0x00d _Isnil           : 1 ''
   +0x010 _Myval           : std::pair<int const ,std::basic_string<char,std::char_traits<char>,std::allocator<char> > >

As stated earlier, head node’s _Left points to the smallest element, and its _Right points to the largest element. _Left and _Right at this point are not really necessary for us to start the traversal, so ignore them for now. After we traversed the tree you can come back and double-check the values.

Head node’s _Parent points to the root of the tree, so let’s start there. Notice that you can specify which member of the type to display, so here we specified _Left, _Parent, _Right, and _Myval. For _Myval we want to drill down to the pair’s first and second values, and also one more level deeper into _Bx as well to see the string buffer, hence we used _Myval… (with three dots).

0:000> dt 0x00f56830 std::_Tree_node<std::pair<int const ,std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,void *> _Left _Parent _Right _Myval...
main!std::_Tree_node<std::pair<int const ,std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,void *>
   +0x000 _Left     : 0x00f56778 std::_Tree_node<std::pair<int const ,std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,void *>
   +0x004 _Parent   : 0x00f55428 std::_Tree_node<std::pair<int const ,std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,void *>
   +0x008 _Right    : 0x00f569a0 std::_Tree_node<std::pair<int const ,std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,void *>
   +0x010 _Myval    : 
      +0x000 first     : 0n2
      +0x004 second    : 
         +0x000 _Myproxy  : 
         +0x004 _Bx       : 
            +0x000 _Buf      : [16]  "Map2"
            +0x000 _Ptr      : 0x3270614d  "--- memory read error at address 0x3270614d ---"
            +0x000 _Alias    : [16]  "Map2"
         +0x014 _Mysize   : 4
         +0x018 _Myres    : 0xf
         =003d7440 npos      : 0xffffffff

So the root node contains the <2,"Map2"> pair. From here you can dt _Left and _Right for each node. If you encounter a _Left or _Right value that is the same as the head node, that means there’s no more subtree there, and you’re done with that branch.

Here’s the complete output. I’ve added some debugger comments for you to follow.

0:000> dt 0x00f56830 std::_Tree_node<std::pair<int const ,std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,void *> _Left _Parent _Right _Myval...
main!std::_Tree_node<std::pair<int const ,std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,void *>
   +0x000 _Left     : 0x00f56778 std::_Tree_node<std::pair<int const ,std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,void *>
   +0x004 _Parent   : 0x00f55428 std::_Tree_node<std::pair<int const ,std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,void *>
   +0x008 _Right    : 0x00f569a0 std::_Tree_node<std::pair<int const ,std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,void *>
   +0x010 _Myval    : 
      +0x000 first     : 0n2
      +0x004 second    : 
         +0x000 _Myproxy  : 
         +0x004 _Bx       : 
            +0x000 _Buf      : [16]  "Map2"
            +0x000 _Ptr      : 0x3270614d  "--- memory read error at address 0x3270614d ---"
            +0x000 _Alias    : [16]  "Map2"
         +0x014 _Mysize   : 4
         +0x018 _Myres    : 0xf
         =003d7440 npos      : 0xffffffff

0:000> * _Parent points to _Myhead, which is expected.
0:000> * Both _Left and _Right point to somewhere other than _Myhead,
0:000> * so they both have branches.

0:000> * Dump the left subtree.

0:000> dt 0x00f56778 std::_Tree_node<std::pair<int const ,std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,void *> _Left, _Parent, _Right, _Myval...
main!std::_Tree_node<std::pair<int const ,std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,void *>
   +0x000 _Left     : 0x00f55428 std::_Tree_node<std::pair<int const ,std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,void *>
   +0x004 _Parent   : 0x00f56830 std::_Tree_node<std::pair<int const ,std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,void *>
   +0x008 _Right    : 0x00f55428 std::_Tree_node<std::pair<int const ,std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,void *>
   +0x010 _Myval    : 
      +0x000 first     : 0n1
      +0x004 second    : 
         +0x000 _Myproxy  : 
         +0x004 _Bx       : 
            +0x000 _Buf      : [16]  "Map1"
            +0x000 _Ptr      : 0x3170614d  "--- memory read error at address 0x3170614d ---"
            +0x000 _Alias    : [16]  "Map1"
         +0x014 _Mysize   : 4
         +0x018 _Myres    : 0xf
         =003d7440 npos      : 0xffffffff

0:000> * Here both _Left and _Right point to _Myhead, so we're done with this branch.

0:000> * Now dump the right subtree.

0:000> dt 0x00f569a0 std::_Tree_node<std::pair<int const ,std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,void *> _Left, _Parent, _Right, _Myval...
main!std::_Tree_node<std::pair<int const ,std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,void *>
   +0x000 _Left     : 0x00f568e8 std::_Tree_node<std::pair<int const ,std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,void *>
   +0x004 _Parent   : 0x00f56830 std::_Tree_node<std::pair<int const ,std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,void *>
   +0x008 _Right    : 0x00f56a58 std::_Tree_node<std::pair<int const ,std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,void *>
   +0x010 _Myval    : 
      +0x000 first     : 0n4
      +0x004 second    : 
         +0x000 _Myproxy  : 
         +0x004 _Bx       : 
            +0x000 _Buf      : [16]  "Map4"
            +0x000 _Ptr      : 0x3470614d  "--- memory read error at address 0x3470614d ---"
            +0x000 _Alias    : [16]  "Map4"
         +0x014 _Mysize   : 4
         +0x018 _Myres    : 0xf
         =003d7440 npos      : 0xffffffff

0:000> * Both _Left and _Right point to somewhere other than _Myhead,
0:000> * so they both have branches.

0:000> * Dump the left subtree.

0:000> dt 0x00f568e8 std::_Tree_node<std::pair<int const ,std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,void *> _Left, _Parent, _Right, _Myval...
main!std::_Tree_node<std::pair<int const ,std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,void *>
   +0x000 _Left     : 0x00f55428 std::_Tree_node<std::pair<int const ,std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,void *>
   +0x004 _Parent   : 0x00f569a0 std::_Tree_node<std::pair<int const ,std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,void *>
   +0x008 _Right    : 0x00f55428 std::_Tree_node<std::pair<int const ,std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,void *>
   +0x010 _Myval    : 
      +0x000 first     : 0n3
      +0x004 second    : 
         +0x000 _Myproxy  : 
         +0x004 _Bx       : 
            +0x000 _Buf      : [16]  "Map3"
            +0x000 _Ptr      : 0x3370614d  "--- memory read error at address 0x3370614d ---"
            +0x000 _Alias    : [16]  "Map3"
         +0x014 _Mysize   : 4
         +0x018 _Myres    : 0xf
         =003d7440 npos      : 0xffffffff

0:000> * Both _Left and _Right point to _Myhead, so we're done with this branch.

0:000> * Now dump the right subtree.

0:000> dt 0x00f56a58 std::_Tree_node<std::pair<int const ,std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,void *> _Left, _Parent, _Right, _Myval...
main!std::_Tree_node<std::pair<int const ,std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,void *>
   +0x000 _Left     : 0x00f55428 std::_Tree_node<std::pair<int const ,std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,void *>
   +0x004 _Parent   : 0x00f569a0 std::_Tree_node<std::pair<int const ,std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,void *>
   +0x008 _Right    : 0x00f55428 std::_Tree_node<std::pair<int const ,std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,void *>
   +0x010 _Myval    : 
      +0x000 first     : 0n5
      +0x004 second    : 
         +0x000 _Myproxy  : 
         +0x004 _Bx       : 
            +0x000 _Buf      : [16]  "Map5"
            +0x000 _Ptr      : 0x3570614d  "--- memory read error at address 0x3570614d ---"
            +0x000 _Alias    : [16]  "Map5"
         +0x014 _Mysize   : 4
         +0x018 _Myres    : 0xf
         =003d7440 npos      : 0xffffffff

0:000> * Again both _Left and _Right point to _Myhead, so we're done with this branch as well.
0:000> * All branches traversed. We're done.

The diagram below provides a logical picture of the tree:

Drawing1

Unlike vectors, I don’t have a script to dump the nodes for map containers. Maybe I’ll find some time later to address this shortcoming. Until then, I hope the information presented so far is helpful to you.

]]> Debugging STL Containers with WinDbg Part 2: List https://docs.microsoft.com/archive/blogs/ambrosew/debugging-stl-containers-with-windbg-part-2-list Mon, 14 Jan 2013 22:41:00 GMT https://blogs.msdn.microsoft.com/ambrosew/2013/01/14/debugging-stl-containers-with-windbg-part-2-list/ For previous posts of this series, check out the following links:

Debugging STL Containers with WinDbg: Prolog
Debugging STL Containers with WinDbg Part 1: Vector

Let’s now look at lists. A list container manages a varying-length sequence of elements as a bidirectional linked list of nodes, each storing one element. The source in Visual Studio 2012 can be found in C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\crt\src\list.

Take the following example:

C:\Projects\STL>type main.cpp
#include <iostream>
#include <string>
#include <list>

using namespace std;

int main() {
    list<string> mylist;
    mylist.insert(mylist.end(), "one");
    mylist.insert(mylist.end(), "two");
    mylist.insert(mylist.end(), "three");
    for (list<string>::iterator li = mylist.begin(); li != mylist.end(); ++li)
        cout << (*li) << endl;
}
C:\Projects\STL>cl /EHsc /nologo /W4 /MTd /Zi main.cpp
main.cpp

C:\Projects\STL>main
one
two
three

The first step is to get the pointer to the head node of the linked list. _Myhead gives you this information. _Mysize gives you the number of elements in the list.

0:000> dt mylist
Local var @ 0xebf7c8 Type std::list<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char> > > >
   +0x000 _Myproxy         : 0x010e6440 std::_Container_proxy
   +0x004 _Myhead          : 0x010e5428 std::_List_node<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,void *>
   +0x008 _Mysize          : 3

0:000> dt 0x010e5428 std::_List_node<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,void *>
main!std::_List_node<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,void *>
   +0x000 _Next            : 0x010e64d0 std::_List_node<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,void *>
   +0x004 _Prev            : 0x010e6868 std::_List_node<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,void *>
   +0x008 _Myval           : std::basic_string<char,std::char_traits<char>,std::allocator<char> >

Note that _Myhead points to the head node. _Myhead->_Next points to the first node, and _Myhead->_Prev points to the last node. The last node’s _Next simply points back to _Myhead.

To go through each node in the linked list, simply grab the first node and dt on _Next, and repeat for each node in the list, until _Next points to _Myhead:

0:000> dt 0x010e5428 std::_List_node<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,void *>
main!std::_List_node<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,void *>
   +0x000 _Next            : 0x010e64d0 std::_List_node<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,void *>
   +0x004 _Prev            : 0x010e6868 std::_List_node<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,void *>
   +0x008 _Myval           : std::basic_string<char,std::char_traits<char>,std::allocator<char> >

0:000> dt 0x010e64d0 std::_List_node<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,void *>
main!std::_List_node<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,void *>
   +0x000 _Next            : 0x010e67c0 std::_List_node<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,void *>
   +0x004 _Prev            : 0x010e5428 std::_List_node<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,void *>
   +0x008 _Myval           : std::basic_string<char,std::char_traits<char>,std::allocator<char> >

0:000> dt 0x010e67c0 std::_List_node<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,void *>
main!std::_List_node<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,void *>
   +0x000 _Next            : 0x010e6868 std::_List_node<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,void *>
   +0x004 _Prev            : 0x010e64d0 std::_List_node<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,void *>
   +0x008 _Myval           : std::basic_string<char,std::char_traits<char>,std::allocator<char> >

0:000> dt 0x010e6868 std::_List_node<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,void *>
main!std::_List_node<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,void *>
   +0x000 _Next            : 0x010e5428 std::_List_node<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,void *>
   +0x004 _Prev            : 0x010e67c0 std::_List_node<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,void *>
   +0x008 _Myval           : std::basic_string<char,std::char_traits<char>,std::allocator<char> >

To look at each node’s value (_Myval), simply tell dt to display the _Myval field. Note the two dots (..) which means "expand the field two levels deep". In this case, we want to see inside _Myval (first level), then we want to see inside _Bx (second level).

0:000> dt 0x010e64d0 std::_List_node<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,void *> _Myval..
main!std::_List_node<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,void *>
   +0x008 _Myval   : 
      +0x000 _Myproxy : 
      +0x004 _Bx      : 
         +0x000 _Buf     : [16]  "one"
         +0x000 _Ptr     : 0x00656e6f  "--- memory read error at address 0x00656e6f ---"
         +0x000 _Alias   : [16]  "one"
      +0x014 _Mysize  : 3
      +0x018 _Myres   : 0xf
      =00994878 npos     : 0xffffffff

The dt command does support -l option which can help you traverse the linked list using _Next, like so:

0:000> dt 0x010e64d0 std::_List_node<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,void *> -l _Next _Myval..
main!std::_List_node<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,void *>
_Next at 0x010e64d0
---------------------------------------------
   +0x008 _Myval   : 
      +0x000 _Myproxy : 
      +0x004 _Bx      : 
         +0x000 _Buf     : [16]  "one"
         +0x000 _Ptr     : 0x00656e6f  "--- memory read error at address 0x00656e6f ---"
         +0x000 _Alias   : [16]  "one"
      +0x014 _Mysize  : 3
      +0x018 _Myres   : 0xf
      =00994878 npos     : 0xffffffff

_Next at 0x010e67c0
---------------------------------------------
   +0x008 _Myval   : 
      +0x000 _Myproxy : 
      +0x004 _Bx      : 
         +0x000 _Buf     : [16]  "two"
         +0x000 _Ptr     : 0x006f7774  "--- memory read error at address 0x006f7774 ---"
         +0x000 _Alias   : [16]  "two"
      +0x014 _Mysize  : 3
      +0x018 _Myres   : 0xf
      =00994878 npos     : 0xffffffff

_Next at 0x010e6868
---------------------------------------------
   +0x008 _Myval   : 
      +0x000 _Myproxy : 
      +0x004 _Bx      : 
         +0x000 _Buf     : [16]  "three"
         +0x000 _Ptr     : 0x65726874  "--- memory read error at address 0x65726874 ---"
         +0x000 _Alias   : [16]  "three"
      +0x014 _Mysize  : 5
      +0x018 _Myres   : 0xf
      =00994878 npos     : 0xffffffff

_Next at 0x010e5428
---------------------------------------------
   +0x008 _Myval   : 
      +0x000 _Myproxy : 
      +0x004 _Bx      : 
         +0x000 _Buf     : [16]  "???"
         +0x000 _Ptr     : 0xcdcdcdcd  "--- memory read error at address 0xcdcdcdcd ---"
         +0x000 _Alias   : [16]  "???"
      +0x014 _Mysize  : 0xcdcdcdcd
      +0x018 _Myres   : 0xcdcdcdcd
      =00994878 npos     : 0xffffffff

Simple as mud. Remember to check out !list extension as well, which allows you to execute debugger commands repeatedly, once for every element in the linked list. For those lists with complex values, it might comes handy.

This is as much as I want to cover for now. Have a great day~!

P.S. Now that I’m at Part 2 in the series, I realized I used "Prolog" in the title of the beginning post instead of "Introduction” or "Preface" or something. Does it mean I need to have an Epilog? For blog posts I guess having an Epilog means there’s a hard end to the series. Or should I go back and change the title from Prolog to something else? I guess except my freshman year’s English teacher, nobody really cares :) Moving on..

P.P.S. That particular English teacher was the very first person I know who pronounced, in disgust, that ALL computer science student’s grammar sucks. There might be some truth to it, and I still try my best to write properly up till now, but I did picked assembly (Computer Science) over English (literature). Woot~!

]]> Debugging STL Containers with WinDbg Part 1: Vector https://docs.microsoft.com/archive/blogs/ambrosew/debugging-stl-containers-with-windbg-part-1-vector Mon, 14 Jan 2013 20:06:33 GMT https://blogs.msdn.microsoft.com/ambrosew/2013/01/14/debugging-stl-containers-with-windbg-part-1-vector/ In the prolog of this series, I dabbled a bit on some of the reasons why you’d want to walk the containers in WinDbg yourself instead of using extensions like !stl.

Just to put a stick on the ground for this series, I’m using Visual Studio Ultimate 2012 Version 11.0.50727.1 RTMREL on Windows 8 Version 6.2 Build 9200, and WinDbg 6.2.9200.16384 from Windows Software Development Kit (SDK) for Windows 8. Although I mentioned in the prolog that the containers’ types do change a little between Visual C++ releases, the concepts in this series should still apply.

First let’s look at vectors. A vector container manages a sequence of elements as a contiguous block of storage, essentially an array that grows on demand. The source in Visual Studio 2012 can be found in C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\crt\src\vector.

Take the following example:

C:\Projects\STL>type main.cpp
#include <iostream>
#include <string>
#include <vector>

using namespace std;

int main() {
    vector<string> ss;
    ss.push_back("1");
    ss.push_back("2");
    ss.push_back("3");
    for (int i = 0; i < (int)ss.size(); i++)
        cout << ss[i] << endl;
}
C:\Projects\STL>cl /EHsc /nologo /W4 /MTd /Zi main.cpp
main.cpp

C:\Projects\STL>main
1
2
3

The first step is to look at the size of each element, be it string or other types. In this case it’s a string vector:

0:000> dt ss
Local var @ 0xd4f938 Type std::vector<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char> > > >
   +0x000 _Myproxy         : 0x00e56418 std::_Container_proxy
   +0x004 _Myfirst         : 0x00e56858 std::basic_string<char,std::char_traits<char>,std::allocator<char> >
   +0x008 _Mylast          : 0x00e568ac std::basic_string<char,std::char_traits<char>,std::allocator<char> >
   +0x00c _Myend           : 0x00e568ac std::basic_string<char,std::char_traits<char>,std::allocator<char> >

_Myfirst - pointer to beginning of array.
_Mylast - pointer to current end of sequence.
_Myend - pointer to end of array.

To find out the size of each element, use dt again for the element type, with the -v option to get the size:

0:000> dt -v main!std::basic_string<char,std::char_traits<char>,std::allocator<char> >
class std::basic_string<char,std::char_traits<char>,std::allocator<char> >, 166 elements, 0x1c bytes
   +0x000 __BaseClass class std::_String_alloc<0,std::_String_base_types<char,std::allocator<char> > >, 15 elements, 0x1c bytes
   +0x000 __BaseClass class std::_String_val<std::_Simple_types<char> >, 24 elements, 0x1c bytes
   +0x000 __BaseClass struct std::_Container_base12, 9 elements, 0x4 bytes
...

There’s a whole lot of things that dt spews with -v. Alternatively you can always just use dt and calculate the size yourself:

0:000> dt main!std::basic_string<char,std::char_traits<char>,std::allocator<char> >
   +0x000 _Myproxy         : Ptr32 std::_Container_proxy
   +0x004 _Bx              : std::_String_val<std::_Simple_types<char> >::_Bxty
   +0x014 _Mysize          : Uint4B
   +0x018 _Myres           : Uint4B
   =003d31cc npos             : Uint4B

At offset 0x18, the last member is Uint4B in size. So the total size is 0x18+4, or 0x1c bytes. Easy enough.

Let’s look at the first element. The beginning of the array is at _Myfirst, so just copy the output for _Myfirst from dt ss earlier and do a dt –r on it:

0:000> dt ss
Local var @ 0xd4f938 Type std::vector<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char> > > >
   +0x000 _Myproxy         : 0x00e56418 std::_Container_proxy
   +0x004 _Myfirst         : 0x00e56858 std::basic_string<char,std::char_traits<char>,std::allocator<char> >
   +0x008 _Mylast          : 0x00e568ac std::basic_string<char,std::char_traits<char>,std::allocator<char> >
   +0x00c _Myend           : 0x00e568ac std::basic_string<char,std::char_traits<char>,std::allocator<char> >

0:000> dt -r 0x00e56858 std::basic_string<char,std::char_traits<char>,std::allocator<char> >
main!std::basic_string<char,std::char_traits<char>,std::allocator<char> >
   +0x000 _Myproxy         : 0x00e564a8 std::_Container_proxy
      +0x000 _Mycont          : 0x00e56858 std::_Container_base12
         +0x000 _Myproxy         : 0x00e564a8 std::_Container_proxy
      +0x004 _Myfirstiter     : (null) 
   +0x004 _Bx              : std::_String_val<std::_Simple_types<char> >::_Bxty
      +0x000 _Buf             : [16]  "1"
      +0x000 _Ptr             : 0xcdcd0031  "--- memory read error at address 0xcdcd0031 ---"
      +0x000 _Alias           : [16]  "1"
   +0x014 _Mysize          : 1
   +0x018 _Myres           : 0xf
   =003d31cc npos             : 0xffffffff

For strings, the most interesting member would be _Bx, which is a union type. From C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\crt\src\xstring:

union _Bxty
    {    // storage for small buffer or pointer to larger one
    value_type _Buf[_BUF_SIZE];
    pointer _Ptr;
    char _Alias[_BUF_SIZE];    // to permit aliasing
    } _Bx;

Your string data will either be in _Buf array for short string, or in the heap pointed to by _Ptr. _Mysize is the current length of the string, and _Myres is the current storage reserved for the string. _Alias is there since Visual Studio 2010 for aliasing.

Let’s go back to vectors.

To find the next element from the first, all we need to do is add the element size to the first element’s address. Here’s the second element in the vector:

0:000> dt -r 0x00e56858+0x1c std::basic_string<char,std::char_traits<char>,std::allocator<char> >
main!std::basic_string<char,std::char_traits<char>,std::allocator<char> >
   +0x000 _Myproxy         : 0x00e568e8 std::_Container_proxy
      +0x000 _Mycont          : 0x00e56874 std::_Container_base12
         +0x000 _Myproxy         : 0x00e568e8 std::_Container_proxy
      +0x004 _Myfirstiter     : (null) 
   +0x004 _Bx              : std::_String_val<std::_Simple_types<char> >::_Bxty
      +0x000 _Buf             : [16]  "2"
      +0x000 _Ptr             : 0xcdcd0032  "--- memory read error at address 0xcdcd0032 ---"
      +0x000 _Alias           : [16]  "2"
   +0x014 _Mysize          : 1
   +0x018 _Myres           : 0xf
   =003d31cc npos             : 0xffffffff

And the third:

0:000> dt -r 0x00e56858+0x1c+0x1c std::basic_string<char,std::char_traits<char>,std::allocator<char> >
main!std::basic_string<char,std::char_traits<char>,std::allocator<char> >
   +0x000 _Myproxy         : 0x00e56750 std::_Container_proxy
      +0x000 _Mycont          : 0x00e56890 std::_Container_base12
         +0x000 _Myproxy         : 0x00e56750 std::_Container_proxy
      +0x004 _Myfirstiter     : (null) 
   +0x004 _Bx              : std::_String_val<std::_Simple_types<char> >::_Bxty
      +0x000 _Buf             : [16]  "3"
      +0x000 _Ptr             : 0xcdcd0033  "--- memory read error at address 0xcdcd0033 ---"
      +0x000 _Alias           : [16]  "3"
   +0x014 _Mysize          : 1
   +0x018 _Myres           : 0xf
   =003d31cc npos             : 0xffffffff

And so on and so forth.

If you have a large number of elements to examine, you’d probably want the computer to do the enumeration for you. A debugger script will fit the bill. Here’s an example:

1. Store the following content in a text file named, say, vectorstring.txt, and put it in, say, c:\temp.

$$ Initialize our pseudo-registers
r? $t0=${$arg1}._Myfirst
r? $t1=${$arg1}._Mylast

$$ Go through the elements until _Mylast is reached.
.while (@$t0 != @$t1)
{
  $$ Dump the string content
  da @@c++(&@$t0->_Bx)

  $$ Go to the next element.
  r? $t0=@$t0+1
}

2. In the debugger, run the script with argument: $$>a< vectorstring.txt <vector>

0:000> $$>a< c:\temp\vectorstring.txt ss
00e5685c  "1"
00e56878  "2"
00e56894  "3"

This could be useful either to just look at the data of each element, or walk the vector array for suspicious values (e.g. buffer overruns). Customize the script to your heart’s content.

This is just about all I needed in order to peel the vector container. I hope this is a good start of the series for you. As always, happy debugging!

]]> Debugging STL Containers with WinDbg: Prolog https://docs.microsoft.com/archive/blogs/ambrosew/debugging-stl-containers-with-windbg-prolog Mon, 14 Jan 2013 02:44:00 GMT https://blogs.msdn.microsoft.com/ambrosew/2013/01/14/debugging-stl-containers-with-windbg-prolog/ For those who use Standard Template Library in applications and depend on WinDbg to troubleshoot, debugging STL containers has always been a little back-bending. There are various STL extensions available, but they sometimes just don’t play nice (fail, or generate an exception).

Take the following example:

C:\Projects\STL>type main.cpp
#include <iostream>
#include <string>
#include <vector>

using namespace std;

int main() {
    vector<string> ss;
    ss.push_back("1");
    ss.push_back("2");
    ss.push_back("3");
    for (int i = 0; i < (int)ss.size(); i++)
        cout << ss[i] << endl;
}
C:\Projects\STL>cl /EHsc /nologo /W4 /MTd /Zi main.cpp
main.cpp

C:\Projects\STL>main
1
2
3

Let’s say you’re using WinDbg 6.12.0002.633 from Microsoft Windows SDK for Windows 7 and .NET Framework 4. If you set a breakpoint at the cout line (when the vector has data) and examine the vector with !stl, you’ll get output similar to below if you use Visual C++ 2010 or 2012 to compile. Try a newer debugger package? WinDbg 6.2.9200.16384 from Windows Software Development Kit (SDK) for Windows 8 produces the same result.

0:000> !stl ss
TryToDumpAsVector(): Failed to g_ExtSymbols->GetFieldOffset( ModuleCollection, TypeIdCollection, FirstName, &ElementOffset ) 0x80070057 [line 983]
    Unrecognized type 'std::vector<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char> > > >' as an STL structure -- Defaulting to `dt -n (std::vector<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char> > > >) 0x22fa78`
main!std::vector<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char> > > >
   +0x000 _Myproxy         : 0x00361460 std::_Container_proxy
   +0x004 _Myfirst         : 0x003614f0 std::basic_string<char,std::char_traits<char>,std::allocator<char> >
   +0x008 _Mylast          : 0x00361550 std::basic_string<char,std::char_traits<char>,std::allocator<char> >
   +0x00c _Myend           : 0x00361550 std::basic_string<char,std::char_traits<char>,std::allocator<char> >
   +0x010 _Alval           : std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char> > >

However, try the debuggers on Visual C++ 2008 compiled binary and you’ll get output similar to below, which is a whole lot nicer:

0:000> !stl ss
    Element 0
[da 0x823798]
00823798  "1"
    Element 1
[da 0x8237b8]
008237b8  "2"
    Element 2
[da 0x8237d8]
008237d8  "3"

As you can see, the !stl (and !std_map, etc.) extension is tightly coupled with the STL version that the extension was designed to support (offsets anyone?). By looking at the type information from various Visual C++ versions, you can see that the underlying STL implementation changes ever so slightly over time:

Visual C++ 2008:

0:000> dt ss
Local var @ 0x18ff14 Type std::vector<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char> > > >
   +0x000 _Myfirstiter     : (null) 
   +0x004 _Alval           : std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char> > >
   +0x008 _Myfirst         : 0x00823790 std::basic_string<char,std::char_traits<char>,std::allocator<char> >
   +0x00c _Mylast          : 0x008237f0 std::basic_string<char,std::char_traits<char>,std::allocator<char> >
   +0x010 _Myend           : 0x008237f0 std::basic_string<char,std::char_traits<char>,std::allocator<char> >

Visual C++ 2010:

0:000> dt ss
Local var @ 0x22fa78 Type std::vector<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char> > > >
   +0x000 _Myproxy         : 0x00361460 std::_Container_proxy
   +0x004 _Myfirst         : 0x003614f0 std::basic_string<char,std::char_traits<char>,std::allocator<char> >
   +0x008 _Mylast          : 0x00361550 std::basic_string<char,std::char_traits<char>,std::allocator<char> >
   +0x00c _Myend           : 0x00361550 std::basic_string<char,std::char_traits<char>,std::allocator<char> >
   +0x010 _Alval           : std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char> > >

Visual C++ 2012:

0:000> dt ss
Local var @ 0xd4f938 Type std::vector<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char> > > >
   +0x000 _Myproxy         : 0x00e56418 std::_Container_proxy
   +0x004 _Myfirst         : 0x00e56858 std::basic_string<char,std::char_traits<char>,std::allocator<char> >
   +0x008 _Mylast          : 0x00e568ac std::basic_string<char,std::char_traits<char>,std::allocator<char> >
   +0x00c _Myend           : 0x00e568ac std::basic_string<char,std::char_traits<char>,std::allocator<char> >

There’s little wonder why the extension sometimes work and sometimes doesn’t. But instead of hunting down the right extension to dump the STL containers, how about understanding the underlying structures so that you can look at the data in WinDbg without an extension? These extensions, after all, look at the same piece of memory. For memory corruption cases, these extensions would probably barf anyway.

In the coming multi-part posts, I’ll show you the steps to examine these containers yourself: vector, list, and map. Before that, I hope this post provides you with a little context on why anyone would want to do it by hand instead of using !stl.

For those who’s interested, stay tuned~!!

P.S. If you’ve read this far you’ve probably pulled your hair out more than once trying to debug STL containers with WinDbg. I’d reckon you’ve tried other extensions like SDbgExt but those too may have suffered similar fate. Little known to a few people I encountered, Visual Studio has had the capability to open dump files since way before my hair started falling off.

Granted the things you could do after opening a dump file with older versions are, well, not that much, newer versions do provide incremental yet significant improvements. In terms of looking at values in STL containers, if that’s all you need, maybe you can just open the dump file with Visual Studio and get comfy there:

VS2008STL

P.P.S. Over the years I occasionally ran into people who had to go through the same ordeal. Unfortunately I never seemed to pick myself up to write about it properly after I’ve helped them out. Not sure what happened but I guess today is always a good day to start doing the right thing. At least now I bitbucket it here so that I don’t need to re-remember these things when someone asks “how do I dump an STL map in WinDbg" next time.

]]>