[Issue 1360] New: GC emits HLT when GetThreadContext fails after CreateRemoteThread.

[Sean Kelly]

d-bugmail at puremagic.com wrote:
> 
> If an external process trys to CreateRemoteThread the current process (to
> inject a DLL in this case) the gcx stack scanning code fails in
> GetThreadContext().

I'm not sure there's anything that can be done about this.  The stack 
scanning routine only calls GetThreadContext on threads it knows about 
(ie. D threads), so it's unlikely GetThreadContext is interacting 
directly with the injected thread.  More likely, and more troubling, is 
that injecting a thread is screwing up the application somehow and 
causing it to fail.  If I had to guess, I'd say that the injected thread 
was using debug routines (specifically, SuspendThread and ResumeThread) 
at the same time a collection cycle was occurring, and it resumed a 
thread that was supposed to be suspended for scanning or something like 
that.

More remote is that the process of injecting a thread is screwing 
something up.  From the docs on CreateRemoteThread:

     there are several side effects to using this technique:

     * It converts single-threaded applications into multi-threaded
       applications.
     * It changes the timing and memory layout of the process.
     * It results in a call to the entry point of each DLL in the
       process.

Normally, I'd think these should all be fine, but given the error, I'm 
wondering what the second clause implies.

> GetLastError() returns ERROR_GEN_FAILURE and the code hard exists via a HLT
> instruction.

Unfortunately, this isn't terribly useful.  Near as I can tell, 
ERROR_GEN_FAILURE just indicates a general failure condition.  The 
actual text description is "a device attached to the system is not 
functioning."

> Seems a few anti virus/spyware utilities use this injection method, so its
> likely to be a problem.

A further comment on the function:

     Another common use of this function is to inject a thread into a
     process to query heap or other process information. This can cause
     the same side effects mentioned in the previous paragraph. Also, the
     application can deadlock if the thread attempts to obtain ownership
     of locks that another thread is using.

This doesn't sound terribly encouraging.  Is the error reproducible? 
I'm curious if it's a timing issue.


Sean