Domanda

Sto usando un oggetto COM (MODI) da dentro il mio NET. Il metodo che io chiamo lancia uno System.AccessViolationException, che viene intercettato da Visual Studio. La cosa strana è che ho avvolto la mia chiamata in un tentativo di cattura, che ha i gestori per AccessViolationException, COMException e tutto il resto, ma quando Visual Studio (2010) intercetta l'AccessViolationException, le interruzioni di debugger sulla chiamata al metodo (doc.OCR), e se passo attraverso, continua alla riga successiva invece di entrare nel blocco catch. Inoltre, se corro questo al di fuori dello studio visivo mia applicazione si blocca. 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();

}
È stato utile?

Soluzione

In .NET 4.0, le maniglie di runtime alcune eccezioni sollevate esempio Windows strutturato di gestione degli errori (SEH) errori come indicatori di danneggiato lo stato. Queste eccezioni danneggiato lo stato (CSE) non sono autorizzati a essere catturati dal codice gestito standard. Non voglio entrare nel perché del o come sta qui. Leggi questo articolo su CSE di in .NET Framework 4.0:

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

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

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

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

  3. Decora i metodi che si desidera per la cattura di queste eccezioni con l'attributo HandleProcessCorruptedStateExceptions. Vedere http://msdn.microsoft.com/en-us/magazine/ dd419661.aspx # id0070035 per i dettagli.


Modifica

In precedenza, ho fatto riferimento a un messaggio Forum per ulteriori dettagli. Ma dal momento che Microsoft Connect è stato ritirato, ecco i dettagli aggiuntivi nel caso in cui siete interessati:

Da Gaurav Khanna, uno sviluppatore di Microsoft CLR team

  

Questo comportamento legato alla progettazione a causa di una caratteristica del CLR 4.0 chiamati eccezioni danneggiato lo stato. In poche parole, il codice gestito non dovrebbe fare un tentativo di cattura eccezioni che indicano lo stato del processo corrotto e AV è uno di loro.

Si passa poi per fare riferimento alla documentazione sul HandleProcessCorruptedStateExceptionsAttribute e l'articolo di cui sopra. Basti dire, è sicuramente la pena di leggere, se si sta valutando la cattura di questi tipi di eccezioni.

Altri suggerimenti

Aggiungere la seguente nel file di configurazione, e sarà preso in blocco try catch. Parola di cautela ... cercare di evitare questa situazione, come questo mezzo un qualche tipo di violazione che sta accadendo.

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

Compilato da risposte di cui sopra, ha lavorato per me, ha i seguenti passi di catturarlo.

Passo # 1 - Aggiungere seguente frammento di file di configurazione

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

Passo # 2

Aggiungi -

[HandleProcessCorruptedStateExceptions]

[SecurityCritical]

sulla parte superiore della funzione che si sta legando intercettare l'eccezione

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

Si può provare a utilizzare AppDomain.UnhandledException e vedere se questo consente di prenderlo.

EDIT ** *

Ecco alcuni ulteriori informazioni che potrebbero essere utili (è una lunga lettura).

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top