¿Cómo debe diagnosticar el error SEHException? El componente externo ha generado una excepción

Siempre que un usuario informe un error como

System.Runtime.InteropServices.SEHException - ¿El componente externo ha generado una excepción?

¿Hay algo que yo, como programador, pueda hacer para determinar la causa?

Escenario: un usuario (que utiliza un programa escrito por mi empresa) ha informado de este error. Esto puede o no haber sido un error único. Mencionaron que en el último mes, la computadora ha 'dejado de funcionar' dos veces. He aprendido por experiencia, no tomar esta descripción demasiado literalmente, ya que generalmente significa que alguien relacionado con la computadora no está funcionando como se esperaba. No pudieron darme más detalles y no pude encontrar ningún error registrado. Por lo tanto, puede que haya sido este error o no.

Desde el seguimiento de la pila, el error real fue al construir una clase que no llama directamente a ningún código de interoperabilidad, pero quizás complicado por el hecho de que el objeto puede ser parte de una lista que está vinculada a datos en una cuadrícula DevExpress.

El error fue "detectado" por una rutina de excepción no controlada que normalmente cerrará el programa, pero tiene una opción para ignorar y continuar. Si optaron por ignorar el error, el programa continuó funcionando, pero el error volvió a ocurrir la próxima vez que se ejecutara esta rutina. Sin embargo, no volvió a ocurrir después de cerrar y reiniciar nuestra aplicación.

La computadora en cuestión no parecía estar estresada. Está ejecutando Vista Business, tiene 2 GB de memoria y, según el Administrador de tareas, solo estaba usando aproximadamente la mitad de eso con nuestra aplicación, aproximadamente 200 Mb.

Hay otra información que puede ser relevante o no. Otra sección del mismo programa utiliza un componente de terceros que es efectivamente un envoltorio dotnet alrededor de una dll nativa y este componente tiene un problema conocido en el que muy ocasionalmente, obtienes un

Intento de leer o escribir en la memoria protegida. Esto suele ser una indicación de que otra memoria está dañada

Los fabricantes de componentes dicen que esto se ha solucionado en la última versión de su componente que estamos usando internamente, pero aún no se ha entregado al cliente.

Dado que las consecuencias del error son bajas (no se pierde ningún trabajo y reiniciar el programa y volver a donde estaban solo toma un minuto como máximo) y dado que el cliente en breve estará obteniendo una nueva versión (con la tercera versión actualizada). party), obviamente puedo cruzar los dedos y esperar que el error no vuelva a ocurrir.

¿Pero hay algo más que pueda hacer?

Si. Este error es una excepción estructurada que no se asignó a un error de .NET. Probablemente sea su asignación de DataGrid la que arroja una excepción nativa que no se detectó.

Puede saber qué excepción se está produciendo mirando la propiedad ExternalException.ErrorCode . Verificaría el seguimiento de la pila y, si está vinculado a la cuadrícula de DevExpress, les informaré del problema.

Tuve un problema similar con una SEHException que se lanzó cuando mi programa usó por primera vez un contenedor dll nativo. Resultó que faltaba la DLL nativa para ese contenedor. La excepción no fue de ninguna manera útil para resolver esto. Lo que sí ayudó al final fue ejecutar procmon en segundo plano y verificar si había algún error al cargar todas las DLL necesarias.

si tiene un problema como se describe en esta publicación:

depurador asp.net mvc que lanza SEHException

entonces la solución es:

si tiene alguna aplicación de Trusteer (como rapport o algo así) simplemente desinstale y reinicie su sistema, funcionará bien ... encontré esta solución aquí:

http://forums.asp.net/t/1704958.aspx/8/10?Re+SEHException+thrown+when+I+run+the+application

Los fabricantes de componentes dicen que esto se ha solucionado en la última versión de su componente que estamos usando internamente, pero esto ya se ha entregado al cliente.

Pregúntele al fabricante de componentes cómo probar si el problema que está teniendo el cliente es el problema que dice haber solucionado en su última versión, sin / antes de implementar su última versión para el cliente.

Me he encontrado con este error cuando la aplicación reside en un recurso compartido de red y el dispositivo (computadora portátil, tableta, ...) se desconecta de la red mientras la aplicación está en uso. En mi caso, se debió a que una tableta Surface se salió del alcance inalámbrico. No hay problemas después de instalar un WAP mejor.

Solo otra información ... Tuve ese problema hoy en un sistema TS de Windows 2012 R2 x64 donde la aplicación se inició desde una ruta unc / network. El problema ocurrió para una aplicación para todos los usuarios del servidor de terminal. La ejecución de la aplicación de forma local funcionó sin problemas. Después de un reinicio, comenzó a funcionar nuevamente: la SEHException lanzada había sido Constructor init y TargetInvocationException

Configuraciones de mi máquina:

Sistema operativo: Windows 10 versión 1703 (x64)

Me enfrenté a este error mientras depuraba mi proyecto C # .Net en Visual Studio 2017 Community Edition. Estaba llamando a un método nativo realizando p / invoke en un ensamblado de C ++ cargado en tiempo de ejecución. Encontré el mismo error informado por OP.

Me di cuenta de que Visual Studio se inició con una cuenta de usuario que no era un administrador en la máquina. Luego reinicié Visual Studio con una cuenta de usuario diferente que era un administrador en la máquina. Eso es todo. Mi problema se resolvió y no volví a enfrentarlo.

Una cosa a tener en cuenta es que se suponía que el método que se estaba invocando en el ensamblado de C ++ escribiría algunas cosas en el registro. No fui a depurar el código C ++ para hacer algo de RCA, pero veo la posibilidad de que todo fallara ya que se requieren privilegios administrativos para escribir el registro en el sistema operativo Windows 10. Entonces, antes, cuando Visual Studio se ejecutaba con una cuenta de usuario que no tenía privilegios administrativos en la máquina, las llamadas nativas fallaban.

Recibí este error mientras ejecutaba pruebas unitarias en el almacenamiento en caché de inmemory que estaba configurando. Inundó el caché. Después de invalidar el caché y reiniciar la máquina virtual, funcionó bien.