Hopefully, this will help me the next time I bang my head against the wall trying to figure out why an application of mine is going crazy, but none of my error-handling code seems to be working.
The core threads that explain this are here:
The simplest example is to create a new WinForm application and simply throw an exception from the OnLoad event. Not only will VS2008 not stop execution on that exception during debugging, but if you run it in "Release" mode, there will also be no trace of the exception.
In this case, your code (OnLoad) was ultimately called from something that executes in kernal-mode. When your exception propagates back up the stack, at the point it hits that boundary, the OS drops it. So execution then continues from the kernel-mode spot as if no exception was thrown---it acts as if the user-mode code had finished normally.
For me, since I don't currently know enough to say more, the simple solution is one of 2 things:
The core threads that explain this are here:
- Visual Studio doesn't break on unhandled exception with windows 64-bit
- The case of the disappearing OnLoad exception
- Silent exceptions on x64 development machines (Microsoft Connect)
The simplest example is to create a new WinForm application and simply throw an exception from the OnLoad event. Not only will VS2008 not stop execution on that exception during debugging, but if you run it in "Release" mode, there will also be no trace of the exception.
In this case, your code (OnLoad) was ultimately called from something that executes in kernal-mode. When your exception propagates back up the stack, at the point it hits that boundary, the OS drops it. So execution then continues from the kernel-mode spot as if no exception was thrown---it acts as if the user-mode code had finished normally.
For me, since I don't currently know enough to say more, the simple solution is one of 2 things:
- Put all of my initialization code in the object's constructor instead of OnLoad.
- Have a try...catch inside OnLoad (or any other similar "black holes") and have a reliable logging/reporting mechanism in the "catch".
Comments