txt practices net log error ejemplo crear clase best application c# winforms .net-2.0 error-logging

c# - practices - ¿Cómo debe diagnosticar el error SEHException? El componente externo arrojó una excepción



log error c# (7)

Cuando un usuario informa un error como

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

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

Escenario: un usuario (utilizando un programa que mi compañía escribió) 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 haber sido o no este error.

Desde el stack-trace, el error real fue cuando se construyó una clase que no llama directamente a ningún código de interoperabilidad, pero tal vez se complica por el hecho de que el objeto puede ser parte de una lista que está unida a DevExpress Grid.

El error fue "atrapado" 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, entonces el programa continuó funcionando pero el error volvió a ocurrir cuando se ejecutó 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 2GB de memoria y de acuerdo con el Administrador de tareas solo estaba usando aproximadamente la mitad de eso con nuestra aplicación de solo 200Mb.

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

Intento de leer o escribir en la memoria protegida. Esto a menudo es una indicación de que otra memoria está corrupta

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

Dado que las consecuencias del error son bajas (no se pierde trabajo y reiniciar el programa y volver al punto en el que estaban solo tarda un minuto como máximo) y dado que el cliente recibirá una nueva versión en breve (con el tercero actualizado). componente del partido), obviamente puedo cruzar los dedos y espero que el error no vuelva a ocurrir.

Pero, ¿hay algo más que pueda hacer?

Los fabricantes de componentes dicen que esto se ha solucionado en la última versión de su componente que estamos utilizando internamente, pero esto se le ha dado al cliente todavía.

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

Mis configuraciones de máquina:

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

Me enfrenté a este error al depurar 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. Me encontré con el mismo error informado por OP.

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

Una cosa a tener en cuenta es que se suponía que el método que se invocaba en el ensamblaje C ++ debía escribir algunas cosas en el registro. No fui depurando el código de 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. Así que 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.

Sí. Este error es una excepción estructurada que no se asignó a un error .NET. Probablemente sea su mapeo DataGrid arrojando una excepción nativa que no fue detectada.

Puede ver qué excepción ocurre al mirar la propiedad ExternalException.ErrorCode . Verificaría el seguimiento de su pila, y si está vinculado a la grilla DevExpress, informe el problema a ellos.

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

Tuve un problema similar con una SEHException que se lanzó cuando mi programa utilizó por primera vez un contenedor nativo dll. Resultó que faltaba la DLL nativa para esa envoltura. 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 comprobar si había algún error al cargar todos los archivos DLL necesarios.

Una vieja pregunta, pero para los googlers: me he encontrado con este error cuando la aplicación reside en una red compartida, y el dispositivo (portátil, tableta, ...) se desconecta de la red mientras la aplicación está en uso. En mi caso, fue debido a que una tableta Surface salió del alcance inalámbrico. No hay problemas después de instalar un WAP mejor.