none
Visual Studio doesn't break on unhandled exception with windows 64-bit

    Question

  • From connect.microsoft.com :
    Steps to reproduce problem:
    1) Create a blank WinForms application in Visual Studio 2008 (any version)
    2) Double-click on the blank form to view the Form1_Load method
    3) Insert code that would throw an exception, for example: throw new Exception();
    4) Click the "debug" button.
    The exception is not reported to the user. If there is any code after the exception is it skipped, and the program continues to run.

    This bug has been known since July 2008, does anybody have a fix available or any information about when a fix will be available? Or will this issue at least be fixed in VS 2010? This bug is very disruptive on productivity causing tracing of bugs to be hard.
    Friday, October 09, 2009 7:09 AM

Answers

All replies

  • You should follow the workaround as outlined in the connect bug:

    Hi,

    This is a known bug with x64 versions of Windows and the way exceptions are handled. One way to work around this issue while debugging is to go to the Debug -> Exceptions and select 'Thrown' for for the exception types you are interested in. This will stop the debugger when the exception is first hit (and before Windows eats it up).

    Thanks,
    Visual Studio Debugger Team
    • Marked as answer by rchiodo - MSFTModerator Saturday, October 10, 2009 12:14 AM
    • Unmarked as answer by Pawaw Monday, October 12, 2009 9:26 AM
    Saturday, October 10, 2009 12:14 AM
    Moderator
  • Thanks for your answer which is highly appreciated.

    The workaround you mention is not too helpful as most of the time it is unknown which sort of exception is being thrown thus you must setup the VS to break on all clr exceptions causing the debuging session to break very often on handled and unrelated exceptions.

    I am aware of the other workaround (Start without debugging -> System.Diagnostics.Debugger.Break() -> Attach process to debugger) and am using it where possible, however the workaround causes the runtime to stall when debuging a project where many assemblies are involved (prism - wpf ui). Not too mention that the workaround does not help on productivity having to attach to the debugger process whenever wanting to run my project.

    Please forgive that I have allowed myself to unmark your reply as an answer as it does not answer my question, which was when a fix will be available? (if at all?) and if this bug is fixed in VS2010? We are unfortunately seriously considering going back to windows x86 because of this problem as it impacts our productivity.
    Monday, October 12, 2009 9:26 AM
  • Any word on how far into the future we should expect to see this fixed? I agree that the workarounds are far from acceptable in a real world scenario.

    Tuesday, October 13, 2009 6:04 AM
  • Hello,

    I am sorry that the bug has not been fixed yet. I have tested it in both Vista x64 and Windows 7 x64 with VS 2008 and VS 2010.

    This bug is not as easy to fix as it looks like. It requires changes in both OS and CLR. Product group will balance resources and user impaction before they fix a bug. I think that's why the bug fix is posponed.

    The best channel for users to tell product group how important of a bug is to vote at the connect site. The vote data will be one important factor for PG to make a decision to fix a bug.

    I still can't answer when the issue will be fixed right now. I will appreciate if you can understand that we are trying to fix most important bugs and your vote will help us to make the decision. Thanks.
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.
    Tuesday, October 13, 2009 4:41 PM
    Moderator
  • Like Hongye said, we can't comment on the availability of a fix. Your best bet is to vote for the connect bug.

    • Marked as answer by rchiodo - MSFTModerator Tuesday, October 13, 2009 5:45 PM
    • Unmarked as answer by Pawaw Wednesday, July 28, 2010 11:20 AM
    Tuesday, October 13, 2009 5:45 PM
    Moderator
  • You can also open a new connect bug. That will give you direct feedback on whether or not they will be fixing this issue.
    Tuesday, October 13, 2009 5:47 PM
    Moderator
  • Thank you for your replies. Although this doesn't fix the bug (which looks like a nasty one), it puts me at ease to understand the process and know that it has been flagged. I have cast my vote on the connect link you provided. Many thanks again for the responses and look forward to the fix.
    Tuesday, October 13, 2009 11:15 PM
  • Ok, thanks for your responses, I have also voted on the connect site. I suppose we will be transitioning back to 32-bit windows as this bug is affecting our productivity too much.
    Wednesday, October 14, 2009 6:29 AM
  • Your best bet is to vote for the connect bug.

    Would that help? I see the status of the bug on connect is "Closed", I would assume that means nobody on the visual studio debugger team is monitoring this.
    Wednesday, October 14, 2009 11:20 AM
  • I just ran into this myself. Yes it's extremely frustrating. One VERY important point is that this issue is only on exceptions raised during the Forms.OnLoad event handler (or methods called from within this event handling).

    While workarounds are incredibly irritating, i currently do the following:

    Create a button somewhere on the form labeled "OnLoad", move all my onLoad logic to this button, and during normal debugging/testing phases of design I just click the button to simulate the onLoad of my software. I have to remember to remove button/move logic during release builds but at least I can catch unhandled exceptions again.
    Monday, October 26, 2009 9:47 AM
  • wow! My app was acting extremely strange and luckily I managed to pinpoint this bug!! geesh what a nightmare it would have been otherwise! Also thanks PsharkAuburn for mentioning it only takes place in the OnLoad event or in function calls that originate from the OnLoad event.


    -Gideon MCTS:Windows Development and C# geek.
    Friday, November 27, 2009 5:40 AM
  • Agreed! I just wasted a day on trying to figure this one out.  I wanted to vote on this bug, but like Pawaw said, the thread is closed. This is frustrating.

     

    Justin

    Thursday, April 22, 2010 1:37 AM
  • Unfortunately for developers the Windows team considers this to be "By Design", they actually consider the fact that it works on x86 to be a bug.  Votes for the Connect bugs mentioned go to Visual Studio and the CLR who are powerless to address the issue.  Feedback regarding this should be directed to Windows, although it does not appear that they intend to modify the behavior from how it has been designed for x64


    Best Regards, Andrew Hall. Visual Studio Debugger.
    Friday, April 23, 2010 12:01 AM
    Moderator
  • Andrew, can you elaborate on why this behaiour is considered "by design" by the windows team?

    I guess i will stay on 32 bit windows forever.... not great.

     

    EDIT

    I saw the reasons the windows team consider it "by design" on the connect thread:

    QUOTE

    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.

    UNQUOTE

    Friday, April 23, 2010 7:03 AM
  • To be clear, this only occurs when you cross a kernel frame in the callstack.  The most common case of this is in Form Load events, most other events such as button handlers do not suffer from this behavior since these events do not require crossing a kernel frame.
    Best Regards, Andrew Hall. Visual Studio Debugger.
    Friday, April 23, 2010 8:20 PM
    Moderator
  • Hi guys - please see my blog post on this topic that describes a recent Windows Hotfix for this issue:

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

    http://support.microsoft.com/kb/976038  is the hotfix that will solve this problem for the impatient, but I really encourage you to read the blog post

    • Marked as answer by Pawaw Wednesday, July 28, 2010 11:20 AM
    Tuesday, July 27, 2010 8:58 PM
  • Hi guys - please see my blog post on this topic that describes a recent Windows Hotfix for this issue:

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

    http://support.microsoft.com/kb/976038  is the hotfix that will solve this problem for the impatient, but I really encourage you to read the blog post


    Great!!! Thank you so much Paul, I had given up on this.... :D
    Wednesday, July 28, 2010 11:21 AM
  • The hotfix is not working for me in even simple scenarios, am I doing anything wrong?

    Tuesday, August 31, 2010 6:58 AM
  • The hotfix only works for me on x86 applications, and in that scenario the debugger still isn't actually breaking, instead the application just crashes (which is certainly better than the silent exception I was receiving before). On an x64 application though, the exception is still silent, regardless of the hotfix or applying a "Win7 compatible" manifest for the application, as recommended by Paul C Betts above.

    Form.Load event handler is not the only one that exhibits this behaviour, I've replicated the issue on ComboBox.SelectedIndexChanged and ListView.SelectedIndexChanged.

    If I use the Kernel32.dll function "SetProcessUserModeExceptionPolicy", my x64 application will close without random message and VS2010 will skip to the code line throwing the exception.

    So, this is what I have thus far deduced:

    1. I need the 976038 hot-fix, or Win7 SP1.
    2. The "system level" registry setting for enabling it in "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options" is only effective for x86 applications, so I can probably ignore that.
    3. Including a "Windows 7 compatible" application manifest, as suggested by Paul Betts in his linked blog above appears to do nothing for this, so I can probably ignore that one too.
    4. A call to Kernel32.dll "GetProcessUserModeExceptionPolicy" within my application works, but instead of the debugger properly breaking on the exception, will just cause the application to crash (which as at least better than the silent exceptions I was getting before).

    To my reckoning, this is a convoluted work-around, and the issue itself still isn't fixed, since the VS2010 debugger still will not break on these exceptions.

    In the 3+ years since this issue was reported here:
    https://connect.microsoft.com/VisualStudio/feedback/details/357311/silent-exceptions-on-x64-development-machines#details

    and the nearly 5 years since the release of Vista saw mainstream desktop Windows x64 usage, is this still the best solution we have?

     

     

    Sunday, October 23, 2011 11:33 PM
  • It seems MS doesn't want us to program on Win7, eh?  If this is not a serious issue, I don't know which one can be. 
    Reed
    Friday, November 25, 2011 3:55 AM
  • Glad I'm not the only one still wrestling with this one Reed. Honestly, being able to see application exceptions and errors has got to be my number 1 requirement for a development environment. I'm stunned that this hasn't been taken more seriously and is still, as far as I can tell, an outstanding issue.

    I got some great help from Mike over in a thread I started on the issue recently - http://social.msdn.microsoft.com/Forums/en-US/vsdebug/thread/8a7006a1-ad86-4aec-9604-d7ccf99ce00b/#6c602710-3ccf-4178-bae8-61e638414a0e

    But now that it's gone out of his hands, everything is quiet again.

    Friday, November 25, 2011 4:10 AM
  • I do not believe in disregard of Microsoft.
    The only advantage of the free liguagens on Dot Net, like Java, is to havethe basis for a company that takes users directly from your tool for

    but if Microsoft does not care for developers, I think this advantage no longer exists.
    Saturday, January 28, 2012 2:41 AM
  • For me it does work on Windows7 x64 sp1 and VS2010 sp1, please download and install ALL the hotfix from windows updates, then read carefully and follow the instructions on http://support.microsoft.com/kb/976038, especially:

    To enable this hotfix at the system level, follow these steps:

    1. In Registry Editor, locate the following registry subkey:
      HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options
    2. Create a registry entry of the DWORD value.
    3. Name the new registry entry DisableUserModeCallbackFilter.
    4. Set the value of the DisableUserModeCallbackFilter registry entry to 1.

     


    • Edited by Zekok Wednesday, February 01, 2012 8:33 AM
    Wednesday, February 01, 2012 8:16 AM