MAPI and User Mode Stack Tracing

Stephen Griffin - MSFT

13 Mar 2009 10:17 AM

Comments 6

James wrote up a good article on analyzing a MAPI memory leak using user mode stack tracing. I wanted to highlight some points he made. Let’s look at some !heap output from one of my recent cases (using only public symbols here):

0:000> !heap -p -a 03fbec28    
    address 03fbec28 found in
    _HEAP @ 3f90000
      HEAP_ENTRY Size Prev Flags    UserPtr UserSize - state
        03fbec20 0021 0000  [07]   03fbec28    000f0 - (busy)
          ? EMSMDB32!MSProviderInit+1d27a
        Trace: 1922
        7c8531e4 ntdll!RtlAllocateHeapSlowly+0x00000041
        7c83d97a ntdll!RtlAllocateHeap+0x00000e9f
        35b732f4 EMSMDB32!MSProviderInit+0x0000186a

The line starting with the ? is the output of dps (Display Words and Symbols) against the start of the allocation. Basically, it’s saying “suppose this was a pointer – what does it point to?”. The reason it does this is in case this allocation happens to be an object. Objects are usually laid out in memory with pointers to the object’s virtual tables (vtable) at the beginning. Even without symbols, we can see that this in this case, it *could* be an object. Let’s take a closer look:

0:000> dps 03fbec28 l3
03fbec28  35b8ed04 EMSMDB32!MSProviderInit+0x1d27a
03fbec2c  35b728b8 EMSMDB32!MSProviderInit+0xe2e
03fbec30  00000001
0:000> dps 35b8ed04 l3
35b8ed04  35b90861 EMSMDB32!MSProviderInit+0x1edd7
35b8ed08  e958026a
35b8ed0c  ffff4140
0:000> dps 35b728b8 l3
35b728b8  35b90839 EMSMDB32!MSProviderInit+0x1edaf
35b728bc  35b7d7eb EMSMDB32!MSProviderInit+0xbd61
35b728c0  35b7d91f EMSMDB32!MSProviderInit+0xbe95

First, we run dps against the allocation, and see two possible vtables. If they are indeed vtables, dps against what they point to should also be code within emsmdb32. And we see that it is – the first points to a vtable with a single function, and the second points to a vtable with several functions. We can carry this further by unassembling the possible functions (such as 35b90861 or 35b90839) to see that the output does resemble a function header. Assuming we’re debugging our own process, we can look further down the stack from the !heap command and see that this memory was allocated in response to an OpenEntry call for a message, and conclude this is a message object.

Next time: we’ll take a look at flags and recognizing MAPI properties in memory.

MAPI, DevMsgTeam, Debugging

Comments

SGriffin's MAPI Internals

16 Mar 2009 11:26 AM

Continuing our look at lessons learned from James’ article on the MAPI memory leak , we look at the memory
SGriffin's MAPI Internals

16 Mar 2009 11:26 AM

Continuing our look at lessons learned from James’ article on the MAPI memory leak , we look at the memory
SGriffin's MAPI Internals

17 Mar 2009 10:07 AM

Digging more into lessons learned from James’ blog on analyzing memory usage (my first two articles are
SGriffin's MAPI Internals

20 Mar 2009 11:26 AM

I think this will be the last article to come from James’ post on debugging MAPI (previous posts here
Lev

13 Aug 2010 10:15 AM

windbg & dv command ( sorry about hijacking this thread ).

I'm looking at a trivial crash. if ( testCondition == 0 ) { dereference NULL; }, where testCondition is an int.

I use dv command of WinDbg to see what the testCondition is and it gives me some meaningless number.

I know for a fact ( and see in the debugger ) that testCondition is 0; otherwise it would not have executed the crashing code.

What gives? Is this not a proper use of the dv command?

Thanks.
Stephen Griffin - MSFT

16 Aug 2010 8:00 AM

Lev - it's a well known fact that the debugger lies. :) When you run a command like dv, the debugger is making it's best guess as to where in memory/registers to look for the local variables. The trouble is - compiler optimizations can make this guess difficult or impossible. Some local variables may only actually exist for a short time, with their memory being shared with other variables after they're no longer needed. So, when the debugger guesses wrong, it may as well be showing you random data. Hence - we say it lies.

Your best bet here is to disassemble your function and find the assembly where you actually do the test. Put your breakpoint there and read the value directly from the memory/register which is being tested. Then, assuming you read the assembly right, you know you're looking at the right data.