4

Ive put my initialization code at form load, since it is not a good idea to leave it at the constructor because the designer can crash.

The problem is that Ive just realized that any exception inside the form load event will be catch internally!

Why? How should I overcome that?

    private void Form1_Load(object sender, EventArgs e)
    {
        //This exception will be catch internally (I don't know why and where)
        throw new Exception("test");
    }
Pedro77
  • 5,176
  • 7
  • 61
  • 91
  • possible duplicate of [VS2010 does not show unhandled exception message in a 64-bit WinForms Application](http://stackoverflow.com/questions/4933958/vs2010-does-not-show-unhandled-exception-message-in-a-64-bit-winforms-application) – Hans Passant Sep 28 '11 at 15:45
  • Yeah, Im using win 7 x64, but the solution is configured to x86. Can some one please test it at a x86 system? – Pedro77 Sep 28 '11 at 15:51
  • You're rigth. It is a bug and is explained here: http://blog.paulbetts.org/index.php/2010/07/20/the-case-of-the-disappearing-onload-exception-user-mode-callback-exceptions-in-x64/ – Pedro77 Sep 28 '11 at 16:02

1 Answers1

2

It is a bug and is explained here:

The case of the disappearing OnLoad exception – user-mode callback exceptions in x64

http://blog.paulbetts.org/index.php/2010/07/20/the-case-of-the-disappearing-onload-exception-user-mode-callback-exceptions-in-x64/

VS team answer: From here: https://connect.microsoft.com/VisualStudio/feedback/details/357311/silent-exceptions-on-x64-development-machines

Posted by Microsoft @ 22/04/2010 17:12 Hello,

This bug was closed as "External" because this behavior results from how x64 version of Windows handle exceptions. When a user mode exception crosses a kernel transition, x64 versions of Windows do not allow the exception to propagate. Therefore attached debuggers are unaware of the fact that an exception occurred resulting in the debugger failing to break on the unhandled exception.

Unfortunately where is nothing that the Visual Studio team can do to address this, it is the result of operating system design. All feedback regarding this issue should be addressed to the Windows team; however the Windows team considers this to be the "correct" operating system design, and considers the x86 behavior to be "incorrect".

Best Regards, Visual Studio Debugger

Solution that Im using: Ive put the code that was inside the form load to the constructor and I check if the app is running in designer or not

    protected static bool IsInDesigner
    {
        get { return (Assembly.GetEntryAssembly() == null); }
    }

     if (!MainForm.IsInDesigner)
          LoadControl();
Community
  • 1
  • 1
Pedro77
  • 5,176
  • 7
  • 61
  • 91
  • If you want to check if you are executing in the designer you can just check `LicenseManager.UsageMode` and `Componet.DesignMode` http://stackoverflow.com/a/2427444/80274 – Scott Chamberlain Jan 10 '14 at 21:33
  • Thanks, I think both checks works ok, but my version only needs on line of code. – Pedro77 Jan 10 '14 at 21:43