Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>If you're on a 64-bit OS, there's a pretty good chance you're being bitten by an OS-level behavior that causes exceptions to disappear. The most reliable way to reproduce it is to make a new WinForm application that simply throws an exception in OnLoad; it will appear to not get thrown. Take a look at these:</p> <ol> <li>Visual Studio doesn't break on unhandled exception with windows 64-bit <ul> <li>http: // social.msdn.microsoft.com/Forums/en/vsdebug/thread/69a0b831-7782-4bd9-b910-25c85f18bceb</li> </ul></li> <li><a href="http://blog.paulbetts.org/index.php/2010/07/20/the-case-of-the-disappearing-onload-exception-user-mode-callback-exceptions-in-x64/" rel="noreferrer">The case of the disappearing OnLoad exception</a> </li> <li>Silent exceptions on x64 development machines (Microsoft Connect) <ul> <li>https: // connect.microsoft.com/VisualStudio/feedback/details/357311/silent-exceptions-on-x64-development-machines</li> </ul></li> </ol> <p>The first is what I found from Google (after this thread didn't help), and that thread led me to the following two. The second has the best explanation, and the third is the Microsoft bug/ticket (that re-affirms that this is "by design" behavior).</p> <p>So, basically, if your application throws an Exception that hits a kernel-mode boundary on its way back up the stack, it gets blocked at that boundary. And the Windows team decided the best way to deal with it was to pretend the exception was handled; execution continues as if everything completed normally.</p> <p>Oh, and this happens <em>everywhere</em>. Debug versus Release is irrelevant. .Net vs C++ is irrelevant. This is OS-level behavior. </p> <p>Imagine you have to write some critical data to disk, but it fails on the wrong side of a kernal-mode boundary. Other code tries to use it later and, if you're lucky, you detect something's wrong with the data ...but why? I bet you never consider that your application failed to write the data---because you expected an exception would be thrown.</p> <p>Jerks.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload