I have a .Net application I am targetting both .Net framework 4.0 and .Net core 2.0, I have to call some pkcs11 driver using pkcs11interop library due to some driver issue I am getting AccessViolation Exception in .net framework 4.0 I was able to handle with attribute [HandleProcessCorruptedStateExceptions]
on the method but this will not work in .Net core 2.0 how can I handle in .Net core 2.0

- 507
- 5
- 25
-
Setting environment variable "COMPlus_legacyCorruptedStateExceptionsPolicy" to "1" should help even in .NET Core. For example with `Environment.SetEnvironmentVariable("COMPlus_legacyCorruptedStateExceptionsPolicy", "1");`, or before starting application. Though doing anything else except logging and exiting process after this exception is not a good idea. – Evk Mar 19 '18 at 07:26
-
I tried adding this line in `Environment.SetEnvironmentVariable("COMPlus_legacyCorruptedStateExceptionsPolicy", "1");` program.cs main() but it did not catch the exception. – Prashanth Mar 19 '18 at 07:45
-
Maybe it's too late to do that when application has already started. Try to set this environment variable before starting. – Evk Mar 19 '18 at 07:47
-
My application is a self-hosted app which runs on the client side and I am giving it SCD deployment how can I handle this. – Prashanth Mar 19 '18 at 07:50
-
Well just set environment variable with a way appropriate to operating system you run it on, then do `dotnet YourApp.dll` or however you start your application. – Evk Mar 19 '18 at 07:52
-
I have updated the question. – Prashanth Mar 19 '18 at 09:23
-
Access violations generally come from doing something wrong in unmanaged memory. As with most unexpected exceptions, you shouldn't try to _catch_ it, you should look into what you're doing wrong, and _prevent or fix_ it. – Nyerguds Mar 19 '18 at 09:49
-
I'm also, My application is a self-hosted app which runs on the client side , did you solved this issue ? – shine Oct 22 '18 at 18:11
-
May be you can add a C++ wrapper to call the external C++ dll Method and handle the external C++ dll's Exception then PInvoke the C++ Wrapper dll method to avoid AccessViolationException ? – shine Oct 23 '18 at 11:17
2 Answers
Please note the following:
You shouldn't. An access violation is a serious problem: it is an unexpected attempt to write to (or read from) an invalid memory address. As John already clarified, the unmanaged DLL might already have corrupted the process memory before the access violation has been raised. This can have unpredicted effects on any part of the current process.
The safest thing to do is to possibly inform the user and then immediately exit.
Some more details: An access violation is an OS exception (a so-called SEH or structured exception handling exception). This is a different kind of exception than the managed CLR exceptions from
System.Exception
. You will rarely see SEH exceptions in purely managed code, but if one occurs, e.g. in unmanaged code, the CLR will deliver it to managed code where you are also able to catch it1.However, catching SEH exceptions is mostly not a good idea. Further details are explained in the article Handling Corrupted State Exceptions in MSDN magazine where the following text it taken from:
The CLR has always delivered SEH exceptions to managed code using the same mechanisms as exceptions raised by the program itself. This isn't a problem as long as code doesn't attempt to handle exceptional conditions that it cannot reasonably handle. Most programs cannot safely continue execution after an access violation. Unfortunately, the CLR's exception handling model has always encouraged users to catch these serious errors by allowing programs to catch any exception at the top of the System.Exception hierarchy. But this is rarely the right thing to do.
1This was true until .NET 3.5. In .NET 4 the behavior has been changed. If you still want to be able to catch such kind of exceptions you would have to add legacyCorruptedStateExceptionsPolicy=true
to the app.config. Further details in the articled linked above.
That said, there is a nice question and answer here regarding the matter which might suit your case as well.
There is a difference in handling corrupted state exception in .Net Core.
Please refer to this article that is concerning error handling in .Net Core, which uses a middleware (which is what I prefer while using extension methods to suit your needs).

- 10,636
- 1
- 28
- 46
If a CSE is possible, you will hard crash. Dark times ahead.
In chronological order...
dotnet/coreclr Issue #9045: Strip corrupted state exceptions handling
dotnet/coreclr PR #10957: Do not honor attribute HandleProcessCorruptedStateExceptions
dotnet/coreclr Issue #19192: Unable to catch in managed code any user exception thrown from native Linux code
SOL currently. Have to create an unmanaged wrapper of sorts to catch external CSEs.

- 3,737
- 16
- 29