0

I'm using WinDbg (Native x64 -- NOT Itanium) to debug an x64 (unmanaged) application that loads both managed an unmanaged DLLs.

I'm trying to set a breakpoint in one of the unmanaged DLLs. When the breakpoint is hit and I step through, the instructions displayed are totally different from what they should be. I verified with two different disassemblers that WinDbg is not displaying the correct disassembly as I step through.

When attaching to the application, I get a line like this:

ModLoad: 00000000`XXXXXXXX 00000000`YYYYYYYY  C:\MyDLL.DLL

I adjusted the addresses in the two disassemblers to reflect the base address XXXXXXXX.

What could be the problem?

devviedev
  • 181
  • 6
  • I found this (which never was completely answered): http://stackoverflow.com/questions/1398826/vs2008-on-win7-64-bit-debugging-a-windows-service Maybe this helps? – devviedev Dec 22 '09 at 00:09
  • does the disassembly make sense generally? i'd give the general preference to windbg since it is decoding using a valid ip in a live process which has benefits as opposed to solely relying on static analysis (however good a disassembler might be). can you reveal a bit of assembly code to compare? – deemok Dec 22 '09 at 14:23
  • It's "call someFunc" vs "mov ebx,esp". Even stepping at other points it doesn't match. It seems inconsistent in which breakpoints are hit; I set breakpoints that should be hit but aren't. – devviedev Dec 22 '09 at 18:08

2 Answers2

0

Does uf modname!FuncName return the correct results? You can sometimes trick WinDbg if you unassemble / breakpoint at weird places. Remember, that x86/x64 is a variable-width instruction set, so if you start reading halfway through an instruction, the disassembler gets confused.

Ana Betts
  • 73,868
  • 16
  • 141
  • 209
  • Do you think that the .NET interpreter could be changing things? – devviedev Dec 21 '09 at 21:56
  • If I do "u
    ", it doesn't match. I'm not debugging with symbols. I also tried moving the address a little, doesn't help to get the right disassembly.
     – devviedev Dec 21 '09 at 22:59
  • If you're not using symbols, WinDbg is going to give you trash information. Find the symbols for the DLL you need – Ana Betts Dec 22 '09 at 03:29
  • I don't believe that. I've used WinDbg and it's given me a good disassembly (that matched the static disassembly perfectly). I've only started to have a problem when I moved from all-native x86 to mixed-mode x64. – devviedev Dec 22 '09 at 17:15
  • Hmmm, let me rephrase - WinDbg will be untrustworthy when you don't have symbols, but not always incorrect. Anyways, what happens if you compare the raw bytes vs. what WinDbg reports via db @rip? – Ana Betts Dec 23 '09 at 03:26
  • Raw bytes say that the static disassembly is correct and WinDbg is wrong, so that's why I'm worried about things changing during runtime. – devviedev Jan 14 '10 at 02:17
0

Somewhere i've noticed info that this may be related to improper entry point in your DLL. But I have no clue what to do with this information (i'm beginner).

PiotrW
  • 1