On Sunday, 31 March 2013 at 20:08:05 UTC, Vladimir Panteleev wrote:
> On Sunday, 31 March 2013 at 15:21:38 UTC, Lars T. Kyllingstad wrote:
>> As you may already have guessed, it does *not* print "TerminateProcess failed" and exit with code 0.
>>
>> But does it print "TerminateProcess succeeded" and exit with code 1? NO! It prints NOTHING and exits with code 123, because TerminateProcess() terminates the CURRENT process when it is passed INVALID_HANDLE_VALUE.  Aaaaargh!
>
> How did INVALID_HANDLE_VALUE get so far in the code as to reach TerminateProcess? Shouldn't an enforce call have been in place to validate whatever the source of the handle is?

I was operating under the (reasonable, IMO) assumption that TerminateProcess would fail if given an invalid handle, and that such a check would therefore be redundant.  This certainly seems to be the case on newer Windows versions.

As it turns out, INVALID_HANDLE_VALUE is *not* an invalid handle value, and consequently the function does not fail.

> Anyway, this is documented behavior. You can pass GetCurrentProcess() to TerminateProcess to terminate the current process.

This is not specified in the TerminateProcess() documentation, which simply says that hProcess must be "a handle to the process to be terminated".  (It is mentioned in a user comment, though.)

http://msdn.microsoft.com/en-us/library/windows/desktop/ms686714%28v=vs.85%29.aspx

You're right that it *is* specified in the GetCurrentProcess() documentation, but there is no explicit warning that this particular magic value coincides with another magic value.

> Your plight was caused by the unfortunate (or perhaps, unforesighted) coincidence that GetCurrentProcess() returns the special (magic) value of (HANDLE)-1, the same value of INVALID_HANDLE_VALUE.

...which is just incredibly poor design.

Lars