why one should not send APC to the debugger thread, as the doc says). I'm
not sure what you mean "until process stops". Are you trying to read/write
"Joseph M. Newcomer" <newcomer@flounder.com> wrote in message
No, the location I'm reading is a code location. It exists. According to
the
documentation, all I need is a process handle to the process, and this
handle is valid as
long as the process exists. In this case, "exists" will go beyond "is
runnable".
In my original code, I did the debugging loop in the main GUI thread, and
it all worked
perfectly. But like most designs that block the main GUI for lengthy
periods, this was an
unacceptable solution for the long term. So as soon as I had all the code
working to my
satisfaction, I could concentrate on the aspects that made the difference
betweeen a toy
and something really usable, such as doing the work in a separate thread.
When I moved
the process monitoring to a thread, however, things went a little weird.
The
WaitForDebugEvent stopped working. RTFM. Oops, WaitForDebugEvent can
only monitor
processes created by the thread exectuting WFDE. Fine, move process
creation to the
thread. OK, it works. But the analyzer phase still ran in the main GUI
thread, and it
suddenly stopped working. All attempts to read the memory returned error
Access Denied.
So I create some read-memory probes. The process state was readable in
the thread in
which the CreateProcess was done, but not in the main GUI thread. Yet
there is nothing in
the docs to suggest this limitation, since the process handle for the
child is clearly
allocated to the parent process and therefore should be valid in all
threads, As far as I
can tell, the only reason is an interaction with WFDE, but having read all
the material on
the debug interface, no such limitation is described.
joe
On Wed, 2 May 2007 15:19:59 +0900, "Norman Diamond"
<ndiamond@community.nospam> wrote:
Thank you for tracking down and reporting this behaviour, but I think it's
at least partly sensible. Compare to the following hypothesis:
Worker thread does a CreateProcess, gets a process handle
Worker thread calls ReadProcessMemory (A) successfully
Subprocess calls VirtualAllocEx
Worker thread calls ReadProcessMemory (B) successfully
Subprocess calls VirtualFreeEx
Worker thread calls ReadProcessMemory (B) and fails
Subprocess stops
Maybe worker thread calls ReadProcessMemory (A) and fails?
"Joseph M. Newcomer" <newcomer@flounder.com> wrote in message
news:rq3g331gdpgkt4lp38t6sicvtsafbkgorn@4ax.com...
It took some time to track this one down.
Main GUI thread spawns worker thread
Worker thread does a CreateProcess, gets a process handle for the
process
Worker thread enters a debug-event loop, does things until process stops
Worker thread does a PostMessage to main GUI thread
Worker thread terminates
Main GUI thread receives notification
Main GUI thread attempts to ReadProcessMemory
ReadProcessMemory fails with "access denied"
Main GUI thread closes process handle
The solution seems to be
Main GUI thread creates event
Main GUI thread spawns worker thread
Worker thread does a CreateProcess
Worker thread enters debug-event loop
Worker thread does PostMessage to main GUI thread
Worker thread waits on event
Worker thread closes event handle
Main GUI thread receives notification
Main GUI thread performs (successfully) ReadProcessMemory
Main GUI thread closes process handle
Main GUI thread does SetEvent to let worker thread finish
Note that this behavior, that ReadProcessMemory will not work if the
thread that created
the process terminates (it makes no sense, actually), is undocumented.
It
may be that it
would work if I had not used WaitForDebugEvent, but if so, this is also
undocumented.
(I'm working on a simple performance analyzer. Stay tuned for later
publication...)
joe
Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm