----------------------------------------------------------------
 Why not to use remote thread into new born process in Win2K?

 Not because process is not initialized. Process is always
initialized before primary or remote thread reaches its WinMain
or ThreadFunc. So what may hamper here?
 1) That statically loaded DLLs are in the case of remote thread
    initialized (process is initialized) by this thread (and not
    by primary one). For well written DLLs (95%) it should not be
    a problem (they shouldn't distinguish which thread initialized
    them; DLL notifications should't harm). Primary thread can be
    even replaced by remote thread (see REMOTE\Remote2Primary).
 2) That thread is not LPC registered (from Win32 API it can
    do only CreateToolhelp32Snapshot with SNAP_MODULES). For
    details see http://EliCZ.com/bugs/WinBugs.htm.
----------------------------------------------------------------

"Bug" (which may be also "invoked" by remote thread) description

 I observed this:
"If between calls to RegisterClass* and CreateWindow*, called from
different threads, the thread which initialized USER32.dll (and
GDI32.dll) has/was terminated as well as the thread which called
RegisterClass*, the class which was registered by RegisterClass*
isn't available (can't be found) and CreateWindow* fails."

 I prepared two sets of examples:
1) USER32.dll was initialized by primary thread of process
   - PRIMARY directory.
2) USER32.dll was initialized by remote thread
   - REMOTE directory.

@1) In the PRIMARY directory are the following binaries:
 USERText1.exe - primary thread is alive.
 USERText2.exe - primary thread has terminated, CreateWindow* 
                 should fail.
 USERTest3.exe - primary thread has terminated, CreateWindow* 
                 should fail.
 USERTest4.exe - primary thread has terminated but class and
                 window are created by the same thread.

    USER32.dll was initialized by child thread:
 USERTest5.exe - thread which initialized USER32.dll has
                 terminated, thread which registered class has
                 terminated, CreateWindow* should fail.

@2) In the REMOTE directory are the following binaries:
 DoRemote.exe  - remote thread is alive when RegisterClass* is
                 called by primary thread.
 DoRemoteFail.exe - RegisterClass* is called when remote thread
                 (which initialized USER32.dll and called
                 RegisterClass*) has finished. 

 Sometimes may USERTest2.exe and USERTest3.exe succeed while
DoRemote.exe may fail. It depends on thread switch time.


 I haven't made deeper "analysis". I don't know if the bug is in
WIN32K, USER32, GDI32 (or even in KERNEL32, NTDLL or NTOSKRNL).
It is not important.

 If this "bug" was present in NT4 already then it can be thought
as "normal but strange behaviour" of NT.
 USERTest*.exe work fine in Win9X (but DLLs don't get
DLL_PROCESS_DETACH notification if process is not terminated via
ExitProcess).
----------------------------------------------------------------

Corrections: Support@EliCZ.com