Let's give it another try with less overhead:
How to determine if an Exception is a CorruptedStateException?
From what I know there's no common superclass that all CorruptedStateExceptions inherit (exclusively) from and I found no other property/flag/attribute I could use to identify them.
For now the best I could come up is working in 2 steps: In below case ThirdPartyCall has the Attributes [HandleProcessCorruptedStateExceptions] and [SecurityCritical] set to catch CorruptedStateExceptions while ThirdPartyCallInternal doesn't. If ThirdPartyCallInternal catches an Exception it's no CSE, if only ThirdPartyCall catches it, it's one.
[HandleProcessCorruptedStateExceptions]
[SecurityCritical]
public static void ThirdPartyCall()
{
bool thrownExceptionIsCorruptedState = true;
try
{
ThirdPartyCallInternal(ref thrownExceptionIsCorruptedState);
}
catch (Exception ex)
{
if (thrownExceptionIsCorruptedState)
{
//This is pretty much the only thing we'd like to do...
log.Fatal("CorruptedStateException was thrown",ex);
}
throw;
}
}
private static void ThirdPartyCallInternal(ref bool thrownExceptionIsCorruptedState)
{
try
{
ThirdPartyLibrary.DoWork();
}
catch (Exception)
{
//Exception was caught without HandleProcessCorruptedStateExceptions => it's not a corruptedStateException
thrownExceptionIsCorruptedState = false;
throw;
}
}
Is there any other (cleaner, easier,...) way to determine if an Exception is a CorruptedStateException that will bring the Application down?
Maybe there's a misunderstanding: "corrupted state" is more a flag on any other type of exception than an exception on its own. Therefore your statement
is incorrect. There is no exception of type CorruptedStateException thrown. The real exception type could e.g. be AccessViolationException and you should look into the reason of that.
Therefore I think it's not important that an Exception is a corrupted state exception or not. It's important that your application actually catches the exception, you get notified about it and you can fix it.
Doing so simplifies your code to
Besides that, maybe it's better to let the operating system handle this crash rather than trying to write something into a log file. Note that log4net may also have been destroyed already and writing to the log file is not possible any more.
Instead, register for Windows Error Reporting, get the crash dumps from Microsoft and analyze those.