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


144

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.


s'il vous plaît poster la pile complète des appels ...
Mitch Wheat


Environ la moitié du temps, je ne peux pas obtenir la pile d'appels. S'il génère l'erreur d'exécution fatale, il n'y a aucune information de débogage. Les fois où il s'arrête quelque part dans le code, rien ne semble anormal. J'ai même parcouru tous les threads actifs et je n'ai rien vu qui puisse causer un conflit. Je suppose que la corruption de la mémoire s'est produite un certain temps avant de générer l'erreur.
Someone Else

Vérifiez les vieux composants COM et ActiveX de merde utilisés. Je sais aussi que SQLCE craps out comme celui-ci dans un environnement multithread.
leppie

Il n'y a aucun composant COM ou ActiveX.
Someone Else

Réponses:


50

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.


1
comment l'avez-vous changé avec x86. Je fais juste face au même problème avec cette instruction CSingleLock lock(&m_csMember, TRUE);. Pour plus de détails, voici mon article
ABCmo

Dans VS 2012/2013, allez dans Propriétés du projet-> Construire et modifiez "Platform Target" en fonction de vos besoins. Bien que je pense qu'il y a un autre endroit où vous pouvez changer cela, mais je n'arrive pas à le trouver, je pense que les deux méthodes devraient aboutir au même résultat.
Sergey

J'utilise actuellement VS 2013, et il est configuré comme x86: /
ABCmo

1
Votre problème peut être causé par beaucoup de choses, j'ai été vraiment surpris d'avoir résolu mon problème en modifiant la plate-forme de construction. Vous pourriez dire une évasion chanceuse.
Sergey

Cette solution en combinaison avec cette réponse l'a résolu pour moi.
Zach Posten

23

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).

entrez la description de l'image ici

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

entrez la description de l'image ici


1
À partir de VS 2017, il a été renommé " Activer le débogage du code natif "
Chiramisu

1
Merci @Chiramisu pour avoir fourni des informations à jour et aidé la communauté. J'ai mis à jour la réponse pour l'adapter aux nouvelles versions de Visual Studio.
RBT le

19

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.


1
dans mon cas, lorsque je lis fréquemment des données à partir de l'appareil, son erreur de lancement, j'ai arrêté le fil pendant un certain temps en utilisant Thread.Sleep (1000) pour la lecture suivante. et fonctionne parfaitement.
JRB

6
J'aurais supposé que le remède était "désinstaller NVidia Network Manager"
paulm

79
La plupart des réponses votées ne fournissent aucune réponse logique.
Teoman shipahi

Je doute d'avoir quelque chose lié à nvidia dans ma carte mère ou mon logiciel. J'utilise Visual Studio 2010. Le problème se produit uniquement lors du débogage du projet à partir de VS. Son exe de sortie du dossier de débogage fonctionne parfaitement.
RBT

1
J'accède aux threads de mon propre processus qui causent le problème.
Muhammad Saqib

13

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.



8

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.


3
Je suis désolé que cela n'ait pas fonctionné pour vous. Cette erreur est soulevée pour de nombreuses raisons, j'ai pensé que la solution que j'ai publiée peut résoudre le problème pour quelqu'un d'autre si la raison est l'optimisation JIT.
curiousBoy

6

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


5

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?


1
Exécution de XP 64 SP2. Cela s'est cependant produit sur plusieurs serveurs. J'ai tout traversé tant de fois et je ne vois rien qui ne soit pas sûr pour les threads. Ne recevrais-je pas non plus une erreur de modification de collection plutôt qu'une viloation d'accès?
Quelqu'un d'autre

5

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.


4

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


2
Je ne suis pas sûr que ce soit une bonne idée. Cela pourrait bien retarder le crash, mais au prix de faire plus de dégâts. Je pense que la meilleure idée, si vous vous
écrasez

1
La désactivation de DEP n'est pas judicieuse mais constitue un exercice de diagnostic utile.
vcsjones

4

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)


Je suis confronté au même problème - autocad .net dll - pouvez-vous expliquer quel était le problème et le résoudre?
BKSpurgeon

3

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.


3
Vous pouvez également obtenir un pointeur corrompu à partir d'une mauvaise mémoire. Si cela ne se produit pas sur un serveur avec mémoire ECC, essayez un utilitaire de test de mémoire de longue durée pour éliminer le matériel comme cause.
cdonner

12
Je sais que ce n'est pas un problème matériel car cela se produit sur plusieurs serveurs. Merci d'avoir indiqué qu'il y a quelque chose de mauvais dans le code capitaine évident. Je ne blâme pas le studio visuel. Comme indiqué, l'application fonctionne correctement pendant une période aléatoire. Ce n'est pas facile à reproduire et j'essaie d'identifier le problème depuis des semaines maintenant.
Someone Else

5
@Someone Else: Je ne pense pas que les insultes vous aideront beaucoup.
Mitch Wheat

2
@Someone Else, j'ai aidé autant que je peux compte tenu des informations limitées que vous avez fournies. Même le meilleur médecin du monde ne peut pas faire grand-chose avec un patient qui déclare simplement «j'ai mal» :-) Si vous souhaitez fournir des informations plus spécifiques, nous pouvons peut-être vous aider davantage.
paxdiablo

5
Mauvaise réponse, mais approche, spéculation éhontée, hypothèses injustifiées, aucune solution fournie ... Pourquoi cette réponse est-elle toujours d'actualité? Et qu'est-ce que 3 personnes auraient pu voter pour cette réponse?
ThunderGr

3

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.


Il mentionne PInvoke comme une cause possible dans le message d'erreur. Il n'y a pas de code dangereux. Je vais essayer WinDBG. Merci.
Someone Else

3

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...


3

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

2

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

2

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.


1

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.


1

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)


1
C'est exactement ma situation avec VS 2017 - 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. J'ai simplement redémarré le PC pour résoudre ce problème sans rien faire d'autre.
Hong

0

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 .


0

Dans certains cas, cela peut se produire lorsque:

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

0

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/


0

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.


0

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.


0

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.


0

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.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.