CSEs error reporting

lukasz

Hi,

Since .NET 4.0 Corrupted State Exceptions like AccessViolationException cannot be caught/handled unless explicitly marking the handler method with [HandleProcessCorruptedStateExceptions, SecurityCritical] attributes. The error reporting handler injected by SA doesn't seem to have this enabled, so it never receives any CSEs. They kill the application without getting reported by SA.

This is currently a big problem for our SA-obfuscated application. Not only are we not getting notified when errors happen on end user machines, but even once we debug the only thing we can get is an obfuscated stack trace. I know we can manually decode a trace if ASCII naming is used during obfuscation (not ideal), but even this way we can only extract stack frame headers, without the additional information normally contained in full SA reports (the variable/field values etc).

We've tried a number of workarounds

* Switching the whole app to legacy CSE policy with <legacyCorruptedStateExceptionsPolicy enabled="true"/> in app.config - SA still doesn't catch & report the error.

* Manually catching CSEs in our code, then throwing a regular exception with the CSE wrapped as InnerException - this lets SA catch it and we do get a report, but the inner trace isn't decoded when we view it in SA.

I know the problem was already reported a few years ago, and a development issue was created (SA-1096), as per the discussion here: https://forum.red-gate.com/discussion/14008/error-reporting-not-working-with-accessviolationexception

Browsing through SA release notes since then and the current documentation, I can't see any trace of this having been resolved.

So the question is: can SA currently report Corrupted State Exceptions? Is there an option I need to use to enable it? Am I missing something else?

Thanks,
Lukasz

Jessica R

Hi Lukasz,

The request logged as SA-1096 hasn't been resolved yet so there still isn't a built-in way to avoid this .NET behavior, I'm really sorry to say.

If I'm understanding correctly though, in order for a CSE to be caught/handled, then the [HandleProcessCorruptedStateExceptions, SecurityCritical] attribute needs to be added to the method that calls the try/catch block for the exception..

As SmartAssembly adds try/catch blocks within each of your methods, I think it should work if you just add [HandleProcessCorruptedStateExceptions, SecurityCritical] to your code to any method that you think may cause a CSE.

I made a quick test with a method that triggers an AccessViolationException and I do get an error report dialog after decorating the method with [HandleProcessCorruptedStateExceptions, SecurityCritical]- have you already tried this though with no luck?