Partager via

Visual Studio debugger fails to catch unhandled exception for a Windows Form or WPF Application?

  • Article

Ever begin debugging a Windows Form to have the form close suddenly without the debugger alerting you to the exception?  Or have you ever been stepping through the Form_Load event handler (or a method called by the Form_Load event handler) in a WPF application only to have it unexpectedly bring up the form instead of stepping to the next line?  If you have, chances are you were running an x64 version of Windows… “yes? ”, keep reading to learn why; “no?” you are encountering a different issue and please let us know about it through Microsoft Connect.

Why can’t the debugger catch/break on my unhandled exception on x64 versions of Windows?

The reason this happens on x64 versions of Windows is a design decision by the Windows operating system; x64 versions of Windows do not allow user mode exceptions to propagate post a kernel transition on the call stack.  What happens is when an exception is thrown in an application, it travels backward on the call stack until it either reaches an exception handler or the application’s “Main()” method.  If the exception reaches the application’s “Main()” method without being handled, the debugger recognizes that the exception went unhandled and breaks the application where the exception occurred.  As shown below, the Form_Load method causes a kernel transition, so when an exception thrown in a Form_Load method reaches the kernel frame on the callstack, the operating system catches the exception.  Since the exception is caught before it reaches the “Main()” method, from the debugger’s perspective the exception was caught—the debugger is unable to determine that the exception was caught by the operating system , not the user code.

image

How can I tell if this is my problem?

This problem can manifest itself in different ways depending on the type of exception.  Both Windows Forms, and WPF applications have exception handling code in the underlying framework that will catch certain types of exceptions (e.g. NullReferenceException), so in some cases your application will crash with an unhandled exception, in other cases the form will load and appear, however the Form_Load method (and all subsequent calls) will not have correctly run to completion.  There will however be a message in the “Output” window that “A first Chance exception of type ‘<exception type>’ occurred in <application’s name>”

image

Workaround

Unfortunately there isn’t a lot the debugger can do in this case since the operating system catches the exception (explained above).  The workaround in Visual Studio is to enable “First Chance” exceptions for the exception types that are being thrown in the Form_Load method.  To to this:

  1. Navigate to the “Debug” menu, and select “Exceptions”
  2. Check the “Thrown” box for the “Common Language Runtime Exceptions” row.  (Note:  You can expand the Exceptions using the “+” sign and only check the "Thrown” box for the desired exceptions")

image

Comments

  • Anonymous
    June 09, 2010
    The comment has been removed

  • Anonymous
    June 16, 2010
    This is a lousy solution. Now all handled exceptions cause the debugger to break too. We want a better solution!

  • Anonymous
    January 26, 2011
    How does this make the code fragile? There are times when you need to do this. If doSomething fails, you need to record that it happened <a href="www.aahgh.com/.../a>. In your mind, are you supposed to catch exceptions, then ignore them? That is much much worse.

  • Anonymous
    January 26, 2011
    If doSomething fails, you need to record that it happened [url=www.aahgh.com/.../the-colorectal-nutrition-connection-a-follow-up-by-hgh-pills-blog.html]HGH[/url] In your mind, are you supposed to catch exceptions, then ignore them? That is much much worse.

  • Anonymous
    May 26, 2011
    Excellent post, thanks alot.  I noticed that sometimes a NullReferenceException would not been seen running in Visual Studio (even in Release mode), but would appear when running as an EXE outside Visual Studio, and did not know why.  This post showed me how to set VS so it stops at the exception.  Since I am paranoid about catching all exceptions (except OutOfMemoryException), this is very helpful.  I am working on a 64-bit Vista machine, and will test it out later on a 32-bit Windows 7.

  • Anonymous
    June 16, 2011
    This option doesn't seem to be available, so it's still no solution to Express users.

  • Anonymous
    September 12, 2011
    Thanks alot for the post man! superb conclusion... well, microsoft should be ashamed on themself..

  • Anonymous
    October 03, 2011
    The comment has been removed

  • Anonymous
    July 30, 2012
    The comment has been removed

  • Anonymous
    February 11, 2013
    Just  started to learn about this, imo that option should be enabled by default and you can disable it if you want to...

  • Anonymous
    February 03, 2014
    this is not a workaround. a million exceptions might be caught before the unhandled one is thrown. you want us to step over every one? pathetic guys.

  • Anonymous
    February 17, 2014
    Thanks. Saved me from headache. I already wasted 2 hours until I found this.

  • Anonymous
    March 27, 2014
    Thank you so much for that article. You are really live safer.

  • Anonymous
    September 05, 2014
    Thank u so much, it's exactly what I want.

  • Anonymous
    November 02, 2014
    I prefer to put all code in another method instead 'Form_Load'; this new method do I call by method New() or externally before Form.Show is called.

  • Anonymous
    November 26, 2014
    I also encountered this problem, my solution for WPF was to create a custom alternative to the Load event that doesn't go through the kernel. It's called FullyLoaded and I have put it my Simpler.Net.Wpf libarary, see github.com/.../Simple.Net.Wpf.SimplerWindow in case its useful to anyone else. I believe the same principle can be applied to WebForms.

  • Anonymous
    April 06, 2015
    UPDATE: This issue has been fixed as of Windows 8.1.  You should not encounter this problem when debugging on newer versions of Windows

  • Anonymous
    April 07, 2015
    Andrew - I am currently running on Windows 7 with Visual Studio 2010.  Will these problems go away if I move to Visual Studio 2013?  Or do I absolutely have to upgrade to Windows 8.1 to see an improvement?

  • Anonymous
    May 16, 2015
    This is Fantastic!  The only version of Windows that handles this properly is a version where 90% of the users are MSFT employees.  They use it because they have no choice!  Even in mid 2015, XP has far more users than 8.1. MSFT should have fired Steve Balmer the day he was hired.   Ohhh.......   Too late.....

  • Anonymous
    June 09, 2015
    @Andrew, @tomh, I'm running Win 8.1 with VS 2013 and still getting VS closing without exceptions being caught.  Maybe this is a different issue, but your workaround came in handy for me anyway.

  • Anonymous
    July 20, 2015
    The comment has been removed

  • Anonymous
    August 10, 2015
    Windows 10, Visual Studio 2015, same thing. Still having problems with this.

  • Anonymous
    August 11, 2015
    Try/Catch does not work in C++ VS 2008, when compiled as Release (without optimizations). Big shame upon you, Microsoft.

  • Anonymous
    September 01, 2015
    I am facing a problem in my Visual Studio 2013. The designer mode of my Visual Studio 2013 is not working. An unhandled exception has occured. Please let me know how to fix it?

  • Anonymous
    September 15, 2015
    I'm facing a problem in my VS2012 and using opencv 2.4.6 in Windows 8.1 my error is: Unhandled exception at at 0x00007FFCF7EE8B9C in opencv6.exe: Microsoft C++ exception: cv::Exception at memory location 0x0000000FCA8EEFF0. however I;m suore that my code is true......