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

Espero que alguien pueda aclararme qué podría estar causando este error:

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

Realmente no puedo publicar código porque este error parece aparecer 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 la aplicación completa se detiene y aparece una pantalla con un error que dice algo como "Hubo un error fatal en ... Esto puede ser un error en el CLR o ... "algo sobre PInvoke u otra información no relevante. Cuando esto sucede, todos los hilos se muestran terminados y no hay información de depuración disponible.

En pocas palabras, esto es lo que hace la aplicación:

Es una aplicación de servidor multiproceso 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 lo veo goteando. Por lo general, consume alrededor de 1,5 GB. No creo que tenga fugas porque el uso de memoria permanece relativamente constante todo el tiempo que la aplicación se está ejecutando. Su código se ejecuta constantemente 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.

He intentado desactivar las optimizaciones del compilador y varias revisiones de Microsoft. Nada parece hacer que este problema desaparezca. Se agradecería si alguien conoce 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 Build de x86 a Any CPU y eso fue suficiente para activar este error. Cambiarlo de nuevo a x86 hizo el truco. Podría ayudar a alguien.

También me enfrenté a este problema con Visual Studio (VS) 2010. Más interesante aún, tenía varios proyectos en mi solución (aplicación de consola, aplicación WPF, aplicación de formularios Windows Forms) pero solo fallaba cuando estaba configurando el tipo de "Aplicación de consola". del proyecto como proyecto de inicio de la solución (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 en sí).

El siguiente cambio finalmente me ayudó a resolver el problema: Ir a las propiedades del proyecto del proyecto de la aplicación de consola (Alternativamente, seleccione el archivo del proyecto en el explorador de soluciones y presione la combinación de teclas Alt+ Enter) -> Ir a la Debugpestaña -> Desplazarse a la Enable Debuggerssección en el panel derecho -> Verificar la Enable unmanaged code debuggingcasilla de verificación como se muestra en la instantánea a continuación -> Haga Floppyclic en el botón en la barra de herramientas para guardar las propiedades del proyecto. La causa raíz de por qué sucedió aún no me es conocida. Lo único que observé fue que había muchas actualizaciones de Windows que se habían instalado en mi máquina la noche anterior, que en su mayoría constituían actualizaciones de Office y del sistema operativo (más de una docena de artículos de KB).

Actualización : VS 2017 en adelante, el nombre de la configuración ha cambiado como se muestra en la siguiente captura de pantalla:

Finalmente rastreó esto con la ayuda de WinDBG y SOS. La violación de acceso estaba siendo lanzada por una DLL desconocida. Resulta que un software llamado "Nvidia Network Manager" estaba causando los problemas. Había leído 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, suponía que no era ambiental porque se produce en más de 1 servidor que usa hardware diferente. Resulta que todas las máquinas en las que probé esto ejecutaban "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 solicitud durante mucho tiempo.

El problema puede deberse a DLL de plataformas de compilación mixtas en el proyecto. es decir, 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 construidas para una plataforma, el problema puede resolverse.

Intenta ejecutar este comando

netsh winsock reset

Fuente: https://stackoverflow.com/a/20492181/1057791

Este error no debería ocurrir en el código administrado. Esto podría resolver el problema:

Vaya al depurador de Visual Studio para evitar esta excepción:

Tools menu ->Options -> Debugging -> General -> Uncheck this option "Suppress JIT optimization on module load"

Espero que ayude.

Me he encontrado y encontré una resolución para esta excepción hoy. Estaba ocurriendo 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 el problema está resuelto.

Fuente de solución:

https://connect.microsoft.com/VisualStudio/feedback/details/819552/visual-studio-debugger-throws-accessviolationexception

Podría ser hardware. Podría ser algo complicado ... pero intentaría sugerir que en algún lugar su código de subprocesos no esté protegiendo alguna colección (como un diccionario) con un bloqueo apropiado.

¿Qué sistema operativo y paquete de servicio está ejecutando?

Tuve este problema recientemente cuando cambié el servidor de desarrollo para un proyecto. Recibía este error en la línea de código donde declaraba una nueva variable 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 nueva máquina, le sugiero que renueve todas las referencias agregadas en ese proyecto.

¿Intentó desactivar DEP (Prevención de ejecución de datos) para su aplicación?

Me enfrenté al mismo problema. Mi código era un .NET dll (extensión de AutoCAD) ejecutándose dentro de AutoCAD 2012. También estoy usando Oracle.DataAccess y mi código arrojó la misma excepción durante ExecuteNonQuery (). Afortunadamente resolví este problema cambiando la versión .net del ODP que estaba usando (es decir, 2.x de Oracle.DataAccess)

Este problema es casi siempre simple. El código es malo Raramente son las herramientas, solo de un análisis estadístico. Incontables millones de personas usan Visual Studio todos los días y tal vez algunas usan su código, ¿qué parte del código está obteniendo las mejores pruebas? Le garantizo que, si esto fuera un problema con VS, probablemente ya lo habríamos encontrado.

Lo que significa la declaración es que, cuando intentas acceder a la memoria que no es tuya, generalmente es porque lo estás haciendo con un puntero dañado, que vino de otro lugar. Por eso está indicando la indicación.

Con la corrupción de la memoria, la detección del error rara vez está cerca de la causa raíz del error. Y los efectos son exactamente lo que usted describe, aparentemente al azar. Solo tendrá que mirar a los culpables habituales, como:

• punteros no inicializados u otros valores.
• escribir más en un búfer que su tamaño.
• recursos compartidos por subprocesos 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 tanto podría haber sucedido entre la creación del problema y la detección del problema.

Principalmente encuentro que es 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 estático manual del código para ver qué podría haberlo dañado, verificando 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 es posible que desee considerar la posibilidad de usar una herramienta de seguimiento de memoria (como valgrind para Linux) para ver si puede detectar problemas obvios.

El código verificable no debería ser capaz de corromper la memoria, por lo que está sucediendo algo inseguro. ¿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 al código no administrado y la organización asociada.

Mi mejor recomendación es adjuntar a una instancia bloqueada y usar WinDBG y SOS para profundizar en lo que sucede 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é, exactamente, está saliendo mal.

Ok, esto podría ser bastante inútil y simplemente anecdótico, pero ...

Esta excepción fue lanzada consistentemente por algunas bibliotecas Twain32 que estábamos usando en mi proyecto, pero solo sucedería en mi máquina.

Probé muchas soluciones sugeridas en Internet, sin éxito ... Hasta que desconecté mi teléfono celular (estaba conectado a través del USB).

Y funcionó.

Resulta que las bibliotecas Twain32 estaban tratando de enumerar mi teléfono como un dispositivo compatible con Twain, y algo que hizo en ese proceso causó esa excepción.

Imagínate...

Recibí este error al usar pinvoke en un método que toma una referencia a a StringBuilder. Había usado el constructor predeterminado que aparentemente solo asigna 16 bytes. Windows trató de poner más de 16 bytes en el búfer y provocó un desbordamiento del búfer.

En vez de

StringBuilder windowText = new StringBuilder(); // Probable overflow of default capacity (16)

Use una capacidad mayor:

StringBuilder windowText = new StringBuilder(3000);

en mi caso el archivo estaba abierto y por lo tanto bloqueado.

Lo estaba obteniendo al intentar cargar un archivo de Excel usando LinqToExcel que también se abrió en Excel.

esto es todo lo que escribí

    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);
    }

Recibí el mismo error en un proyecto con el que estaba trabajando en VB.NET. Verificando el "Habilitar marco de aplicación" en la página de propiedades lo resolvió para mí.

Yo tuve este problema también . 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.

Obtuve este error al azar en VS1017, al intentar construir un proyecto que se estaba construyendo perfectamente bien el día anterior. El reinicio de la PC solucionó el problema (también ejecuté el siguiente comando de antemano, no estoy seguro de si es necesario: netsh winsock reset)

Mi respuesta depende en gran medida de su escenario, pero tuvimos un problema al intentar actualizar una aplicación .NET para un cliente que tenía> 10 años para que pudieran hacer que funcione en Windows 8.1. La respuesta de @ alhazen estaba en 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). Reorientamos la aplicación para .NET 4.5 pero cada vez que se ejecuta la siguiente línea recibimos el AccessViolationException was unhandledmensaje:

UnlockPICImagXpress.PS_Unlock (1908228217,373714400,1341834561,28447);

Para solucionarlo, tuvimos que agregar el siguiente evento posterior a la compilación 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 el ejecutable como incompatible con la Prevención de ejecución de datos. Para más detalles ver aquí .

En algunos casos, esto puede suceder cuando:

obj = new obj();
...
obj.Dispose();  // <-----------------    Incorrect disposal causes it
obj.abc...

En mi caso, tuve que hacer referencia a una biblioteca C / C ++ usando P / Invoke, pero tuve que asegurarme de que la memoria se asignó primero a la matriz de salida usando fixed:

[DllImport("my_c_func_lib.dll", CharSet = CharSet.Ansi)]
public static extern unsafe int my_c_func(double input1, double input2, double pinput3, double *outData);

    public unsafe double[] GetMyUnmanagedCodeValue(double input1, double input2, double input3)
    {
        double[] outData = new double[24];

        fixed (double* returnValue = outData)
        {
            my_c_func(input1, input2, pinput3, returnValue);
        }

        return outData;
    }

Para más detalles, consulte: https://www.c-sharpcorner.com/article/pointers-in-C-Sharp/

Esto me sucedió cuando estaba depurando mi aplicación WinForms de C # en Visual Studio. Mi aplicación realiza llamadas a Win32 a través de DllImport, por ejemplo

[DllImport("Secur32.dll", SetLastError = false)]
private static extern uint LsaEnumerateLogonSessions(out UInt64 LogonSessionCount, out IntPtr LogonSessionList);

Ejecutar Visual Studio "como administrador" resolvió el problema para mí.

Tuve el mismo mensaje de error:

System.AccessViolationException: intento de leer o escribir memoria protegida. Esto es a menudo una indicación de que otra memoria está corrupta.

En mi caso, el error desapareció después de limpiar y reconstruir la solución.

En mi caso, la utilidad FTDI FT Prog arrojó el error al escanear en busca de dispositivos USB. Desconectar mis auriculares Bluetooth de la PC solucionó el problema.

Recibí este mensaje de error en la expresión lambda que estaba usando Linq para filtrar una colección de objetos. Cuando inspeccioné la colección, noté que sus miembros no estaban poblados: en la Localsventana, expandiéndolos solo mostraba "...". En última instancia, el problema estaba en el método del repositorio que inicialmente poblaba la colección: Dapper estaba tratando de asignar automáticamente una propiedad de un objeto anidado. Arreglé la consulta Dapper para manejar la asignación múltiple y eso solucionó el error de memoria.