2

the function addresses (Rva+Base) in my MAP-file from visual studio doesn't match the one I see in the debugger (or when I manually inspect my stack frame).

What could be causing this?

/A.B.

  • Please check if this is a duplicate of http://stackoverflow.com/questions/2485336/address-of-function-is-not-actual-code-address – rwong Dec 22 '11 at 21:58

4 Answers4

2

Is the problem in an executable or a DLL?

If it's a DLL what is its preferred load address? If this clashes with any other DLL then it will be rebased by the loader, and this can lead to what you're seeing.

As part of your build process, you should ensure that all your DLLs are rebased (there's a tool to do this) so that their address spaces don't clash (this frees up some page file space as well as improving load time).

Seb Rose
  • 3,628
  • 18
  • 29
1

Both exe and dll can be relocated, unless you specify a /FIXED command line option when linking. I use following way to determine the real address to determine where my exe was loaded, so that I can compute the offset against the map file.

static void KnownFunctionAddress(){}

...

// check an address of a known function
// and compare this to the value read from the map file

intptr_t CheckRelocationOffset(MapFile map)
{
  intptr_t mapAddress = map.PhysicalAddress("?KnownFunctionAddress@@YAXXZ");
  intptr_t realAddress = (intptr_t)KnownFunctionAddress;

  return realAddress-mapAddress;
}
Suma
  • 33,181
  • 16
  • 123
  • 191
0

When you are in the debugger and stepping into the code, can you check if the code address is within the range that you see in the "Modules" window? Sometimes the same piece of code may exist in several modules of same / different names.

Once you identify the "Module" which contains the code, use the base address from the Modules window to arrive at (by subtracting) the DLL entry point address.

Finally, there is also the effect of entry jump tables (trampoline), which is a kind of function call indirection that can be added at compile time or at runtime. Thus, the "entry point" address may be a smoke screen and doesn't match the address for the function body.

(My understanding of DLL structure is limited, so there may be inaccuracies in my answer.)

rwong
  • 6,062
  • 1
  • 23
  • 51
0

I'm not able to reply directly to Suma's reply for some reason, but you can also just do the following:

extern "C" struct IMAGE_DOS_HEADER __ImageBase; // On platforms other than Win32/Win64, this MAY be a different header type...
...
printf_s("base: %p", &__ImageBase);

__ImageBase is defined by the linker (VC++ at least) and taking its address will give you the base address of the module (EXE/DLL), even if it is relocated at runtime.

There's also

printf_s("calling module's base: %p\n", GetModuleHandle(NULL));

which can give you the same base address value...but there are more caveats to GetModuleHandle (plus it requires windows.h) so I recommend just sticking to __ImageBase.

Like others have mentioned, your problem is probably relating to Windows relocating your module. If there is no .reloc section in the module file, then the file isn't relocatable, in which case it is like you're running into trampolines or such like rwong suggested.

kornman00
  • 808
  • 10
  • 27