We know the id of a thread (DWORD dwThreadId). Then, how can we get the process identifier of the process associated with the specified thread?
I find the API below which could get the process id through the handle of the thread.
DWORD WINAPI GetProcessIdOfThread(
__in HANDLE Thread
);
However, the handle of the thread is unknown now. We only know the id of the thread.
If we don't use the API "GetProcessIdOfThread", is there any other mehtod? Because the minimum supported client of the API "GetProcessIdOfThread" is Vista. But I work on the XP system.
Where is your purpose on this ? Where do you get thread id anyway ?
If this is YOUR process, just call GetCurrentProcessId() directly.
If this process is spawned by you using CreateProcess(), just read PROCESS_INFORMATION structure for dwProcessId member.
If this process was not spawned by you then things get complicated. If it is a GUI program use FindWindow() to get a window handle, then use GetWindowThreadProcessId() to get process id as second argument.
Note that CreateToolhelp32Snapshot and related functions are aimed at diagnostic tools.
If that's not what you're writing you should go that way. Without administrative or debug privilege you won't be able to do a lot with the process id you obtain.
Although andywestken is technically correct, the tlhelp32 functions ARE meant for debugging, neither the target process or your process have to be running in debug mode. This is niether a thread injection or image hijack for the target process so there is no risk of a crash. There are precious few choices in Windows XP to associate a third parties thread by it's ID to it's parents process. I would suggest the options that modoran posted first but if they do not work then mine will.
I guess I am just curious about why one app need to know about another's threads, apart from diagnostic purposes.
Enumerating the process, threads, and heaps is only really useful if once you see them, you do something with them. Unless you're writing a diagnostic tool which is just about viewing what's going on.
And I know the tool help API itself is safe, as it works with a snapshot.
Andy
P.S. Not directly relevant, but Toolhelp32ReadProcessMemory does require elevated privileges.
As we know, the API "PostThreadMessage" could posts a message to the message queue of the specified thread using the parameter of thread-id.
What I want to do is to block the application to post messages to the thread which belongs to other applications. And applications could create multi-processes.
Now I have a hook on the API "PostThreadMessage" and a process-id-list created by this application, and then I need to check if the process-id associated with the thread identified by the parameter of thread-id is included in the process-id-list. If no, block the message.