Tentative de lecture ou d'écriture de la mémoire protégée. Ceci indique souvent qu'une autre mémoire est corrompue

J'espère que quelqu'un pourra m'éclairer sur la cause de cette erreur:

Tentative de lecture ou d'écriture de la mémoire protégée. Cela indique souvent qu'une autre mémoire est corrompue.

Je ne peux pas vraiment publier de code car cette erreur semble être lancée dans une zone aléatoire de l'application. L'application s'exécutera entre 12 et 48 heures avant de générer l'erreur. Parfois, il s'arrête à un endroit apparemment aléatoire et lance l'erreur ci-dessus, d'autres fois, toute l'application s'arrête et j'obtiens un écran avec une erreur qui dit quelque chose du genre "Il y a eu une erreur fatale dans ... Cela peut être un bug dans le CLR ou ... "quelque chose à propos de PInvoke ou d'autres informations non pertinentes. Lorsque cela se produit, tous les threads sont terminés et aucune information de débogage n'est disponible.

En un mot, voici ce que fait l'application:

C'est une application serveur multi-thread écrite entièrement en C #. Les clients se connectent au serveur via socket. Le serveur exécute un «environnement» virtuel pour les clients dans lequel ils peuvent interagir entre eux et avec l'environnement. Il consomme pas mal de mémoire mais je ne vois pas de fuite. Il consomme généralement environ 1,5 Go. Je ne pense pas que cela fuit car l'utilisation de la mémoire reste relativement constante pendant tout le temps que l'application est en cours d'exécution. Son code est constamment en cours d'exécution pour maintenir l'environnement même si les clients ne font rien. Il n'utilise aucun logiciel tiers ni aucune autre API. Les seules ressources externes utilisées par cette application sont les connexions de socket et les connexions de base de données SQL. Il fonctionne sur un serveur 64 bits. J'ai essayé de déboguer ceci dans VS2008 et VS2010 en utilisant .net 2.0, 3.5 et 4.

J'ai essayé de désactiver les optimisations du compilateur et plusieurs correctifs de Microsoft. Rien ne semble faire disparaître ce problème. Il serait apprécié que quelqu'un connaisse les causes possibles ou une sorte de moyen d'identifier ce qui cause le problème.

Je viens de faire face à ce problème dans VS 2013 .NET 4.5 avec une DLL MapInfo. Il s'est avéré que le problème était que j'ai changé la plate-forme pour la construction de x86 à N'importe quel processeur et cela suffisait pour déclencher cette erreur. Le remettre en x86 a fait l'affaire. Pourrait aider quelqu'un.

J'ai également rencontré ce problème avec Visual Studio (VS) 2010. Plus intéressant encore, j'avais plusieurs projets dans ma solution (application console, application WPF, application Windows Forms) mais cela n'échouait que lorsque je définissais le type "Application console" du projet comme projet de démarrage de la solution (même pour ceux qui n'avaient littéralement pas de code ou des assemblys supplémentaires référencés en dehors de ceux par défaut fournis avec le modèle de projet lui-même).

Le changement suivant m'a finalement aidé à résoudre le problème: accédez aux propriétés du projet du projet d'application de la console (ou sélectionnez le fichier de projet dans l'explorateur de solutions et appuyez sur Alt+ Entercombinaison de touches) -> Aller à l' Debugonglet -> Faire défiler jusqu'à la Enable Debuggerssection dans le volet de droite -> Vérifier la Enable unmanaged code debuggingcase à cocher comme indiqué dans l'instantané ci-dessous -> Cliquez sur le Floppybouton dans la barre d'outils pour enregistrer les propriétés du projet. Je ne sais toujours pas pourquoi cela s'est produit. La seule chose que j'ai observée était qu'il y avait beaucoup de mises à jour de Windows qui avaient été installées sur ma machine la nuit précédente et qui constituaient principalement des mises à jour de bureau et des mises à jour du système d'exploitation (plus d'une douzaine d'articles de Ko).

Mise à jour : À partir de VS 2017, le nom du paramètre a changé comme indiqué dans la capture d'écran ci-dessous:

Enfin retrouvé cela avec l'aide de WinDBG et SOS. La violation d'accès a été levée par une DLL inconnue. Il s'avère qu'un logiciel appelé "Nvidia Network Manager" était à l'origine des problèmes. J'avais lu d'innombrables fois comment ce problème pouvait être causé par des pare-feu ou des antivirus, que j'utilise ni l'un ni l'autre, j'ai donc rejeté cette idée. De plus, je supposais que ce n'était pas environnemental car cela se produit sur plus d'un serveur utilisant un matériel différent. Il s'avère que toutes les machines sur lesquelles j'ai testé ceci exécutaient "NVidia Network Manager". Je crois qu'il s'installe avec le reste des pilotes de la carte mère.

J'espère que cela aidera quelqu'un car ce problème affectait ma candidature depuis très longtemps.

Le problème peut être dû à des DLL de plates-formes de génération mixtes dans le projet. c'est-à-dire que vous construisez votre projet sur N'importe quel processeur mais que vous avez déjà des DLL dans le projet pour la plate-forme x86. Ceux-ci provoqueront des plantages aléatoires en raison du mappage de mémoire différent de l'architecture 32 bits et 64 bits. Si toutes les DLL sont créées pour une plate-forme, le problème peut être résolu.

Essayez d'exécuter cette commande

réinitialisation netsh winsock

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

Cette erreur ne doit pas se produire dans le code managé. Cela pourrait résoudre le problème:

Accédez au débogueur Visual Studio pour contourner cette exception:

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

J'espère que cela aidera.

J'ai rencontré et trouvé une solution à cette exception aujourd'hui. Cela se produisait lorsque j'essayais de déboguer un test unitaire (NUnit) qui appelait une méthode virtuelle sur une classe abstraite.

Le problème semble être lié à l'installation de .NET 4.5.1.

J'ai téléchargé .NET 4.5.2 et installé (mes projets font toujours référence à .NET 4.5.1) et le problème est résolu.

Source de solution:

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

Cela pourrait être du matériel. Cela pourrait être quelque chose de compliqué ... mais je voudrais essayer de suggérer que quelque part votre code de thread ne protège pas une collection (comme un dictionnaire) avec un verrou approprié.

Quel système d'exploitation et service pack utilisez-vous?

J'ai eu ce problème récemment lorsque j'ai changé le serveur de développement pour un projet. J'obtenais cette erreur sur la ligne de code où j'ai déclaré une nouvelle variable OracleConnection.

Après avoir essayé beaucoup de choses, y compris l'installation de correctifs, j'ai essayé de changer les références Oracle.DataAccess et System.Data.OracleClient dans le projet et cela a fonctionné!

Lorsqu'un projet est déplacé vers une nouvelle machine, je vous suggère de renouveler toutes les références ajoutées dans ce projet.

Avez-vous essayé de désactiver DEP (Data Execution Prevention) pour votre application?

J'ai fait face au même problème. Mon code était une dll .NET (extension AutoCAD) fonctionnant dans AutoCAD 2012. J'utilise également Oracle.DataAccess et mon code lançait la même exception pendant ExecuteNonQuery (). J'ai heureusement résolu ce problème en changeant la version .net de l'ODP que j'utilisais (c'est-à-dire 2.x d'Oracle.DataAccess)

Cette question est presque toujours simple. Le code est mauvais. Ce sont rarement les outils, juste à partir d'une analyse statistique. Des millions de personnes utilisent Visual Studio chaque jour et peut-être que quelques-unes utilisent votre code - quel morceau de code obtient le meilleur test? Je vous garantis que si c'était un problème avec VS, nous l'aurions probablement déjà trouvé.

Ce que la déclaration signifie, c'est que, lorsque vous essayez d'accéder à une mémoire qui n'est pas la vôtre, c'est généralement parce que vous le faites avec un pointeur corrompu, qui vient d'ailleurs. C'est pourquoi il énonce l'indication.

Avec la corruption de la mémoire, la détection de l'erreur est rarement proche de la cause première de l'erreur. Et les effets sont exactement ce que vous décrivez, apparemment aléatoires. Vous aurez juste à regarder les coupables habituels, des choses comme:

• pointeurs non initialisés ou autres valeurs.
• écrire plus dans un tampon que sa taille.
• ressources partagées par des threads qui ne sont pas protégés par des mutex.

Travailler à rebours à partir d'un problème comme celui-ci pour trouver la cause racine est incroyablement difficile étant donné que tant de choses auraient pu se passer entre la création du problème et la détection du problème.

Je trouve surtout qu'il est plus facile de regarder ce qui est corrompu (par exemple, un pointeur spécifique), puis de faire une analyse statique manuelle du code pour voir ce qui aurait pu le corrompre, en vérifiant les coupables habituels, comme indiqué ci-dessus. Cependant, même cela n'attrapera pas de longues chaînes de problèmes.

Je ne connais pas assez VS pour le savoir, mais vous voudrez peut-être également examiner la possibilité d'utiliser un outil de suivi de la mémoire (comme valgrind pour Linux) pour voir s'il peut détecter des problèmes évidents.

Le code vérifiable ne devrait pas pouvoir corrompre la mémoire, il se passe donc quelque chose de dangereux. Utilisez-vous n'importe quel code dangereux n'importe où, comme dans le traitement de la mémoire tampon? En outre, les informations sur PInvoke peuvent ne pas être sans importance, car PInvoke implique une transition vers du code non managé et le marshaling associé.

Ma meilleure recommandation est de m'attacher à une instance en panne et d'utiliser WinDBG et SOS pour approfondir ce qui se passe au moment du crash. Ce n'est pas pour les âmes sensibles, mais à ce stade, vous devrez peut-être utiliser des outils plus puissants pour déterminer ce qui ne va pas exactement.

Ok, cela pourrait être assez inutile et simplement anecdotique, mais ...

Cette exception a été systématiquement levée par certaines bibliothèques Twain32 que nous utilisions dans mon projet, mais ne se produirait que sur ma machine.

J'ai essayé beaucoup de solutions suggérées partout sur Internet, en vain ... Jusqu'à ce que je débranche mon téléphone portable (il était connecté via USB).

Et ça a marché.

Il s'est avéré que les bibliothèques Twain32 essayaient de répertorier mon téléphone comme un appareil compatible Twain, et quelque chose qu'elle a fait dans ce processus a provoqué cette exception.

Allez comprendre...

J'ai eu cette erreur lors de l'utilisation de pinvoke sur une méthode qui prend une référence à un fichier StringBuilder. J'avais utilisé le constructeur par défaut qui n'alloue apparemment que 16 octets. Windows a essayé de mettre plus de 16 octets dans la mémoire tampon et a provoqué un dépassement de mémoire tampon.

Au lieu de

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

Utilisez une plus grande capacité:

StringBuilder windowText = new StringBuilder(3000);

dans mon cas, le fichier était ouvert et donc verrouillé.

Je l'obtenais en essayant de charger un fichier Excel à l'aide de LinqToExcel qui était également ouvert dans Excel.

c'est tout ce que j'ai fait

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

J'ai eu la même erreur dans un projet avec lequel je travaillais dans VB.NET. Cochez la case "Activer le cadre d'application" sur la page de propriétés l'a résolu pour moi.

J'ai eu ce problème également . J'exécutais différentes solutions en même temps à l'aide de Visual Studio, lors de la fermeture d'autres solutions et de l'exécution de la solution cible uniquement, cela fonctionnait bien sans cette erreur.

Vous avez obtenu cette erreur au hasard dans VS1017, lorsque vous essayez de créer un projet qui se construisait parfaitement bien la veille. Le redémarrage du PC a résolu le problème (j'ai également exécuté la commande suivante au préalable, je ne sais pas si c'est nécessaire: netsh winsock reset)

Ma réponse dépend beaucoup de votre scénario, mais nous avons eu un problème en essayant de mettre à niveau une application .NET pour un client qui avait> 10 ans afin qu'il puisse la faire fonctionner sous Windows 8.1. La réponse de @ alhazen était en quelque sorte dans le bon sens pour moi. L'application reposait sur une DLL tierce que le client ne voulait pas payer pour mettre à jour (Pegasus / Accusoft ImagXpress). Nous avons re-ciblé l'application pour .NET 4.5 mais à chaque exécution de la ligne suivante, nous avons reçu le AccessViolationException was unhandledmessage:

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

Pour y remédier, nous avons dû ajouter l'événement post-build suivant au projet:

call "$(DevEnvDir)..\tools\vsvars32.bat"
"C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\bin\amd64\editbin.exe" /NXCOMPAT:NO "$(TargetPath)"

Cela spécifie explicitement l'exécutable comme incompatible avec Data Execution Prevention. Pour plus de détails, cliquez ici .

Dans certains cas, cela peut se produire lorsque:

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

Dans mon cas, je devais référencer une bibliothèque C / C ++ en utilisant P / Invoke, mais je devais m'assurer que la mémoire était allouée au tableau de sortie en utilisant d'abord 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;
    }

Pour plus de détails, veuillez consulter: https://www.c-sharpcorner.com/article/pointers-in-C-Sharp/

Cela m'est arrivé lorsque je déboguais mon application C # WinForms dans Visual Studio. Mon application appelle des trucs Win32 via DllImport, par exemple

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

L'exécution de Visual Studio "en tant qu'administrateur" a résolu le problème pour moi.

J'ai eu le même message d'erreur:

System.AccessViolationException: tentative de lecture ou d'écriture de la mémoire protégée. Cela indique souvent qu'une autre mémoire est corrompue.

Dans mon cas, l'erreur a disparu après le nettoyage et la reconstruction de la solution.

Dans mon cas, l'utilitaire FTDI FT Prog lançait l'erreur lors de la recherche de périphériques USB. Le fait de débrancher mes écouteurs Bluetooth du PC a résolu le problème.

J'ai reçu ce message d'erreur sur l'expression lambda qui utilisait Linq pour filtrer une collection d'objets. Quand j'ai inspecté la collection, j'ai remarqué que ses membres n'étaient pas peuplés - dans la Localsfenêtre, les agrandir montrait juste "...". En fin de compte, le problème était dans la méthode de référentiel qui a initialement rempli la collection - Dapper essayait de mapper automatiquement une propriété d'un objet imbriqué. J'ai corrigé la requête Dapper pour gérer le multi-mappage et cela a corrigé l'erreur de mémoire.