views:

307

answers:

2

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?

A: 

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.

Paul Betts
Do you think that the .NET interpreter could be changing things?
devviedev
No, the CLR will not change any unmanaged DLL
Paul Betts
If I do "u <address>", 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
If you're not using symbols, WinDbg is going to give you trash information. Find the symbols for the DLL you need
Paul Betts
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
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?
Paul Betts
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
A: 

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