Which exit codes can a .net program have, when Environment.Exit() is not used?

Question

If a .net program fails to explicitely set the exit code before terminating (by calling Environment.Exit() / Appliation.Current.Shutdown() / ...), what is the exit code for that process?

Does a normal termination always result in exit code zero, and what are the other possible cases?

According to this answer to the related question Getting ExitCode From Exception Handler by Hans Passant: "if a program dies on an exception then its exit code is normally the same as the underlying exception error code".

So an uncaugth exception can cange the exit code. Is this always the case, and is the underlying exception error code always guaranteed to be different from zero, and in a specific range?

Are there other circumstances where the .net framework or Windows can automatically set another exit code, such as some non-exception related crash (is that possible?), or a forced task kill?

To put it another way, could I determine by the exit code whether the program terminated in any abnormal fashion or not?
Or if an exit code of zero can happen in some abnormal cases as well, could I include a Environment.Exit(somevalue) in all normal termination paths for a program, and be sure that this exit code can never occur in case of a crash?

---

Motivation:
Since not all exeptions are catchable without severe workarounds, and since there may be other causes for sudden program termination other than uncaught excpetions, making sure that all code paths call Environment.Exit() is not alwas possible. This is why I am interested in determinining whether the exit code can be used to reliably tell whether a program exited normally.

Answer 1

then its exit code is normally the same as the underlying exception error code

After 6 months, you should have built up some confidence that normally applies. Probably worked just fine, you just can't get a warranty here. It is not just unhandled exceptions that make a process terminate and you can never be sure that it is always the same code that runs when a process dies on an exception.

There is far too much stuff out there that wants to be involved with this and it is not always of the best quality. On top of the list is certainly anti-malware, there is a lot of cr*pware out there and you'll never know what you run into. The recent Avast disaster gives plenty of reasons to be concerned about this. Not nearly where it ends, utilities that replace WER are common enough.

And you are completely defenseless against a yokel that thinks that TerminateProcess() is a good way to solve a file locking problem. Or somebody tripping over the power cord and unplugging the machine.

Focus a bit on why you want to know the exit code. There ought to be something you do next that uses the result of the program to continue executing. Validate the result.

Answer 2

Is the process you're executing your own? That is, can you control its exit code under predictable circumstances? If so, you could catch any exception thrown and then return your own predictable non-zero exception code (a specific value or your own range.) I would use a negative number since system error codes are positive. That way you've got three possibilities:

1. Zero - success
2. Negative - process threw an exception that you were able to catch
3. Positive - process threw an exception that you couldn't catch. That would be abnormal.

Anything other than that seems unpredictable. If something is so far outside of normal that a process can't even return a non-zero exit code then the process waiting for that exit code may also have failed. Checking for a non-zero exit code is what you can reasonably do to account for the possibility of failure due to any unforeseen cause.

I don't know if #3 is even possible, but if you're trying to account for the unknown then it's probably the most you can do.

Here's an example:

internal class Program
{
    private static void Main(string[] args)
    {
        var exitCode = 0;
        try
        {
            //do something
        }
        catch (SystemException systemEx)
        {
            //log
            exitCode = -systemEx.HResult;
        }
        catch (Exception ex)
        {
            //log
            Environment.ExitCode = int.MinValue;

        }
        Environment.ExitCode = exitCode;
    }
}

That's what you could do. But I wouldn't use the exit code to describe the error. I'd use logging for that. I'd use the exit code to tell the calling app what to do. Zero or non-zero is probably sufficient for that. I've written more complicated return codes that indicate whether the failure was IO-related or SQL-related and in the end I never used any of it. If it fails I look at my log for an error message.