How to retrieve the primary thread of the process?

Yes!

I mean, inside some other threads in the process, how can I retrieve the handle to the primary thread?

The simplest way would be to call GetCurrentThread (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/getcurrentthread.asp) when inside the main thread at process start time, and cache that HANDLE in a variable (that is reachable from other threads that wish to use the same).Good approach, Sid - but with a catch: Note that GetCurrentThread() returns a pseudo-handle - it is valid only within the context of the calling thread. You need to additionally use DuplicateHandle() to convert it into a real thread handle, which can then be used from within other threads and processes.

This solution does'nt solve my problem...

In my case, the primary thread starts suspended and I want the other thread to resume it.

The primary thread has no chance to store its handle...

Is it possible to retrieve the handle directly?

In my case, the primary thread starts suspended and I want the other thread to resume it.Hm... Just wondering: If the primary thread starts suspended - who the heck is creating the additional threads? :confused:

Two people posted the same post at the same time...

And for you two:

Ever heard about CreateRemoteThread??!!

Exactly! That's the case!

Exactly! That's the case!In addition to what Sid said: If that's the case, then where's the problem of retrieving the handle of process B's primary thread from the PROCESS_INFORMATION structure after creating the the process (in step 1 above)?

I found out again, how a simple task can become a huge headache...Well, this is actually not a simple task - but looks like a strangely contrieved situation...

I can't change the primary thread. It is a black-box for me. I do not have the source of that process.Hm... So, in this case, how would you expect the additional threads that you are creating in that foreign, unknown process space to communicate with the process' primary thread in any meaningful way?

Perhaps you can explain better what exactly you are trying to do here, and why?

Hm... So, in this case, how would you expect the additional threads that you are creating in that foreign, unknown process space to communicate with the process' primary thread in any meaningful way?

I do not have to communicate with the process' primary thread at all!
I just want it to resume during my additional thread!

I do not have to communicate with the process' primary thread at all!
I just want it to resume during my additional thread!

There is no good way to get main thread from inside of process considering your case. There are two ways you can solve this,
1. Supply the main thread ID to remote thread and then do resume it from the remote thread.

2. Inside the process (call it process A) where you called CreateRemoteThread, wait for some event which will be signaled by that remote thread once you need to resume main thread and then call ResumeThread from process A.

This is the only determind and useful conclusion that actualy answer my question...Well... Note that there is a way, of course: The approach using the ToolHelp API will work as well from within a thread of the same process. It's just that, according to how you described your problem, it would be pointeless to do it that way, since resuming the thread from within your calling process (as described above) would be much easier than injecting a thread via CreateRemoteThread().

I tend to consider this as a system lack in API support.

Why not try the 2nd aproach of resuming the thread from the parent process ?

Yes indeed why not use lpParameter to pass the thread handle to ur remote thread routine?

I see that I didn't clear myself enough.
Sorry for that.
I can't describe the whole parts of my project so I'll try to clear the point:

1. Process A creates process B, which is a complete black-box.
2. Process A injects a thread into process B using CreateRemoteThread.
3. That thread run under process B, and it want the handle of the primary thread of this process.

Is this an exaggerated request?

Suggestions so far:

1. The primary thread store its handle - impossible (black-box).
2. Supply it as a parameter in the call to CreateRemoteThread - This parameter is preserved and processes by foreign code expecting a hard-coded syntax.
3. Using ToolHelp API to find the thread - There is no way to differentiate a primary thread and a regular thread.
4. Send a signal to the calling process which handle that thread - Bad strategy. And if the calling process should shut down?

Another option: pass it using a shared memory. (Looks difficult to me :()

O.K. but I still keep thinking that this is a great lack in API service. Isn't it?

Do not pass the handle to the remote thread. instead pass the thread id and do a openthread in the remotethread. Is it that bad?

In fact, many may argue that the unnecessary flexibility that the system has supplied in terms of "CreateRemoteThread" has resulted in this situation, and an absence of this API would have resulted in a better implementation on your end, resulting in no need to get that HANDLE from any external thread.Yes, I think we are using the api rather it is not meant to be.