Tom Lane wrote:
> win32.h says
>
> /*
> * Signal stuff
> * WIN32 doesn't have wait(), so the return value for children
> * is simply the return value specified by the child, without
> * any additional information on whether the child terminated
> * on its own or via a signal. These macros are also used
> * to interpret the return value of system().
> */
> #define WEXITSTATUS(w) (w)
> #define WIFEXITED(w) (true)
> #define WIFSIGNALED(w) (false)
> #define WTERMSIG(w) (0)
>
> I think this supposition has been pretty much proven false by recent
> reports of silly "exit code" numbers from Win32 users, as for instance
> here
> http://archives.postgresql.org/pgsql-bugs/2006-12/msg00163.php
> where the postmaster reports
> server process exited with exit code -1073741819
> from what I suspect is really the equivalent of a SIGSEGV trap,
> ie, attempted access to already-deallocated memory. My calculator
> says the above is equivalent to hex C0000005, and I say that this
> makes it pretty clear that *some* parts of Windows put flag bits into
> the process exit code. Anyone want to run down what we should really
> be using instead of the above macros?
>
The exit code is apparently what is reported from GetExitCodeProcess().
For info on that see
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/getexitcodeprocess.asp
I think we are possibly seeing the third case, i.e. the code from an
unhandled exception. I haven't managed to find an API to handle them
though ...
cheers
andrew