Lerele wrote:
It seems after all the solution proposed may be the best resort,
instead of the last: more compatible, less interfereable with child,
however a bit more difficult to write.
In fact, the first version of interrupt code I wrote several months
ago worked like that (I still keep a copy somewhere). It worked, but
it was buggy, so I dropped it and wrote that other simpler new version.
This other solution may be the one-for-all solution, because it uses
rather more standard Win32 calls.
The more I search for a *clean* way to do it in WinCE, the more I'm
inclined to drop the create_a_remote_thread idea. A bit of
googling and reading old MSFT docs indicates that older debuggers either
suspend all threads with SuspendThread (like you suggest, or get the
main thread's PC (EIP) and set a breakpoint there, which should be
simpler. (I would still have to do a little more work for WinCE
because the address might not be physically writable.) I think I
read somewhere that recent MSVC uses DebugBreakProcess, and hides the
fact
that the break was inside ntdll.dll, or wherever, by switching threads...
What do you think of just suspending of thread, and setting a breakpoint
at the current PC, and resuming?