This site uses cookies to deliver our services and to show you relevant ads and job listings.
By using our site, you acknowledge that you have read and understand our Cookie Policy, Privacy Policy, and our Terms of Service.
Your use of Stack Overflow’s Products and Services, including the Stack Overflow Network, is subject to these policies and terms.

Join us in building a kind, collaborative learning community via our updated
Code of Conduct.

I would expect that VS breaks and shows an unhandled exception message at the second line. However, what happens is that the third line is just skipped without any message and the application keeps running.

I don't have this problem with my existing C# projects. So I guess that my new projects are created with some strange default settings.

Does anyone have an idea what's wrong with my project???

I tried checking the boxes in Debug->Exceptions. But then executions breaks even if I handle the exception in a try-catch block; which is also not what I want. If I remember correctly, there was a column called "unhandled exceptions" or something like this in this dialog box, which would do excatly what I want. But in my projects there is only one column ("Thrown").

5 Answers
5

This is a nasty problem induced by the wow64 emulation layer that allows 32-bit code to run on the 64-bit version of Windows 7. It swallows exceptions in the code that runs in response to a notification generated by the 64-bit window manager, like the Load event. Preventing the debugger from seeing it and stepping in. This problem is hard to fix, the Windows and DevDiv groups at Microsoft are pointing fingers back and forth. DevDiv can't do anything about it, Windows thinks it is the correct and documented behavior, mysterious as that sounds.

It is certainly documented but just about nobody understands the consequences or thinks it is reasonable behavior. Especially not when the window procedure is hidden from view of course, like it is in any project that uses wrapper classes to hide the window plumbing. Like any Winforms, WPF or MFC app. Underlying issue is Microsoft could not figure out how to flow exceptions from 32-bit code back to the 64-bit code that triggered the notification back to 32-bit code that tries to handle or debug the exception.

It is only a problem with a debugger attached, your code will bomb as usual without one.

Project > Properties > Build tab > Platform target = AnyCPU and untick Prefer 32-bit. Your app will now run as a 64-bit process, eliminating the wow64 failure mode. Some consequences, it disables Edit + Continue for VS versions prior to VS2013 and might not always be possible when you have a dependency on 32-bit code.

Other possible workarounds:

Debug > Exceptions > tick the Thrown box for CLR exceptions to force the debugger to stop at the line of code that throws the exception.

Write try/catch in the Load event handler and failfast in the catch block.

Use Application.SetUnhandledExceptionMode(UnhandledExceptionMode.CatchException) in the Main() method so that the exception trap in the message loop isn't disabled in debug mode. This however makes all unhandled exceptions hard to debug, the ThreadException event is pretty useless.

Consider if your code really belongs in the Load event handler. It is very rare to need it, it is however very popular in VB.NET and a swan song because it is the default event and a double-click trivially adds the event handler. You only ever really need Load when you are interested in the actual window size after user preferences and autoscaling is applied. Everything else belongs in the constructor.

I have checked this same bug exists on a Winforms application, on the OnFormClosed event. And I cannot solve it changing the app target to x86 also. But at least I have a problem explanation.
– ferpegaSep 17 '11 at 9:21

1

Another workaround seems to be Application.ThreadException. Setting it seems to help - the exceptions are triggered in the IDE and by the debugger.
– tanasciusJun 18 '12 at 14:58

7

Windows 8 do have this problem. Just FYI.
– ThunderGrOct 1 '13 at 5:58

Set/GetProcessUserModeExceptionPolicy are still not documented on MSDN, and Kernel32.dll of Windows 8 does not export them.
– MartinMay 2 '13 at 12:33

Isn't there a way to do the same thing by editing the registry or something?
– ThunderGrOct 1 '13 at 6:01

1

I have read them. I also read the comment that windows 8 kernel do not export these methods. I happen to run on windows 8. I was just asking, just in case.
– ThunderGrOct 1 '13 at 6:27

1

If you apply the hotfix you point to, you can solve the problem by editing the registry, as they describe, instead of using the methods. I remember having solved that problem on a Win7 machine, this way, before. Unfortunately, you cannot do that in Win 8.
– ThunderGrOct 1 '13 at 6:42

I'm using WPF and ran into this same problem. I had tried Hans 1-3 suggestions already, but didn't like them because studio wouldn't stop at where the error was (so I couldn't view my variables and see what was the problem).

So I tried Hans' 4th suggestion. I was suprised at how much of my code could be moved to the MainWindow constructor without any issue. Not sure why I got in the habit of putting so much logic in the Load event, but apparently much of it can be done in the ctor.

However, this had the same problem as 1-3. Errors that occur during the ctor for WPF get wrapped into a generic Xaml exception. (an inner exception has the real error, but again I wanted studio to just break at the actual trouble spot).

What ended up working for me was to create a thread, sleep 50ms, dispatch back to main thread and do what I need...