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
