Cómo manejar AccessViolationException

Estoy usando un objeto COM (MODI) desde mi aplicación .net. El método que estoy llamando arroja System.AccessViolationException, que es interceptado por Visual Studio. Lo curioso es que he cerrado mi llamada en una captura de prueba, que tiene controladores para AccessViolationException, COMException y todo lo demás, pero cuando Visual Studio (2010) intercepta AccessViolationException, el depurador se rompe en la llamada al método (doc.OCR), y si paso, continúa a la siguiente línea en lugar de ingresar al bloque catch. Además, si ejecuto esto fuera del estudio visual mi aplicación se bloquea. ¿Cómo puedo manejar esta excepción que se lanza dentro del objeto 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(); } 

En .NET 4.0, el tiempo de ejecución maneja ciertas excepciones planteadas como errores de manejo de errores estructurados de Windows (SEH) como indicadores de estado dañado. Estas Excepciones de estado dañado (CSE) no pueden ser atrapadas por su código administrado estándar. No entraré en el por qué o cómo está aquí. Lea este artículo sobre CSE en .NET 4.0 Framework:

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

Pero hay esperanza. Hay algunas formas de evitar esto:

  1. Vuelva a comstackr como un ensamblado .NET 3.5 y ejecútelo en .NET 4.0.

  2. Agregue una línea al archivo de configuración de la aplicación en el elemento de configuración / tiempo de ejecución:

  3. Decore los métodos con los que desea capturar estas excepciones con el atributo HandleProcessCorruptedStateExceptions . Consulte http://msdn.microsoft.com/en-us/magazine/dd419661.aspx#id0070035 para obtener detalles.


EDITAR

Anteriormente, hice referencia a una publicación en el foro para obtener detalles adicionales. Pero dado que se ha retirado Microsoft Connect, aquí están los detalles adicionales en caso de que esté interesado:

De Gaurav Khanna, un desarrollador del equipo Microsoft CLR

Este comportamiento es por diseño debido a una característica de CLR 4.0 llamada Corrupted State Exceptions. En pocas palabras, el código administrado no debe intentar detectar excepciones que indiquen un estado de proceso dañado y AV es una de ellas.

A continuación, pasa a referenciar la documentación en HandleProcessCorruptedStateExceptionsAttribute y en el artículo anterior. Basta con decir que definitivamente vale la pena leerlo si está considerando detectar este tipo de excepciones.

Agregue lo siguiente en el archivo de configuración, y quedará atrapado en el bloque try catch. Palabra de advertencia … trate de evitar esta situación, ya que esto significa que está ocurriendo algún tipo de violación.

      

Comstackdo a partir de las respuestas anteriores, funcionó para mí, hizo los siguientes pasos para atraparlo.

Paso # 1 – Agregue el siguiente fragmento de código al archivo de configuración

      

Paso 2

Agregar –

 [HandleProcessCorruptedStateExceptions] [SecurityCritical] 

en la parte superior de la función que está atando atrapar la excepción

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

Puedes intentar usar AppDomain.UnhandledException y ver si eso te permite atraparlo.

**EDITAR*

Aquí hay más información que podría ser útil (es una lectura larga).