Tentative de lecture ou d'écriture d'une mémoire protégée. C'est souvent une indication que d'autres mémoires sont corrompues.

Question

J'espère que quelqu'un pourra m'éclairer sur ce qui pourrait causer cette erreur :

Tentative de lecture ou d'écriture d'une mémoire protégée. C'est souvent une indication que d'autres mémoires sont corrompues.

Je ne peux pas vraiment afficher de code car cette erreur semble se produire dans n'importe quelle zone de l'application. L'application fonctionne entre 12 et 48 heures avant de déclencher l'erreur. Parfois, elle s'arrête à un endroit apparemment aléatoire et affiche l'erreur ci-dessus, d'autres fois, l'application entière s'arrête et j'obtiens un écran avec une erreur qui dit quelque chose du genre "There was a fatal error in...". Il peut s'agir d'un bogue 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 bref, voici ce que fait l'application :

Il s'agit d'une application serveur multi-threads entièrement écrite en C#. Les clients se connectent au serveur via un socket. Le serveur exécute un "environnement" virtuel pour les clients où ils peuvent interagir entre eux et avec l'environnement. Il consomme pas mal de mémoire mais je ne le vois pas fuir. Il consomme généralement environ 1,5 Go. Je ne pense pas qu'il y ait de fuite car l'utilisation de la mémoire reste relativement constante tout au long de l'exécution de l'application. Elle exécute constamment du code pour maintenir l'environnement, même si les clients ne font rien. Elle n'utilise aucun logiciel tiers ni aucune autre API. Les seules ressources extérieures que cette application utilise sont les connexions aux sockets et aux bases de données SQL. Elle fonctionne sur un serveur 64 bits. J'ai essayé de déboguer ce problème dans VS2008 et VS2010 en utilisant .net 2.0, 3.5 et 4.0 et sur plusieurs serveurs et le problème finit toujours par se produire.

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

Answer 1

Je viens de rencontrer 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'avais changé la plateforme de construction de x86 à Any CPU et que cela avait suffi pour déclencher cette erreur. En le remettant à x86, cela a fonctionné. Cela pourrait aider quelqu'un.

Answer 2

J'ai fini par le retrouver avec l'aide de WinDBG et SOS. Une violation d'accès était lancée par une DLL inconnue. Il s'avère qu'un logiciel appelé "Nvidia Network Manager" causait les problèmes. J'avais lu un nombre incalculable de fois que ce problème pouvait être causé par des pare-feu ou des antivirus, que je n'utilise pas, donc j'ai écarté cette idée. J'ai également supposé que ce problème n'était pas environnemental car il se produit sur plus d'un serveur utilisant du matériel différent. Il s'avère que toutes les machines sur lesquelles j'ai testé ce problème utilisaient "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 a pesé sur ma demande pendant très longtemps.

Answer 3

Essayez d'exécuter cette commande

netsh winsock reset

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

Answer 4

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

Après avoir essayé plusieurs choses, y compris l'installation de hotfixes, 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.

Answer 5

Ce problème est presque invariablement simple. Le code est mauvais. Il s'agit rarement des outils, d'après une analyse statistique. Des millions de personnes utilisent Visual Studio chaque jour et peut-être quelques-unes utilisent-elles votre code - quelle partie du code est la mieux testée ? Je vous garantis que, si c'était un problème avec VS, nous l'aurions probablement déjà trouvé.

Cette déclaration signifie 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 provient d'un autre endroit. C'est pourquoi l'indication est donnée.

Dans le cas de la corruption de la mémoire, la capture 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. Il vous suffit de regarder les coupables habituels, des choses comme :

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

Travailler à l'envers à partir d'un problème comme celui-ci pour trouver la cause fondamentale, c'est incroyablement difficile étant donné que tant de choses ont pu se passer entre la création du problème et sa détection.

Je trouve que c'est plus facile de jeter un coup d'oeil à ce que est corrompu (par exemple, un pointeur spécifique) et ensuite faire une analyse statique manuelle du code pour voir ce qui a pu le corrompre, en vérifiant les coupables habituels comme indiqué ci-dessus. Cependant, même cela ne permet pas de détecter de longues chaînes de problèmes.

Je ne suis pas assez familier avec VS pour le savoir, mais vous pouvez également envisager 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.