views:

246

answers:

4

Hi! I am using WaitForSingleObject from (kernel32.dll) in my program.

It is working fine on 32bit Windows XP, but when I use it on 64bit WindowsXP, it is not working.

The problem is that it doesn't wait for the process and control moves forward.

Does anyone have any idea on why?

Is there any replacement for that method in WinXP 64bit ?

+1  A: 

The WaitForSingleObject function is either telling you that the process is already "signaled" (WAIT_OBJECT_0) or an error has occurred. To know which, we would need to know what it's returning. If the return value is anything other than WAIT_OBJECT_0 or WAIT_TIMEOUT then you need to call GetLastError() to determine what went wrong.

I would guess would be that either the process initialization failed, and you're getting WAIT_FAILED with GetLastError() == ERROR_INVALID_HANDLE, or the process has already terminated and you're getting WAIT_OBJECT_0, but without more information we can't really help you.

Tim Sylvester
The process is launched successfully, and I get WAIT_OBJECT_0 in return, but problem is it should wait for the child exe to finish.. which it is not doing....
+2  A: 

If the function's return value is telling you that the process has terminated, then perhaps it really has.

Suppose the program you start comes with 32-bit and 64-bit versions. Maybe the 32-bit version can detect that it's running on a 64-bit platform, start the 64-bit version of itself, and then terminate the 32-bit version. In that case, your program would detect the termination of the 32-bit child, but it would be oblivious to the 64-bit "grandchild" process.

You can use Task Manager or Process Explorer to confirm this hypothesis. Find the program that's still running. Is its pid the same as the pid that CreateProcess returned to you?

Rob Kennedy
I like that suggestion. Sounds quite plausible.
Steve Rowe
The SysInternals utilities do this, they have the 32- and 64-bit executables bundled together with a custom launcher. It's also possible that Windows itself is doing something like that with wow64...
Tim Sylvester
A: 

I agree with Rob, it's not quite probable that WinAPI is wrong: if it says it's terminated, then it is.

Do you somehow follow the output of the child process? Is it possible that it failed early in its initialization, e.g. when trying to load DLLs for the wrong platform (32/64), getting some environment variables pointing to wrong location depending on the platform etc.?

Nikola Gedelovski
A: 

A little searching turned up this code for a tcsh implementation:

http://www.opensource.apple.com/source/tcsh/tcsh-60/tcsh/win32/fork.c

(Search for the second instance of "WaitForSingleObject")

It looks like they may have had the same problem that you did. The WFSO is commented out and replaced by a set of shared events that the new and existing processes use to communicate. Perhaps this is a common problem, or even a yet-to-be-fixed windows bug.

Tim Sylvester