views:

51

answers:

1

I have a Winodws Mobile 6.1 application running on an ARMV4I processor. Given a stack address (from unwinding an exception), I like to determine what module owns that address.

Using the ToolHelpAPI, I'm able to determine most modules using the following method:

HANDLE snapshot = ::CreateToolhelp32Snapshot( TH32CS_SNAPMODULE | TH32CS_GETALLMODS, 0 );
if( INVALID_HANDLE_VALUE != snapshot ) 
{
    MODULEENTRY32 mod = { 0 };
    mod.dwSize = sizeof( mod );
    if( ::Module32First( snapshot, &mod ) ) 
    {
        do {
            if( stack_address > (DWORD)mod.modBaseAddr && 
                stack_address < (DWORD)( mod.modBaseAddr + mod.modBaseSize ) )
            {
                // Found the module!
                // offset = stack_address - mod.modBaseAddr
                break;
            }
        } while( ::Module32Next( snapshot, &mod ) );
    }
    ::CloseToolhelp32Snapshot( snapshot );
}

// if it's still not found

snapshot = ::CreateToolhelp32Snapshot( TH32CS_SNAPPROCESS | TH32CS_SNAPNOHEAPS, 0 );
if( INVALID_HANDLE_VALUE != snapshot )
{
    PROCESSENTRY32 proc = { 0 };
    proc.dwSize = sizeof( proc );
    if( ::Process32First( snapshot, &proc ) ) 
    {
        do 
        {
            if( stack_address > proc.th32MemoryBase &&
                stack_address < ( proc.th32MemoryBase + 0x2000000 ) )
            {
                // Found the executable
                // offset = stack_address - proc.th32MemoryBase
                break;
            }

        } while( ::Process32Next( snapshot, &proc ) );
    }
    ::CloseToolhelp32Snapshot( snapshot );
}

But, I don't always seem to be able to find a module that matches an address. For example:

stack address        module       offset
0x03f65bd8      coredll.dll + 0x0001bbd8
0x785cab1c        mylib.dll + 0x0002ab1c
0x785ca9e8        mylib.dll + 0x0002a9e8
0x785ca0a0        mylib.dll + 0x0002a0a0
0x785c8144        mylib.dll + 0x00028144
0x3001d95c           my.exe + 0x0001d95c
0x3001dd44           my.exe + 0x0001dd44
0x3001db90           my.exe + 0x0001db90
0x03f88030      coredll.dll + 0x0003e030
0x03f8e46c      coredll.dll + 0x0004446c
0x801087c4              ???      
0x801367b4              ???      
0x8010ce78              ???      
0x801086dc              ???      
0x03f8e588      coredll.dll + 0x00044588
0x785a56a4        mylib.dll + 0x000056a4
0x785bdd60        mylib.dll + 0x0001dd60
0x785bbd0c        mylib.dll + 0x0001bd0c
0x785bdb38        mylib.dll + 0x0001db38
0x3001db20           my.exe + 0x0001db20
0x3001dc40           my.exe + 0x0001dc40
0x3001a8a4           my.exe + 0x0001a8a4
0x3001a79c           my.exe + 0x0001a79c  
0x03f67348      coredll.dll + 0x0001d348

Where do I find those stack addresses that are missing? Any suggestions?

Thanks, PaulH

Edit: By taking @SoapBox's suggestion, I've filled in some of the gaps with "my.exe"

A: 

The CPU stack contains more than just addresses of code. Function arguments get passed on the stack as well. Only a debugger would know exactly what's in the stack frame, it gets it from the .pdb file. That won't really help you, a program cannot debug itself. On regular Windows, you'd use a minidump to do postmortem analysis, no idea if that's available on Mobile. It should be.

Hans Passant
Are you saying those 0x80000000 addresses don't refer to code? What sort of things could they refer to?
PaulH
@PaulH: Data, as I explained. Could be float arguments.
Hans Passant