AccessViolationException을 처리하는 방법

AccessViolationException을 처리하는 방법

---

내 .net 응용 프로그램에서 COM 개체 (MODI)를 사용하고 있습니다. 내가 호출하는 메서드는 Visual Studio에서 가로채는 System.AccessViolationException을 발생시킵니다. 이상한 점은 AccessViolationException, COMException 및 기타 모든 것에 대한 핸들러가있는 try catch로 호출을 래핑했지만 Visual Studio (2010)가 AccessViolationException을 인터셉트하면 디버거가 메소드 호출 (doc.OCR)에서 중단됩니다. 단계별로 진행하면 catch 블록에 들어 가지 않고 다음 줄로 계속 진행합니다. 또한 Visual Studio 외부에서 이것을 실행하면 응용 프로그램이 중단됩니다. COM 개체 내에서 발생하는이 예외를 어떻게 처리 할 수 ​​있습니까?

MODI.Document doc = new MODI.Document();
try
{
    doc.Create(sFileName);
    try
    {
        doc.OCR(MODI.MiLANGUAGES.miLANG_ENGLISH, false, false);
        sText = doc.Images[0].Layout.Text;
    }
    catch (System.AccessViolationException ex)
    {
        //MODI seems to get access violations for some reason, but is still able to return the OCR text.
        sText = doc.Images[0].Layout.Text;
    }
    catch (System.Runtime.InteropServices.COMException ex)
    {
        //if no text exists, the engine throws an exception.
        sText = "";
    }
    catch
    {
        sText = "";
    }

    if (sText != null)
    {
        sText = sText.Trim();
    }
}
finally
{
    doc.Close(false);

    //Cleanup routine, this is how we are able to delete files used by MODI.
    System.Runtime.InteropServices.Marshal.FinalReleaseComObject(doc);
    doc = null;
    GC.WaitForPendingFinalizers();
    GC.Collect();
    GC.WaitForPendingFinalizers();

}

---

.NET 4.0에서 런타임은 Windows SEH (Structured Error Handling) 오류로 발생한 특정 예외를 손상된 상태 표시기로 처리합니다. 이러한 손상된 상태 예외 (CSE)는 표준 관리 코드에서 잡을 수 없습니다. 나는 왜 또는 어떻게 여기에 들어 가지 않을 것입니다. .NET 4.0 프레임 워크에서 CSE에 대한이 기사를 읽으십시오.

http://msdn.microsoft.com/en-us/magazine/dd419661.aspx#id0070035

그러나 희망이 있습니다. 이 문제를 해결하는 몇 가지 방법이 있습니다.

1. .NET 3.5 어셈블리로 다시 컴파일하고 .NET 4.0에서 실행하십시오.

2. configuration / runtime 요소 아래에서 응용 프로그램의 구성 파일 행을 추가하십시오. <legacyCorruptedStateExceptionsPolicy enabled="true|false"/>

3. 이러한 예외를 포착하려는 메소드를 HandleProcessCorruptedStateExceptions속성으로 장식하십시오 . 자세한 내용은 http://msdn.microsoft.com/en-us/magazine/dd419661.aspx#id0070035 를 참조하십시오.

---

편집하다

Previously, I referenced a forum post for additional details. But since Microsoft Connect has been retired, here are the additional details in case you're interested:

From Gaurav Khanna, a developer from the Microsoft CLR Team

This behaviour is by design due to a feature of CLR 4.0 called Corrupted State Exceptions. Simply put, managed code shouldnt make an attempt to catch exceptions that indicate corrupted process state and AV is one of them.

He then goes on to reference the documentation on the HandleProcessCorruptedStateExceptionsAttribute and the above article. Suffice to say, it's definitely worth a read if you're considering catching these types of exceptions.

---

Add the following in the config file, and it will be caught in try catch block. Word of caution... try to avoid this situation, as this means some kind of violation is happening.

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

---

Compiled from above answers, worked for me, did following steps to catch it.

Step #1 - Add following snippet to config file

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

Step #2

Add -

[HandleProcessCorruptedStateExceptions]

[SecurityCritical]

on the top of function you are tying catch the exception

source: http://www.gisremotesensing.com/2017/03/catch-exception-attempted-to-read-or.html

---

You can try using AppDomain.UnhandledException and see if that lets you catch it.

**EDIT*

Here is some more information that might be useful (it's a long read).

참고URL : https://stackoverflow.com/questions/3469368/how-to-handle-accessviolationexception