Vous avez tenté de lire ou d’écrire de la mémoire protégée. C’est souvent une indication que la mémoire est corrompue

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

Vous avez tenté de lire ou d’écrire de la 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 une zone aléatoire de l’application. L’application fonctionnera de 12 à 48 heures avant de lancer l’erreur. Parfois, il s’arrête dans un endroit apparemment aléatoire et lance l’erreur ci-dessus, d’autres fois l’application s’arrête et j’obtiens un écran avec une erreur qui dit quelque chose comme “Il y a eu une erreur fatale dans … Cela peut être une erreur.” bogue dans le CLR ou … “quelque chose à propos de PInvoke ou d’autres informations non pertinentes. Lorsque cela se produit, toutes les discussions sont terminées et aucune information de débogage n’est disponible.

En bref, c’est ce que fait l’application:

C’est une application de serveur multithread écrite entièrement en C #. Les clients se connectent au serveur via le socket. Le serveur exécute un “environnement” virtuel pour les clients où ils peuvent interagir entre eux et avec l’environnement. Cela consum pas mal de mémoire mais je ne le vois pas fuir. Il consum généralement environ 1,5 Go. Je ne pense pas que cela fuit parce que l’utilisation de la mémoire rest relativement constante tout le temps que l’application est en cours d’exécution. Son code en permanence 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 socket et les connexions à la firebase database 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.0 et sur plusieurs serveurs et le problème persiste finalement.

J’ai essayé de désactiver les optimisations du compilateur et plusieurs correctifs Microsoft. Rien ne semble faire disparaître ce problème. Il serait apprécié si quelqu’un connaît des 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 que cela suffisait pour déclencher cette erreur. Changer en x86 a fait l’affaire. Peut aider quelqu’un.

Finalement, suivi avec l’aide de WinDBG et SOS. La violation d’access était lancé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 je n’utilise pas, alors j’ai rejeté cette idée. En outre, je pensais que ce n’était pas environnemental car il se produit sur plus d’un serveur utilisant un matériel différent. Il s’avère que toutes les machines sur lesquelles je l’ai testé fonctionnaient avec “NVidia Network Manager”. Je crois qu’il installe avec le rest des pilotes de la carte mère.

Avec un peu de chance, cela aide quelqu’un, car ce problème a affligé mon application pendant très longtemps.

Essayez d’exécuter cette commande

netsh winsock reset

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

J’ai également rencontré ce problème avec Visual Studio 2010. Plus intéressant encore, ma solution contenait plusieurs projets (application console, application WPF, application Windows Forms) mais elle échouait uniquement lorsque je définissais le projet de type “Application console”. “en tant que projet de démarrage (même pour ceux qui n’avaient littéralement aucun code ni aucun assemblage supplémentaire, sauf ceux qui sont fournis avec le modèle de projet lui-même).

Les modifications suivantes m’ont finalement aidé à résoudre le problème: Accédez aux propriétés du projet d’application de la console -> Cliquez sur l’onglet Debug -> Enable Debuggers section Enable Debuggers dans le volet droit – Cochez la Enable unmanaged code debugging au dessous de. La cause fondamentale de ce qui s’est produit n’est toujours pas connue. La seule chose que j’ai observée était qu’il y avait beaucoup de mises à jour Windows qui s’étaient installées sur ma machine la nuit précédente et qui consistaient principalement en des mises à jour bureautiques et des mises à jour du système d’exploitation (plus d’une douzaine d’articles).

entrer la description de l'image ici

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 certaines DLL sont déjà intégrées au projet pour la plate-forme x86. Celles-ci provoqueront des pannes aléatoires en raison de la cartographie mémoire différente 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.

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

Accédez à Visual Studio Debugger pour contourner cette exception:

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

J’espère que ça va aider.

J’ai eu ce problème récemment lorsque j’ai changé le serveur de développement pour un projet. Je recevais 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é sur une nouvelle machine, je vous suggère de renouveler toutes les références ajoutées à ce projet.

J’ai rencontré et trouvé une ré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

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

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

Quel système d’exploitation et service pack exécutez-vous?

J’ai fait face au même problème. Mon code était une DLL .NET (extension AutoCAD) exécutée dans AutoCAD 2012. J’utilise également Oracle.DataAccess et mon code émettait la même exception pendant ExecuteNonQuery (). J’ai heureusement résolu ce problème en modifiant la version .net de l’ODP que j’utilisais (c’est-à-dire, 2.x d’Oracle.DataAccess)

Ok, ça pourrait être plutôt inutile et simplement anecdotique, mais …

Cette exception a été lancée de manière cohérente par certaines bibliothèques Twain32 que nous utilisions dans mon projet, mais ne se produirait que dans ma machine.

J’ai essayé beaucoup de solutions proposées sur Internet, en vain … jusqu’à ce que je détwig mon téléphone portable (il était connecté via le port USB).

Et ça a marché.

Il s’avère que les bibliothèques Twain32 essayaient de répertorier mon téléphone en tant que périphérique compatible Twain, et quelque chose qu’il a fait lors de ce processus a provoqué cette exception.

Allez comprendre…

Ce problème est presque toujours simple. Le code est mauvais. Ce sont rarement les outils, juste à partir d’une parsing statistique. Des millions de personnes utilisent Visual Studio tous les jours et peut-être quelques-unes utilisent-elles votre code – quel bit obtient le meilleur test? Je garantis que si cela posait 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 à la 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 indique l’indication.

Avec la corruption de mémoire, la capture de l’erreur est rarement à l’origine de l’erreur. Et les effets sont exactement ce que vous décrivez, apparemment aléatoire. 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 à partir d’un problème comme celui-ci pour trouver la cause est extrêmement difficile, car il s’est passé tellement de choses entre la création du problème et la détection du problème.

Je trouve surtout que c’est plus facile de regarder ce qui est corrompu (disons un pointeur spécifique) et ensuite de faire une parsing 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 ne va pas attraper de longues chaînes de problèmes.

Je ne connais pas suffisamment VS pour savoir, mais vous voudrez peut-être aussi 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.

Le code vérifiable ne devrait pas pouvoir corrompre la mémoire, il y a donc quelque chose de dangereux. Utilisez-vous un code non sécurisé n’importe où, comme dans le traitement des tampons? En outre, les informations sur PInvoke peuvent ne pas être pertinentes, car PInvoke implique une transition vers du code non géré et un marshaling associé.

Ma meilleure recommandation est d’attacher à une instance en panne et d’utiliser WinDBG et SOS pour mieux comprendre ce qui se passe au moment de la panne. Ce n’est pas pour les faibles de cœur, mais à ce stade, vous devrez peut-être sortir des outils plus puissants pour déterminer exactement ce qui ne va pas.

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

Je l’ai eu en essayant de charger un fichier Excel en utilisant LinqToExcel qui a également été ouvert dans Excel.

c’est tout ce que j’ai fait

  var maps = from f in book.Worksheet() select f; try { foreach (var m in maps) if (!ssortingng.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 ce problème également . J’exécutais différentes solutions en même temps en utilisant Visual Studio, lorsque je fermais d’autres solutions et exécutais uniquement la solution cible, cela fonctionnait parfaitement sans cette erreur.

J’ai eu la même erreur dans un projet avec lequel je travaillais dans VB.NET. En cochant la case “Activer le framework d’application” sur la page de propriétés, je l’ai résolue.

Ma réponse dépend beaucoup de votre scénario, mais nous avons rencontré un problème en essayant de mettre à niveau une application .NET pour un client de plus de 10 ans afin de pouvoir le faire fonctionner sous Windows 8.1. La réponse de @ alhazen était en quelque sorte dans mon camp. L’application s’appuyait sur une DLL tierce que le client ne souhaitait pas payer pour la mise à jour (Pegasus / Accusoft ImagXpress). Nous avons redéfini l’application pour .NET 4.5, mais chaque fois que la ligne suivante exécutée, nous avons reçu AccessViolationException was unhandled nous avons reçu un message AccessViolationException was unhandled :

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

Pour y remédier, nous avons dû append 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 la prévention de l’exécution des données. Pour plus de détails, voir ici .