c# - Intento de leer o escribir en la memoria protegida. Esto a menudo es una indicación de que otra memoria está corrupta
.net multithreading (18)
¿Intentó desactivar DEP (Prevención de ejecución de datos) para su aplicación?
Espero que alguien me pueda aclarar qué podría estar causando este error:
Intento de leer o escribir en la memoria protegida. Esto a menudo es una indicación de que otra memoria está corrupta.
Realmente no puedo publicar el código porque este error parece ser arrojado en cualquier área aleatoria de la aplicación. La aplicación se ejecutará entre 12 y 48 horas antes de arrojar el error. A veces se detendrá en un lugar aparentemente aleatorio y arrojará el error anterior, otras veces se detendrá toda la aplicación y obtendré una pantalla con un error que dice algo como "Hubo un error fatal en ... Esto puede ser una error en el CLR o ... "algo sobre PInvoke u otra información no relevante. Cuando esto sucede, todos los hilos terminan y no hay información de depuración disponible.
En resumen, esto es lo que hace la aplicación:
Es una aplicación de servidor multihilo escrita completamente en C #. Los clientes se conectan al servidor a través del socket. El servidor ejecuta un "entorno" virtual para los clientes donde pueden interactuar entre sí y con el entorno. Consume bastante memoria, pero no la veo gotear. Por lo general, consume alrededor de 1,5 GB. No creo que gotee porque el uso de la memoria se mantiene relativamente constante todo el tiempo que la aplicación se está ejecutando. Su código constantemente se ejecuta para mantener el entorno, incluso si los clientes no están haciendo nada. No utiliza software de terceros u otras API. Los únicos recursos externos que utiliza esta aplicación son las conexiones de socket y las conexiones de bases de datos SQL. Se ejecuta en un servidor de 64 bits. He intentado depurar esto en VS2008 y VS2010 usando .net 2.0, 3.5 y 4.0 y en varios servidores y el problema aún ocurre eventualmente.
Intenté apagar las optimizaciones del compilador y varios arreglos rápidos de Microsoft. Nada parece hacer que este problema desaparezca. Se agradecería si alguien supiera alguna causa posible, o algún tipo de forma de identificar cuál es la causa del problema.
Acabo de enfrentar este problema en VS 2013 .NET 4.5 con una DLL de MapInfo. Resulta que el problema fue que cambié la plataforma para compilación de x86 a cualquier CPU y eso fue suficiente para desencadenar este error. Cambiarlo a x86 hizo el truco. Podría ayudar a alguien.
El código verificable no debería poder dañar la memoria, por lo que hay algo inseguro pasando. ¿Está utilizando algún código inseguro en algún lugar, como en el procesamiento de búfer? Además, las cosas sobre PInvoke pueden no ser irrelevantes, ya que PInvoke implica una transición a código no administrado y clasificación asociada.
Mi mejor recomendación es adjuntarme a una instancia bloqueada y utilizar WinDBG y SOS para profundizar en lo que está sucediendo en el momento del bloqueo. Esto no es para los débiles de corazón, pero en este punto es posible que necesite desarrollar herramientas más poderosas para determinar qué es exactamente lo que está fallando.
El problema puede deberse a DLL de plataformas de compilación mixtas en el proyecto. es decir, usted construye su proyecto en Cualquier CPU pero tiene algunas DLL en el proyecto ya construidas para la plataforma x86. Esto provocará bloqueos aleatorios debido a la asignación de memoria diferente de la arquitectura de 32 bits y 64 bits. Si todas las DLL están compiladas para una plataforma, el problema se puede resolver.
Enfrenté el mismo problema. Mi código era .NET dll (extensión de AutoCAD) ejecutándose dentro de AutoCAD 2012. También estoy usando Oracle.DataAccess y mi código arrojaba la misma excepción durante ExecuteNonQuery (). Afortunadamente, resolví este problema cambiando la versión de .NET del ODP que estaba usando (es decir, 2.x de Oracle.DataAccess)
Este error no debería ocurrir en el código administrado. Esto podría resolver el problema:
Vaya a Visual Studio Debugger para eludir esta excepción:
Tools menu ->Options -> Debugging -> General -> Uncheck this option "Suppress JIT optimization on module load"
Espero que ayude
Este problema es casi invariablemente simple. El código es malo Raramente son las herramientas, solo a partir de un análisis estadístico. Millones de personas no contadas están usando Visual Studio todos los días y tal vez algunas están usando su código. ¿Qué parte del código está obteniendo mejores resultados? Te garantizo que, si esto fuera un problema con VS, probablemente ya lo hubiéramos encontrado.
Lo que la declaración significa es que, cuando intenta acceder a la memoria que no es suya, generalmente se debe a que lo está haciendo con un puntero corrupto, que proviene de otro lugar. Es por eso que está indicando la indicación.
Con la corrupción de la memoria, la captura del error rara vez se acerca a la causa raíz del error. Y los efectos son exactamente lo que describes, aparentemente al azar. Tendrás que mirar a los culpables habituales, cosas como:
- punteros no inicializados u otros valores.
- escribir más en un búfer que su tamaño.
- recursos compartidos por hilos que no están protegidos por mutexes.
Trabajar hacia atrás desde un problema como este para encontrar la causa raíz es increíblemente difícil dado que pudo haber pasado tanto entre la creación del problema y la detección del problema.
En su mayoría, me resulta más fácil echar un vistazo a lo que está dañado (por ejemplo, un puntero específico) y luego hacer un análisis manual estático del código para ver qué podría haberlo corrompido, buscando los culpables habituales como se muestra arriba. Sin embargo, incluso esto no atrapará largas cadenas de problemas.
No estoy lo suficientemente familiarizado con VS como para saberlo, pero también puede considerar la posibilidad de utilizar una herramienta de seguimiento de memoria (como valgrind para Linux) para ver si puede detectar problemas obvios.
Finalmente rastreó esto con la ayuda de WinDBG y SOS. La violación de acceso fue lanzada por una DLL desconocida. Resulta que un software llamado "Nvidia Network Manager" estaba causando los problemas. Leí innumerables veces cómo este problema puede ser causado por firewalls o antivirus, ninguno de los cuales estoy usando, así que descarté esta idea. Además, estaba bajo la suposición de que no era ambiental porque ocurre en más de 1 servidor que usa hardware diferente. Resulta que todas las máquinas en las que probé esto estaban ejecutando "NVidia Network Manager". Creo que se instala con el resto de los controladores de la placa base.
Espero que esto ayude a alguien, ya que este problema estuvo plagando mi aplicación durante mucho tiempo.
Intenta ejecutar este comando
netsh winsock reset
Fuente: https://.com/a/20492181/1057791
Me encontré con, y encontré una resolución a esta excepción hoy. Ocurría cuando intentaba depurar una prueba unitaria (NUnit) que llamaba a un método virtual en una clase abstracta.
El problema parece ser con la instalación de .NET 4.5.1.
He descargado .NET 4.5.2 e instalado (mis proyectos todavía hacen referencia a .NET 4.5.1) y se ha resuelto el problema.
Fuente de solución:
Mi respuesta depende mucho de su escenario, pero tuvimos un problema al tratar de actualizar una aplicación .NET para un cliente que tenía> 10 años de antigüedad para que pudiera funcionar en Windows 8.1. La respuesta de @ alhazen fue algo así como el estadio correcto para mí. La aplicación se basaba en una DLL de terceros que el cliente no quería pagar para actualizar (Pegasus / Accusoft ImagXpress). AccessViolationException was unhandled la aplicación para .NET 4.5, pero cada vez que AccessViolationException was unhandled la siguiente línea recibimos el mensaje AccessViolationException was unhandled :
UnlockPICImagXpress.PS_Unlock (1908228217,373714400,1341834561,28447);
Para solucionarlo, tuvimos que agregar el siguiente evento de construcción posterior al proyecto:
call "$(DevEnvDir)../tools/vsvars32.bat"
"C:/Program Files (x86)/Microsoft Visual Studio 11.0/VC/bin/amd64/editbin.exe" /NXCOMPAT:NO "$(TargetPath)"
Esto especifica explícitamente que el ejecutable es incompatible con la Prevención de ejecución de datos. Para más detalles, mira here .
Obtuve el mismo error en un proyecto con el que estaba trabajando en VB.NET. Comprobando el "Habilitar el marco de la aplicación" en la página de propiedades me lo resolvió.
Ok, esto podría ser bastante inútil y simplemente anecdótico, pero ...
Esta excepción fue arrojada consistentemente por algunas bibliotecas Twain32 que estábamos usando en mi proyecto, pero solo ocurriría en mi máquina.
Intenté muchas soluciones sugeridas en todo Internet, pero no sirvió de nada ... Hasta que desenchufé mi teléfono celular (estaba conectado a través del USB).
Y funcionó.
Resulta que las bibliotecas Twain32 estaban tratando de incluir mi teléfono como un dispositivo compatible con Twain, y algo que hizo en ese proceso causó esa excepción.
Imagínate...
Podría ser hardware. Podría ser algo complicado ... pero intentaría sugerir que en alguna parte su código de enhebrado no protege una colección (como un diccionario) con un bloqueo apropiado.
¿Qué sistema operativo y paquete de servicio está ejecutando?
También me enfrenté a este problema con Visual Studio 2010. Más interesante, tuve varios proyectos en mi solución (aplicación de consola, aplicación WPF, aplicación Windows Forms) pero solo fallaba cuando, estaba configurando el proyecto que era del tipo "Aplicación de consola". "como proyecto de inicio (incluso para aquellos que literalmente no tenían código o ensamblajes adicionales referidos aparte de los predeterminados que vienen con la plantilla del proyecto).
El siguiente cambio me ayudó a resolver el problema: vaya a las propiedades del proyecto de la aplicación de consola -> Ir a la pestaña Debug -> Ir a la sección Enable Debuggers en el panel derecho -> Marque la casilla Enable unmanaged code debugging como se muestra en la instantánea abajo. La causa raíz de por qué sucedió todavía no la conozco. Lo único que observé fue que había muchas actualizaciones de ventanas que se habían instalado en mi máquina la noche anterior, que en su mayoría consistían en actualizaciones de Office y actualizaciones del sistema operativo (más de una docena de artículos de KB).
También tuve este problema . Estaba ejecutando diferentes soluciones al mismo tiempo usando Visual Studio, al cerrar otras soluciones y ejecutar solo la solución de destino, funcionó bien sin ese error.
Tuve este problema recientemente cuando cambié el servidor de desarrollo para un proyecto. Estaba obteniendo este error en la línea de código donde declare una nueva variable de OracleConnection.
Después de probar muchas cosas, incluida la instalación de revisiones, intenté cambiar las referencias Oracle.DataAccess y System.Data.OracleClient en el proyecto y ¡funcionó!
Cuando un proyecto se mueve a una máquina nueva, le sugiero que renueve todas las referencias agregadas en ese proyecto.
en mi caso, el archivo estaba abierto y, por lo tanto, bloqueado.
Lo conseguí cuando intentaba cargar un archivo de Excel usando LinqToExcel que también se abrió en Excel.
esto es todo lo que deeded
var maps = from f in book.Worksheet<NavMapping>()
select f;
try {
foreach (var m in maps)
if (!string.IsNullOrEmpty(m.SSS_ID) && _mappings.ContainsKey(m.SSS_ID))
_mappings.Add(m.SSS_ID, m.CDS_ID);
} catch (AccessViolationException ex) {
_logger.Error("mapping file error. most likely this file is locked or open. " + ex);
}