title: How can I get WinForms to stop silently ignoring unhandled exceptions?
body: <p>This is getting extremely irritating.  Right now I have a winforms application, and things were not working right, but no exceptions were being thrown as far as I could tell.  After stepping through almost all pieces of relevant code, it turns out that an exception was being thrown at the start of my application.  </p>
  
  <p>Long story short, in WinForms, being as awesome as it is, if an exception occurs the WinForms library ignores it.  No "an unhandled exception has occurred" JIT message is thrown, it just stops processing the current event and goes back to the GUI.  </p>
  
  <p>This is causing random bugs, because code to load data isn't being called due to the exception occurring prior to this data being loaded.</p>
  
  <p>To see this in action I created a brand new WinForms application, and entered the following code:</p>
  
  <pre><code>public partial class Form1 : Form
  {
      public Form1()
      {
          InitializeComponent();
      }
  
      private void Form1_Load(object sender, EventArgs e)
      {
          string blah = null;
          blah.Trim();
      }
  }
  </code></pre>
  
  <p>Press F5 and the form loads without any errors showing, even though a null reference is being thrown.</p>
  
  <p>I then tried to go to my <code>Program.cs</code> main method and add <code>Application.SetUnhandledExceptionMode(UnhandledExceptionMode.ThrowException);</code> to it.  Still my form loads without causing any errors to be thrown.</p>
  
  <p>Even though I know that I can tell VS to break on all exceptions, I find this situation really bad.  It causes really wierd issues that are hard to debug in production, and as this is an internal tool I really want to have it so it actually errors out when an exception occurs, and not silently disregards it.</p>
  
  <p>Does anyone know how to do this?</p>
  
  <p><hr>
  <b>Update:</b> Just to update on things I have learned from the comments.</p>
  
  <p>This does appear to be a 64-bit issue with windows, as I learned from <a href="https://stackoverflow.com/questions/4933958/vs2010-does-not-show-unhandled-exception-message-in-a-64-bit-winforms-application">this question</a> which I did not see before posting.  In that question it pointed to a <a href="https://connect.microsoft.com/VisualStudio/feedback/details/357311/silent-exceptions-on-x64-development-machines" rel="nofollow noreferrer">Microsoft bug report</a> about this, which had this to say:</p>
  
  <blockquote>
    <p>Hello,</p>
    
    <p>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 occured resulting in the debugger failing to break on the unhandled exception.</p>
    
    <p>Unfortunately where is nothing that the Visual Studo 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".</p>
    
    <p>Best Regards,
    Visual Studio Debugger</p>
  </blockquote>
  
  <p>That being said, builds not run through visual studio (or using Ctrl+F5 to run) does seem to show the JIT exception message box <em>EXCEPT</em> if you have the following code in your <code>Program.cs</code>:</p>
  
  <pre><code>Application.SetUnhandledExceptionMode(UnhandledExceptionMode.ThrowException);
  </code></pre>
  
  <p>That code will cause windows to ignore the exception.</p>
  
  <p>However, if you (instead) subscribe to the <code>Application.ThreadException</code> event, not only will your exceptions be caught, visual studio's debugger <em>will</em> break on unhandled exceptions!</p>