Im writing a little tracer which should handle a breakpoint in a process, dump some information from it and restore original opcode. Everything runs fine with notepad.exe ;)
in patched notepad.exe (with CCh opcode in code) when i reach EXCEPTION_BREAKPOINT in my tracer, address from DBEvent.u.Exception.pExceptionRecord.ExceptionAddress and eip read from context are the same which is normal i think. Then Iam patching code with original byte and call ContinueDebugEvent with DBG_CONTINUE and everything works fine.
In my application which I want to trace ExceptionAddress and EIP read from context are diffrent. ExceptionAddress is of course ok, but EIP from context is 7FFE0304. There is a RET opcode which (when debugged in softice) returns me to ntdll.
I think the problem is that that this code is working in a thread (there are 3 diffrent threads).
Even if i patch my CCh opcode with original byte and call ContinueDebugEvent i got EXCEPTION_ACCESS_VIOLATION from other thread that is trying to access data which should be processed by the thread that was broken.
Does anybody have any idea why EIP in read context is so strange and how to handle this?
Posted on 2004-01-31 05:14:20 by rahp
I dunno why you end up in ntdll (probably DbgBreakPoint or DbgUserBreakPoint) when you're debugging the process. But as for the exception... what is the return-eip from code in ntdll? The instruction after the breakpoint? Perhaps a working solution is to restore the original byte, then fix up context.eip before DBG_CONTINUE?
Posted on 2004-01-31 05:52:20 by f0dder