Untraceable Error

Question

I have a rather simple program that operates as an inventory tracking program. It is a single thread, .net 4.0, and is entirely event driven(nothing happens without a button click). The program crashes without a button being clicked. Here are the measures I have taken to attempt to get any information about this error:

FIRST: LOOK FOR UNHANDELED EXCEPTIONS OR THREAD EXCEPTIONS. CREATE A MESSAGE BOX POP-UP AND A DATABASE ENTRY FOR THIS ERROR:

static void Main()
    {
        Application.EnableVisualStyles();
        Application.SetCompatibleTextRenderingDefault(false);

        Application.ThreadException += new ThreadExceptionEventHandler(Application_ThreadException);
        AppDomain.CurrentDomain.UnhandledException += new UnhandledExceptionEventHandler(CurrentDomain_UnhandledException);

        Application.Run(new archiveInventory_b());
    }
    static void Application_ThreadException(object sender, ThreadExceptionEventArgs e)
    {
        MessageBox.Show(e.Exception.Message, "Unhandled Thread Exception");
        ErrorLogEntry(e.Exception.Message + " INNER EXCEPTION: " + e.Exception.InnerException.Message, "ThreadException");
    }

    static void CurrentDomain_UnhandledException(object sender, UnhandledExceptionEventArgs e)
    {
        MessageBox.Show((e.ExceptionObject as Exception).Message, "Unhandled UI Exception");
        ErrorLogEntry((e.ExceptionObject as Exception).Message + " INNER EXCEPTION: " + (e.ExceptionObject as Exception).InnerException.Message, "UnhandledException");
    }

The program closes and no message box or database entry.

SECOND: CATCH THE CULPRIT IN THE ACT WHEN THE PROGRAM CLOSES:

private static void form_Closing(object sender, CancelEventArgs e)
    {
        const string message =
    "Are you sure that you would like to close the program?";
        const string caption = "Form Closing";
        var result = MessageBox.Show(message, caption,
                                     MessageBoxButtons.YesNo,
                                     MessageBoxIcon.Question);

        // If the no button was pressed ... 
        if (result == DialogResult.No)
        {
            // cancel the closure of the form.
            e.Cancel = true;
        }
    }

Yet no message ever appears. What else can be done to track this one down?

Answer 1

There are three basic reasons why a .NET program can crash to the desktop without firing the event handlers you wrote. I'll assume it is not something obvious like Environment.Exit() in your code:

• A StackOverflowException. There is not enough stack space left to do anything safely, including firing those events. You'll always know about it when you have a debugger attached but no notification at all when you run your program without one.

• An ExecutionEngineException. Raised by the CLR when it detects that its internal data structures are corrupted. By far the most common reason is corruption of the GC heap, in turn caused by a bad pinvoke declaration or misbehaving unmanaged code. Exceedingly difficult to diagnose, the damage is always done long before the crash occurs.

• A /GS violation. /GS is the name of a C++ compiler option that adds extra checks to code to verify that the processor stack was not corrupted. A very common malware attack vector, a way to get a processor to execute arbitrary code with just data. /GS checks are present in the CLR as well as code generated by the jitter. Such mishaps are very rare, the original .NET 4.0 release had some bugs in the CLR that triggered this check incorrectly but I haven't heard about it for quite a while. They can be diagnosed with the debugger, you however have to turn on unmanaged code debugging.

Which one of those three is crashing your program is something you'll have to find out the hard way. The most basic way to discover which way you need to go hunting next is paying attention to the process exit code. Its value will be non-zero to indicate failure, it is set to the matching underlying SEH exception code. When you have trouble reproducing the crash then you may have to write a little helper program that does nothing but use the Process class to start your main program. When it stops, the Process.ExitCode gives you the value.

Needless to say perhaps, this is going to take a while to get fixed so allocate the resources you need to hone down on the problem. Extensive testing to get a repro is required. Keep your fingers crossed for a simple SOE, by far the most common reason, those other two are awfully ugly and you're liable to need Microsoft Support.

Answer 2

There is a known issue about swallowed Exceptions in the Load() event in Windows x64.

To eliminate this reason (or check it...), could you please add an try/catch in your load event (if applicable), so you can verify if any exception occurs here ?