Now I can't set bp on WinMain
though I can see the disassembly of it,and I can't list the source of WinMain
either:
0:000> u WinMain
00401040 55 push ebp
00401041 8bec mov ebp,esp
00401043 6a00 push 0
00401045 e87e0e0000 call monitormt!g_thread_init (00401ec8)
0040104a 83c404 add esp,4
0040104d e8700e0000 call monitormt!gdk_threads_init (00401ec2)
00401052 e8650e0000 call monitormt!gdk_threads_enter (00401ebc)
00401057 e8d4040000 call monitormt!select_device (00401530)
0:000> ba WinMain
^ Unable to set breakpoint error
The system resets thread contexts after the process
breakpoint so hardware breakpoints cannot be set.
Go to the executable's entry point and set it then.
'ba WinM开发者_Python百科ain'
How to do it in windbg?
UPDATE
It seems bp
works,but why ba
doesn't?
The message displayed by debugger actually explains quite clearly why ba
would not work at this point. Instruction ba
sets a hardware breakpoint. Hardware breakpoints are set through debug registers. The debug registers are part of the processor context, which is set by OS. You just loaded the process into memory -- all memory layout is ready, but processor context has not been set. If you debugger sets some registry values right now, those changes would not matter, because OS will override all register values while starting executing process.
A software breakpoint (bp
) is better here because it works by overwriting instruction at address you specified to INT 3
instruction. Obviously that is not affected by processor context changes, so that works any time, even on initial processor breakpoint.
Workaround is simple -- first make a single step using t
instruction, then you can use hardware breakpoints as you like. For execution breakpoint I would recommend to use software breakpoints. You can create any number of software breakpoints, while number of hardware breakpoints is limited to number of debug registers.
精彩评论