Come gestire AccessViolationException

Sto usando un oggetto COM (MODI) dalla mia applicazione .net. Il metodo che sto chiamando genera System.AccessViolationException, che viene intercettato da Visual Studio. La cosa strana è che ho racchiuso la mia chiamata in un tentativo catch, che ha gestori per AccessViolationException, COMException e tutto il resto, ma quando Visual Studio (2010) intercetta AccessViolationException, il debugger si interrompe sulla chiamata del metodo (doc.OCR), e se passo attraverso, continua alla riga successiva invece di entrare nel blocco catch. Inoltre, se eseguo questo al di fuori di Visual Studio, la mia applicazione si arresta in modo anomalo. Come posso gestire questa eccezione che viene generata all'interno dell'oggetto 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();

}

In .NET 4.0, il runtime gestisce alcune eccezioni sollevate come errori SEH (Windows Structured Error Handling) come indicatori di stato danneggiato. Queste eccezioni di stato danneggiato (CSE) non possono essere rilevate dal codice gestito standard. Non entrerò nel perché o come è qui. Leggi questo articolo sui CSE in .NET 4.0 Framework:

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

Ma c'è speranza. Ci sono alcuni modi per aggirare questo:

1. Ricompilare come assembly .NET 3.5 ed eseguirlo in .NET 4.0.

2. Aggiungi una riga al file di configurazione dell'applicazione sotto l'elemento configuration / runtime: <legacyCorruptedStateExceptionsPolicy enabled="true|false"/>

3. Decora i metodi in cui vuoi catturare queste eccezioni con l' HandleProcessCorruptedStateExceptionsattributo. Vedere http://msdn.microsoft.com/en-us/magazine/dd419661.aspx#id0070035 per i dettagli.

MODIFICARE

In precedenza, ho fatto riferimento a un post sul forum per ulteriori dettagli. Ma poiché Microsoft Connect è stato ritirato, ecco i dettagli aggiuntivi nel caso in cui ti interessi:

Da Gaurav Khanna, uno sviluppatore del team Microsoft CLR

Questo comportamento è in base alla progettazione a causa di una funzionalità di CLR 4.0 denominata Eccezioni stato danneggiato. In poche parole, il codice gestito non dovrebbe tentare di rilevare eccezioni che indicano lo stato del processo danneggiato e AV è uno di questi.

Continua quindi a fare riferimento alla documentazione su HandleProcessCorruptedStateExceptionsAttribute e all'articolo precedente. Basti dire che vale sicuramente la pena leggere se stai pensando di cogliere questo tipo di eccezioni.

Aggiungi quanto segue nel file di configurazione e verrà catturato nel tentativo di catch block. Un avvertimento ... cerca di evitare questa situazione, poiché ciò significa che si sta verificando una sorta di violazione.

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

Compilato dalle risposte sopra, ha funzionato per me, ha fatto i seguenti passi per prenderlo.

Passaggio 1: aggiungi il frammento seguente al file di configurazione

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

Passo 2

Inserisci -

[HandleProcessCorruptedStateExceptions]

[SecurityCritical]

nella parte superiore della funzione che stai catturando cattura l'eccezione

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

Microsoft: "Le eccezioni di stato del processo danneggiate sono eccezioni che indicano che lo stato di un processo è stato danneggiato. Non è consigliabile eseguire l'applicazione in questo stato ..... Se si è assolutamente certi di voler mantenere la gestione di questi eccezioni, è necessario applicare l' HandleProcessCorruptedStateExceptionsAttributeattributo "

Microsoft: "Utilizza i domini delle applicazioni per isolare le attività che potrebbero arrestare un processo."

Il seguente programma proteggerà la tua applicazione / thread principale da guasti irreversibili senza rischi associati all'uso di HandleProcessCorruptedStateExceptionse<legacyCorruptedStateExceptionsPolicy>

public class BoundaryLessExecHelper : MarshalByRefObject
{
    public void DoSomething(MethodParams parms, Action action)
    {
        if (action != null)
            action();
        parms.BeenThere = true; // example of return value
    }
}

public struct MethodParams
{
    public bool BeenThere { get; set; }
}

class Program
{
    static void InvokeCse()
    {
        IntPtr ptr = new IntPtr(123);
        System.Runtime.InteropServices.Marshal.StructureToPtr(123, ptr, true);
    }

    private static void ExecInThisDomain()
    {
        try
        {
            var o = new BoundaryLessExecHelper();
            var p = new MethodParams() { BeenThere = false };
            Console.WriteLine("Before call");

            o.DoSomething(p, CausesAccessViolation);
            Console.WriteLine("After call. param been there? : " + p.BeenThere.ToString()); //never stops here
        }
        catch (Exception exc)
        {
            Console.WriteLine($"CSE: {exc.ToString()}");
        }
        Console.ReadLine();
    }


    private static void ExecInAnotherDomain()
    {
        AppDomain dom = null;

        try
        {
            dom = AppDomain.CreateDomain("newDomain");
            var p = new MethodParams() { BeenThere = false };
            var o = (BoundaryLessExecHelper)dom.CreateInstanceAndUnwrap(typeof(BoundaryLessExecHelper).Assembly.FullName, typeof(BoundaryLessExecHelper).FullName);         
            Console.WriteLine("Before call");

            o.DoSomething(p, CausesAccessViolation);
            Console.WriteLine("After call. param been there? : " + p.BeenThere.ToString()); // never gets to here
        }
        catch (Exception exc)
        {
            Console.WriteLine($"CSE: {exc.ToString()}");
        }
        finally
        {
            AppDomain.Unload(dom);
        }

        Console.ReadLine();
    }


    static void Main(string[] args)
    {
        ExecInAnotherDomain(); // this will not break app
        ExecInThisDomain();  // this will
    }
}

Puoi provare a utilizzare AppDomain.UnhandledException e vedere se ciò ti consente di catturarlo.

**MODIFICARE*

Ecco alcune altre informazioni che potrebbero essere utili (è una lettura lunga).