4

The Visual Studio 2008 debugger is displaying relative addresses in the disassembly window as shown in the snippet below:

00000548 8B 4D B8           mov         ecx,dword ptr [ebp-48h]
0000054b 8B 01              mov         eax,dword ptr [ecx]
0000054d FF 50 28           call        dword ptr [eax+28h]
00000550 89 85 44 FF FF FF  mov         dword ptr [ebp+FFFFFF44h],eax
00000556 8B 8D 44 FF FF FF  mov         ecx,dword ptr [ebp+FFFFFF44h]
0000055c E8 2F 1D 2C 76     call        762C2290
00000561 90                 nop

Notice how the values of the addresses are too low to be real addresses. When I am at address 0x548 (first line) my EIP is 0x034D1A90. How do I configure the debugger/disassembly window to show the real address (for example, 0x034D1A90) instead of a relative address (for example, 0x0548)?

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Hex440bx
  • 657
  • 6
  • 16

1 Answers1

4

Yes, this is a bug in the debugger. The addresses it calculates are based on the address listed on the left. Which are fake, the actual machine code does not start at address 0. It doesn't have an option to show real addresses.

To find the real call target address, you have to set a breakpoint on the call instruction. When it hits, use Debug + Windows + Registers and copy/paste the value of the EIP register into your calculator. Then add the value of the call argument and subtract the value of address as shown on the left. That's the real address.

To view the machine code there, you next have to switch the debugger to non-managed mode. Debug + Windows + Call Stack and double-click one of the stack frames of an unmanaged method. At the bottom if you're not sure. Now you type "0x" in the Address box and copy/paste the address you calculated. Be sure to have the symbol server enabled.

Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536
  • thank you for the thorough explanation. I presume this is a known bug. Does MS have a fix/hotfix for it ? (I'm afraid the answer is likely to be "no", otherwise you would have probably mentioned the fix). – Hex440bx Apr 09 '11 at 21:02
  • It's been this way forever, I don't doubt this is a restriction in the debugger interface. It does make sense, considering the way the jitter places code. You could post to connect.microsoft.com, somebody probably already did so search first. Vote it up. – Hans Passant Apr 09 '11 at 21:06