Unexpected exit code from a .NET console application

Question

I have written a console application and a companion class library to export some data from a cloud service. The application is called by SQL Server Integration Services which relies on the exit code returned by the application to determine if it worked correctly or not.

Intermittently the application returns an exit code of -532462766 (0xE0434352) which is the generic error code for a .NET unhandled exception. I'm totally flummoxed as to why this is happening.

The log files generated by the applications do not show any issues and they look like everything has completed successfully.

There are no entries in the Application Event Viewer logs.

The application even has an unhandled exception handler:

AppDomain.CurrentDomain.UnhandledException += UnhandledErrorHandler;
...
private void UnhandledErrorHandler(object sender, UnhandledExceptionEventArgs e) {
    logWriter.Write(e.ExceptionObject.ToString(), logLevel.Fatal);
    logWriter.Write("Exiting now...", logLevel.Fatal);
    Dispose();
}

I've even written a batch file to execute the application and log the exit code before passing it along to SSIS. The exit codes that SSIS are receiving are the ones that seem to be returned by the application. But I cannot see an unhandled exception happening anywhere.

The console application returns the exit code by defining Main() like so:

class Program {
    static int Main(string[] args) {

    ...

    return (Success) ? 0 : 1;
}

Because it is intermittent (and the data extraction can take a couple of hours) I can't just run it in Visual Studio and debug it. I have a suspicion it might be related to the fact that the application does run for such a long time but I can't seem to confirm that.

Is there anything else that can cause a .NET application to return that exit code? Am I missing something in my troubleshooting?

Maybe [this](http://stackoverflow.com/questions/14711633/my-c-sharp-application-is-returning-0xe0434352-to-windows-task-scheduler-but-it) post and the answers could help you. Is it possible to comment out some parts of your code to pinpoint the problem? Did you also deploy the PB files in order to get more information and did you already ruled out a memory problem? — Jeroen Heier, May 04 '16 at 04:27
Thanks Jeroen but I have seen that question and unfortunately it didn't help as I already have an unhandled exception handler and there are no entries in the application event viewer logs. I will try deploying the PDB files and see if that gets me any additional information. — Mike D., May 04 '16 at 05:01

score 2 · Answer 1 · answered May 04 '16 at 04:29

2

quick check: wrap your entire code inside a try catch block and save the exception in a log file.

static int Main(string[] args)
{
    try
    {

          //your existing code....

    }
    catch(Exception Ex)
    {
        //write your log results here.

    }
}

answered May 04 '16 at 04:29

John

819
1
9
20

Do not forget to log the inner exceptions – Jeroen Heier May 06 '16 at 04:30

score 0 · Answer 2 · edited Sep 23 '16 at 15:08

Check if you are using multiple app domains. I encountered this same issue when an exception X was thrown in AppDomain B and could not cross to AppDomain A because it was not serializable. See also best practices for exceptions (search for 'across app domains'):

When you create user-defined exceptions, you must ensure that the metadata for the exceptions is available to code that is executing remotely, including when exceptions occur across app domains. For example, suppose App Domain A creates App Domain B, which executes code that throws an exception. For App Domain A to properly catch and handle the exception, it must be able to find the assembly that contains the exception thrown by App Domain B. If App Domain B throws an exception that is contained in an assembly under its application base, but not under App Domain A's application base, App Domain A will not be able to find the exception, and the common language runtime will throw a FileNotFoundException exception. To avoid this situation, you can deploy the assembly that contains the exception information in two ways:

Put the assembly into a common application base shared by both app domains.

or

If the domains do not share a common application base, sign the assembly that contains the exception information with a strong name and deploy the assembly into the global assembly cache.

Thanks for the info! That is quite useful. I've added the relevant quote from the page you linked to which is the recommended procedure here on StackOverflow. Links can change and pages can get deleted so we try to preserve a copy of the information here. While still providing the link & attribution to the source, of course. And that is a useful find. — Mike D., Sep 23 '16 at 15:10

Unexpected exit code from a .NET console application

2 Answers2