Windbg used to do this, but now it has stopped and the disassembly window shows eip at an int 3 instruction.
Context - I start windbg and it has reloaded the workspace, so it is ready to go, with source, executable, breakpoints and
windows from the last session. I hit F5 (run) twice and my app is running. I alt-tab into the app and do things that cause
it to encounter the breakpoint. I alt-tab back into the debugger and that's where we are.
Or - this is what it is doing now with a different break point -
It stops at the breakpoint:
mov esi, [ebfcp]
And the source line is magenta (breakpoint and current location)
The disassembly window has the proper line highlighted:
004028b2 8b3542b34000 mov esi,dword ptr [lfw!ebfcp (0040b342)] ds:0023:0040b342={lfw!ebuf (0040b34c)}
So all seems well.
But when I hit F8 (trace) eip goes to:
7c90120e cc int 3
Some breakpoints work properly; some dom't and I can't see a significant difference between the ones that work and the ones that don't.
What can be causing this?
This is the batch file I use to assemble and link:
g:
cd lfw
g:\masm32\bin\ml /c /coff /Cp /Fl /W2 /Zi /Zd g:\lfw\lfw.asm >errs
if errorlevel 1 goto erfc
g:\masm32\bin\link /SUBSYSTEM:WINDOWS /LIBPATH:g:\masm32\lib /DEBUG /DEBUGTYPE:CV /PDB:lfw.pdb lfw.obj >>errs
if errorlevel 1 goto erfc
cd\
c:
exit
:erfc
type errs
pause
cd\
c:
And this is the command I use to start windbg:
"C:\Program Files\Debugging Tools for Windows (x86)\windbg.exe" -QY g:\lfw\lfw.exe -y g:\lfw
Thanks
Robert
dunno if this will help, but.....
when INT3 occurs, it is up to the handler to replace the INT3 in the code stream with the opcode that was BP'ed
that doesn't appear to be happening in this case - a fault of the debugger, perhaps
or - the INT3 handler attempts to replace the opcode byte like it's supposed to, but can't because of access rights
i would think that would crash with the all-too familiar c0000005 access violation
if the debugger has replaced the exception handler, that crash may not occur
strange things may happen if an INT3 is immediately followed by another INT3
that may be something like what you are seeing
there is a BP in your code - but the handler somehow has a BP in it's first instruction ??? (maybe - lol)
the handler gets lost - lol
maybe the INT3 vector is screwed up to start with
the code address on the stack needs to be adjusted by the handler, as well
by subtracting one, the returning EIP points to the BP'ed instruction
not sure how "single-stepping" works on a pentium
but that is different than an INT3 BP
Thanks dedndave.
The debugger has done other weird things, like jumping somewhere when it should be executing
mov al, [esi], so I think maybe a file has gotten corrupted and I need to reinstall it.