40

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.

H H
  • 263,252
  • 30
  • 330
  • 514
Letterman
  • 4,076
  • 5
  • 29
  • 41
  • 1
    Can you further explain your problem with a snippet from your OnLoad event handler for your form. Also, do you have an UnhandledException handler within this application domain? If this is the main form of the application and it can't load because you threw an unhandled exception what did you expect to have happen? I suspect your the unhandled event handler would be invoked in this case. – Wil P Oct 17 '09 at 22:17
  • What version of windows are you using? – Quintin Robinson Oct 17 '09 at 22:26
  • 3
    I actually voted your previous question down again, it's badly written AND arrogant... – Blindy Oct 17 '09 at 22:41
  • 7
    Your question is not answered here: http://blogs.msdn.com/ericlippert/archive/2008/02/20/how-to-not-get-a-question-answered.aspx – Eric Lippert Oct 17 '09 at 23:47

1 Answers1

46

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.

Michael Petrotta
  • 59,888
  • 27
  • 145
  • 179
  • thanks a lot.. i half remember this happened to me as well with x86, but i'm not sure enough.. i'll check it out. – Letterman Oct 17 '09 at 22:59
  • 1
    Interestingly, this exception is not swallowed on my Windows 7 x64 machine when I run without debugging, but is swallowed when I do. – FacticiusVir Oct 17 '09 at 23:10
  • 1
    @FacticiusVir: Exactly the same here. On my Win7 x64 it is swallowed only when I'm in the VS debugging mode. – ulrichb Nov 12 '09 at 22:17
  • 2
    There is an API that allows you to fix this. See [my answer here](http://stackoverflow.com/a/11997142/119527) for how to use it in C#. – Jonathon Reinhart Aug 17 '12 at 00:10