Is it possible to catch an access violation exception in .NET?

Is there anything I can do to catch an AccessViolationExc开发者_开发百科eption? It is being thrown by a unmanaged DLL that I don't control.

---

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 it¹.

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.

¹_{This 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 legacyCorruptedState­­ExceptionsPolicy=true to the app.config. Further details in the articled linked above.}

---

As others pointed out, you shouldn't "handle" this condition, but during development it is handy to catch this for the sake of troubleshooting.

You can mark your managed method with the System.Runtime.ExceptionServices.HandleProcessCorruptedStateExceptions attribute:

[HandleProcessCorruptedStateExceptions]
public void MyMethod()
{
    try
    {
        NaughtyCall();
    }
    catch (AccessViolationException e)
    {
        // You should really terminate your application here
    }
}

---

Yes.

In your App.confg, plop the following code within the <configuration> tag:

<runtime>
    <legacyCorruptedStateExceptionsPolicy enabled="true"/>
</runtime>

Now you should be able to catch corrupted state exceptions (CSE) like any other.

Note: If you already have a runtime tag then simply add <legacyCorruptedStateExceptionsPolicy enabled="true"/> to it

The above works for .Net 4.5

---

First of all I fully ack with 0xA3. But if there is no way out you can wrap the dirty unmanaged dll in its own process and transfer data via IPC (TCP/IP, namedpipes, etc.). Catch all exceptions and inform the host-process. So your host-process is mostly save from memory corruption.

---

you can wrap the call to the unmanaged DLL with a try-catch block. AccessViolationExceptions can be caught normally. Executing the following code shows both messages:

try
{
    throw new AccessViolationException();
}
catch (Exception e)
{
    MessageBox.Show(e.Message + e.StackTrace, e.Message, MessageBoxButtons.OK, MessageBoxIcons.Error);
}
MessageBox.Show("Still running..");

Edit: .NET 4 introduced a change in behavior, it is no longer possible to catch corrupted state exceptions unless you specifically "ask" the runtime to do so.