C
Christopher Bohn
This refers to KB article #836674
(http://support.microsoft.com/?kbid=836674). I encountered the bug
described in that article, but neither of the workarounds are entirely
satisfactory.
The first workaround, creating the App.config file, only seems to work
when making a debug build.
The second workaround solves the problem, but the process of re-throwing
the exception causes the stack trace contained in the exception to be
reset. The result is that when the exception is finally caught, the
stack trace shows the call stack at the point where the
ThreadExceptionEventHandler re-threw it, instead of where the exception
was originally thrown.
So, is there any way around this? Can I somehow throw the exception
without having its stack trace altered? I don't want to change the code
that eventually catches the exception to deal with this, I would like to
simply get the behavior as it should be if this bug didn't exist at all.
(http://support.microsoft.com/?kbid=836674). I encountered the bug
described in that article, but neither of the workarounds are entirely
satisfactory.
The first workaround, creating the App.config file, only seems to work
when making a debug build.
The second workaround solves the problem, but the process of re-throwing
the exception causes the stack trace contained in the exception to be
reset. The result is that when the exception is finally caught, the
stack trace shows the call stack at the point where the
ThreadExceptionEventHandler re-threw it, instead of where the exception
was originally thrown.
So, is there any way around this? Can I somehow throw the exception
without having its stack trace altered? I don't want to change the code
that eventually catches the exception to deal with this, I would like to
simply get the behavior as it should be if this bug didn't exist at all.