In above function's arguments,
"lpExitTime " is "Pointer to a FILETIME structure that receives the exit time of the process. " But MSDN library also says that if the process has not exited, the content of this structure is undefined.

So , I am stuck . Any help ?

Thanks,
Ashwini

December 13th, 2002, 11:51 AM

alpha137

After creating the process call WaitForSingleObject and pass the handle of the new process as first parameter.
WaitForSingleObject will block your current thread / will not return until the process terminates.
If you do not want to block your current thread create a new one where you call WaitForSingleObject.

You can use GetExitCodeProcess to find the state of a process if you do not want to wait for the process to end but just check up on it. It will give you a STILL_ACTIVE notifier if the process is still running.

December 14th, 2002, 04:05 AM

Andreas Masur

Re: some more info

Quote:

Originally posted by galathaea
You can use GetExitCodeProcess to find the state of a process if you do not want to wait for the process to end but just check up on it. It will give you a STILL_ACTIVE notifier if the process is still running.

'hHandle' is returned within the process information structure which is passed to 'CreateProcess()'....

April 7th, 2004, 11:00 AM

elim

Re: some more info

Quote:

Originally posted by galathaea
You can use GetExitCodeProcess to find the state of a process if you do not want to wait for the process to end but just check up on it. It will give you a STILL_ACTIVE notifier if the process is still running.

But what if I want more information? I cannot believe that the process cannot tell me if the thread is currently running, or is in a suspended state?

Does windows not have a call, or something very similar to it, that if I give the function a pointer or handle to my thread, it can return to me somehow the status of the thread? Something like...

Code:

switch (::GetThreadStatus(m_thread))
{
case SUSPENDED:
break;

case RUNNING:
break;

case TERMINATED:
break;

default:
break;
}

April 7th, 2004, 04:45 PM

Andreas Masur

Re: Re: some more info

Quote:

Originally posted by elim
But what if I want more information? I cannot believe that the process cannot tell me if the thread is currently running, or is in a suspended state?

As far as I know, there is no way of getting this information...in other words, I did not find a way yet using regular API etc.

April 7th, 2004, 04:52 PM

Mick

The native api can be used to obtain this information.

NtQuerySystemInformation using SystemProcessessAndThreadsInformation enumeration, there is a THREAD_STATE enum inside of the SYSTEM_THREADS struct.

let google be your guide as far as code usage or buy Windows NT/2000 Native API reference by Gary Nebbitt (if you still can somewhere) and it is all laid bare in there.

April 8th, 2004, 08:21 AM

Andreas Masur

Quote:

Originally posted by Mick
The native api can be used to obtain this information.

Well...I could have guessed that on my own...it looks like am getting too old for the job... :rolleyes:

April 8th, 2004, 08:51 AM

Mick

Quote:

Originally posted by Andreas Masur
Well...I could have guessed that on my own...it looks like am getting too old for the job... :rolleyes:

Nah, maybe you were just distracted, happens to me all the time...but anyways guess I'll spiel for the OP....some simple things people always assume there is an API for but it's a little more complex, usually you have to hit the Native Api to accomplish this in a robust way eg: getting command line params in/from another process (CreateRemoteThread? bah too intrusive, and too restrictive) BUT since the native api is not necassarily documented by Microsoft it can be a maintaince issue if underlying structs, api's change between releases, so you have to keep that in mind. And yes I am aware they finally put up NtQuerySystemInformation....

Thread State is ever changing, so a snap shot really tells you just that, that's the threads state at the moment, making coding decisions based upon it is not very wise, displaying informational things is fine. In future SDK's etc, they may return addition thread info from the tool hlp lib eg: THREADENTRY32.

You could also use (and works well in a distrubuted env)

The performance monitoring api's

PdhXXX to get thread state.

WMI, parsing the Win32_Thread calls (which contains state information) (or the performance classes as they are encapsualted as well)

possible states for the thread under nt/2k (haven't looked for xp but it's doubtful another member has been added)..

StateInitialized - (recognized by the microkernel)
StateReady- (prepared to run on next available processor)
StateRunning - Obvious
StateStandby -about to run, only one thread may be in this state at a time)
StateTerminated - Obviouus
StateWait - (not ready for the processor, when ready, it will be rescheduled)
StateTransition - (thread is waiting for resources other than the processor)
StateUnknown - Obvious