4

I have a minidump of a crash. At the point of the crash, there is some weird looking code that shouldn't ever run successfully. Something like:

call        AnObject::AFunction 
test        byte ptr [eax],cl

AnObject::AFunction is a member function that returns bool. So the result should be stored in eax as either 0 or 1. It does not make sense to dereference eax at this point.

I disassembled the corresponding binary and indeed, the code is different in this function:

call        AnObject::AFunction 
test        al, al

Why on earth would the minidump disassembly code be different from the actual binary disassembly code?

Jimson
  • 41
  • 1
  • There is a real chance of stack corruption which can lead into this issue. – kumar_m_kiran Nov 21 '12 at 10:45
  • Wouldn't stack corruption only affect the stack frame and variables? Stack corruption shouldn't affect the read-only code. – Jimson Nov 21 '12 at 17:24
  • Your code changed from `84 C0` to `84 08` - is it possible something overwrote your code while the program was running? Debuggers and other programs can do that. – DCoder Nov 24 '12 at 07:46
  • Debuggers generally change the first byte of an instruction to 0xCC (INT 3 - Debugger Trap). –  Feb 05 '13 at 15:59

0 Answers0