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


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 (25)

  1. Karel Kral says:

    It's a Microsoft shame. This nasty bug have annoyed us several years and ve hoped that it will be solver in VS 2010. But it is NOT! Very disappointing. Why can't Visual Studio team and Operating systems team cooperate together?

    Proposed "solution" is not solution for us. When debugger is set to  “Thrown”, it stops on every exception. Which means I must go through tons of correct exceptions before catching the correct one.

    Yes I can uncheck undesired exceptions in this dialog box above. But when I uncheck "Thrown", my selection is lost. At least, something as "Save selection to file" would be nice in Exceptions dialog.

  2. Marc K says:

    This is a lousy solution. Now all handled exceptions cause the debugger to break too.

    We want a better solution!

  3. Max says:

    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="http://www.aahgh.com/…/a&gt;.

    In your mind, are you supposed to catch exceptions, then ignore them? That is much much worse.

  4. Max says:

    If doSomething fails, you need to record that it happened [url=http://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.

  5. Keith says:

    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.

  6. What about VS Express says:

    This option doesn't seem to be available, so it's still no solution to Express users.

  7. Altamash Shaikh. says:

    Thanks alot for the post man!

    superb conclusion…

    well, microsoft should be ashamed on themself..

  8. Can Microsoft have something like 'Form_PreLoad' event and we can write all our Things which do not relate to Components attributes in the 'Form_PreLoad' and we can also have an e.CancelFormLoad as a return value in this event so that the Form doesn't load at all if we set it to true.

    And best of all it should  allow handling of  Exceptions just as all other Procedures do, except of course the Form_Load event, which we can use to set the components on the form attributes…

    Can Microsoft guys do that … and do they see these comments. If not can you pass this to them. Sometimes even a small thing might work , even if it means from now onwards.

    Regards

  9. Vikesh says:

    Thanks for the solution. It helped me to get to the root of the problem. I was trying to access database and fetching the result of the query I wanted from it. Every time I wanted to execute it, it threw an exception which didn't even got caught by the try catch block. It gave me the error:

    INTERNAL ERROR:

    Unhandled exception in Debugger::HandleIPCEvent.

    Event ID=0x246. Exception code=0xc0000005, Eip=0x6a566899.

    Process ID=0x8d0(2256), Thread ID=0xa90 (2704)

    It even closed the Visual studio after a few tries saying something rubbish.

    Then after 3 hours of searching, I found this page. When I turned on the Common Language Run Time Exceptions, I got the error was in the query. And it was:

    SELCET * FROM users;

    Where it was a typo in spelling the "SELECT" word.

    Thanks for this, other wise I could have screwed the whole project by now and starting again from the scratch..

  10. Newbie says:

    Just  started to learn about this, imo that option should be enabled by default and you can disable it if you want to…

  11. spongman says:

    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.

  12. guest says:

    Thanks. Saved me from headache. I already wasted 2 hours until I found this.

  13. Matt says:

    Thank you so much for that article.

    You are really live safer.

  14. Thế Anh says:

    Thank u so much, it's exactly what I want.

  15. Ldaniel says:

    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.

  16. Modus Operandi says:

    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.

  17. UPDATE: This issue has been fixed as of Windows 8.1.  You should not encounter this problem when debugging on newer versions of Windows

  18. tomh says:

    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?

  19. LS says:

    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…..

  20. Steve says:

    @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.

  21. Rose says:

    It still doesn't work.I took  a long time to try another solutions but it doesn't applied.I cant resolve that exceptions in  VS  2010..  !

  22. Christoph says:

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

  23. Bob says:

    Try/Catch does not work in C++ VS 2008, when compiled as Release (without optimizations).

    Big shame upon you, Microsoft.

  24. Saif Alam says:

    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?

  25. Farnaz says:

    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……