winforms - Silent failures in C#, seemingly unhandled exceptions that does not crash the program

Question

In a winforms app, in a form's Load event, add the following line:

throw new Exception();

and run the application. It ran without a problem. This is called a silent failure, you can try to add messageboxes before and after, and you'll soon find out that instead of crashing the application, the throw statement just exits from the Load event.

I'm sure there is no need to explain how ugly and dangerous this is.

I was wondering nonetheless in the (probably history) reasons behind this terrifying behavior. I'm sure it's not a design decision, probably no-choice, or laziness. Does anybody know?

Would be glad if anyone can point me to a list of events which may cause seilent failures too.

Here's a snippet of my code - I have no idea how it might help - but, here it is:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Windows.Forms;

namespace WindowsFormsApplication1
{
    static class Program
    {
        /// <summary>
        /// The main entry point for the application.
        /// </summary>
        [STAThread]
        static void Main()
        {
            Form f = new Form();
            f.Load += new EventHandler((x, y) => { throw new Exception(); });
            Application.Run(f);
        }

    }
}

EDIT It seems it does not happend to everyone. I use: fw 3.5, winforms, vs 2008, vista x64, new clean project of winforms, with the code mentioned above.

Answer 1

This is a known problem on x64 systems:

This is a known issue on 64-bit OS platform. The reason is that the 64bit OS core does not allow user mode exception through kernal mode stacks. The exception is swallowed by OS sliently. That happens in FormLoad handler, because it is called in an OS callback. 32bits OS doesn't do this, so it doesn't repro there.

The OS team is investigating related issues. In the mean time, you do have to work around this issue. Turning on "Stop on first chance exception" will make the debugger to stop in this scenario. But it does make the debugger to stop very often, so you might want to do this only when you find a problem.

The linked bug report was last updated February 2008, and doesn't indicate what's happened since then.

I can reproduce most poster's behavior on my 32-bit system here, and I can reproduce the OP's behavior on my 64-bit (Vista SP2, 3.5SP1 Framework) work PC.