The Old New Thing

From a cold reading of the MSDN, it would appear they are doing it "right"..

Wild guess, based on reading the hint article: They see that the exit code is 0 in the debugger, because their debugger is creating a new thread during process termination to be able to debug the process. And the debug thread terminates successfully.

From MSDN

"Terminating a process does not necessarily remove the process object from the OS. A process object is deleted when the last handle to the process is closed. "

So, they are in a circular loop where they can't retrieve the Exit Code until they close their handle?

Maybe they should call DuplicateHandle with the DUPLICATE_CLOSE_SOURCE flag.

(Especially in light of the provided hint article) I would guess they are waiting for the process to end in the wrong way... probably by waiting on a mutex.  Thus they race with the dying process to read the exit code.

A guess: a DLL their process is using calls ExitProcess(0) itself as part of its teardown.

If the process were still running, the exit code would be 259 and not 0.

I have no clue what the problem is. They are doing everything right. If they are doing something incredibly stupid like calling ExitProcess from DLL_PROCESS_DETACH, we wouldn't be requested to invoke psychic powers to debug that, that would just be plain dumb.

I believe it's involving DLL_PROCESS_DETACH - something they're doing is pooching the exit code.

That's my guess anyway.

Joel: You don't want the OS to delete the process object, that's where your exit code is stored.

El Guapo: (rereads documentation) Ah, you're right. d'oh!

Calling RaiseException with 0 doesn't seem like psychic debugging, either.

Maybe we can get to ExitProcess(0) with a better story behind it... something like: DLL_PROCESS_DETACH handler tries to use a critical section, ends up reading something in an inconsistent state, faults, the exception filter runs and ends the process with 0.

Would such an exception be handled by a try/catch block?  The thought of an exception unwinding the stack past ExitProcess is pretty scary.

Perhaps the called program is exiting successfully!

this is an easy one - it's just an off-by-one error deep in the guts of windows :)

Yeah, a crash is probably happening in a DLL_PROCESS_DETACH, which is just causing TerminateProcess to be called on self and thus an exit code of 0.

I liked how in the referenced article, Raymond actually had FAITH in his readers to not nitpick!  Aaaahhhh Raymond, you sure were foolish in your younger free-wheeling days of a year ago.

(Disclaimer:  Long time reader who was a few shades less upset with the nitpickers as Raymond had to have been.)

My psychic powers are weak; my guess is that some loaded DLL is either crashing or calling ExitProcess(0) during DLL_PROCESS_DETACH.

Maybe they aren't checking the return value from GetExitCodeProcess? The process might be racing or hung in which case the return value would be STILL_ACTIVE (259), but they wouldn't know that, since they didn't check it?

I am able to reproduce this with an UnhandledExceptionFilter (using ExitProcess again) and with structured exception handling (returning control to main.)  I imagine there are other permutations of this approach as well.

Kudos to whoever made ExitProcess behave so well in these circumstances.

Q: Why does ExitProcess(1) produce an exit code of zero?

A: Welcome to windows programming.

My guess is that they're using ShellExecute to launch the program.  Then they're passing the return value of ShellExecute to GetExitCodeProcess.  But since ShellExecute doesn't return a process handle this causes GetExitCodeProcess to return 0 for error.

Last week I've resolved a simple "debugging" case by phone, and figured that it might benefit