Share via

MAPI and User Mode Stack Tracing

  • Article

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.

Comments

  • Anonymous
    March 16, 2009
    Continuing our look at lessons learned from James’ article on the MAPI memory leak , we look at the memory

  • Anonymous
    March 16, 2009
    Continuing our look at lessons learned from James’ article on the MAPI memory leak , we look at the memory

  • Anonymous
    March 17, 2009
    Digging more into lessons learned from James’ blog on analyzing memory usage (my first two articles are

  • Anonymous
    March 20, 2009
    I think this will be the last article to come from James’ post on debugging MAPI (previous posts here

  • Anonymous
    August 13, 2010
    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.

  • Anonymous
    August 16, 2010
    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.