Tentative de lecture ou d'écriture de la mémoire protégée. Cela indique souvent que d'autres mémoires sont corrompues
J'espère que quelqu'un pourra m'éclairer sur ce qui pourrait éventuellement causer 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 poster de code car cette erreur semble avoir été renvoyée dans une zone aléatoire de l'application. L'application fonctionnera n'importe où de 12 à 48 heures avant de générer l'erreur. Parfois, il s’arrête à un endroit apparemment aléatoire et jette l’erreur ci-dessus, d’autres fois, l’application tout entière s’arrête et j’obtiens un écran avec une erreur disant: bug dans le CLR ou ... "quelque chose à propos de PInvoke ou d'autres informations non pertinentes. Lorsque cela se produit, tous les threads s’arrêtent et aucune information de débogage n’est disponible.
En bref, voici ce que fait l'application:
C'est une application serveur multithread écrite entièrement en C #. Les clients se connectent au serveur via un socket. Le serveur exécute un "environnement" virtuel pour les clients, leur permettant d’interagir entre eux et avec l’environnement. Cela consomme un peu de mémoire mais je ne le vois pas fuir. Il consomme généralement environ 1,5 Go. Je ne pense pas que cela fuit parce que l'utilisation de la mémoire reste relativement constante pendant tout le temps que l'application est en cours d'exécution. Son code fonctionne constamment pour maintenir l'environnement même si les clients ne font rien. Il n'utilise aucun logiciel tiers ou autre API. Les seules ressources externes utilisées par cette application sont les connexions socket et les connexions à la base de données SQL. Son fonctionnement 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 finit toujours par se produire.
J'ai essayé de désactiver les optimisations du compilateur et plusieurs correctifs logiciels Microsoft. Rien ne semble faire disparaître ce problème. Il serait apprécié que quiconque connaisse les causes possibles, ou une sorte de moyen d'identifier ce qui cause le problème.
Enfin, nous avons trouvé cette solution à l’aide de WinDBG et de SOS. La violation d'accès a été généré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 ni l'un ni l'autre, j'ai donc rejeté cette idée. De plus, je partais du principe que ce n’était pas un problème 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 j'ai testé ceci fonctionnaient sous "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 duré très longtemps dans ma candidature.
Je viens de faire face à ce problème dans VS 2013 .NET 4.5 avec une DLL MapInfo. En fait, le problème est que j'ai changé la plate-forme pour la construction de x86 en n'importe quel processeur et que cela a été suffisant pour déclencher cette erreur. Remettre à x86 a fait le tour. Peut aider quelqu'un.
Essayez de lancer cette commande
netsh winsock réinitialiser
J'ai également rencontré ce problème avec Visual Studio 2010. Plus intéressant encore, ma solution comportait plusieurs projets (application console, application WPF, application Windows Forms), mais cela n'a échoué que lorsque j'ai défini le projet de type "Application console". "en tant que projet de démarrage (même pour ceux qui n’avaient littéralement aucun code ou des assemblages 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 d'application de la console -> Accédez à l'onglet Debug -> Accédez à la section Enable Debuggers dans le volet de droite -> Cochez la case Enable unmanaged code debugging comme indiqué dans l'instantané ci-dessous. La cause fondamentale de la raison pour laquelle c'est arrivé ne m'est toujours pas connue. La seule chose que j'ai constatée, c'est qu'il y avait beaucoup de mises à jour Windows installées sur ma machine la nuit précédente, principalement des mises à jour de bureau et des mises à jour de système d'exploitation (plus d'une douzaine d'articles de la Base de connaissances).
Le problème peut être dû à des DLL de plates-formes de construction mixtes dans le projet. Vous construisez votre projet sur N'importe quel processeur, mais vous avez déjà des DLL dans le projet créées pour la plate-forme x86. Celles-ci provoqueront des plantages aléatoires en raison de l’affectation différente de la mémoire des architectures 32 et 64 bits. Si toutes les DLL sont créées pour une plate-forme, le problème peut être résolu.
Cette erreur ne devrait 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 ça va aider.
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:
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 à ce projet.
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ù, par exemple 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 se connecter à une instance bloquée et d'utiliser WinDBG et SOS - pour approfondir la description de 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.
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 voudrais essayer de suggérer que votre code de filetage ne protège pas quelque part une collection (telle qu'un dictionnaire) avec un verrou approprié.
Quel système d'exploitation et service pack utilisez-vous?
Ok, cela pourrait être assez inutile et simplement anecdotique, mais ...
Certaines bibliothèques Twain32 que nous utilisions dans mon projet lançaient régulièrement cette exception, mais cela ne se produirait que sur ma machine.
J'ai essayé beaucoup de solutions suggérées partout sur Internet, mais en vain ... Jusqu'à ce que je débranche mon téléphone portable (il était connecté via USB).
Et ça a fonctionné.
Il s'est avéré que les bibliothèques Twain32 essayaient de répertorier mon téléphone en tant que périphérique compatible Twain. Cette opération a été provoquée par une exception.
Allez comprendre...
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 lançait la même exception lors de 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 de Oracle.DataAccess).
Ce problème 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 tous les jours et peut-être quelques-unes utilisent-elles votre code - quel morceau de code fait-il l'objet des meilleurs tests? Je vous garantis que, si cela posait un problème avec VS, nous l’aurions probablement déjà trouvé.
La déclaration signifie que lorsque vous essayez d'accéder à de 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 provient d'ailleurs. C'est pourquoi c'est l'indication.
Avec la corruption de 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 en arrière d'un problème comme celui-ci pour trouver la cause fondamentale 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 que est corrompu (par exemple, un pointeur spécifique), puis d'effectuer une analyse statique manuelle du code pour voir ce qui aurait pu le corrompre, en recherchant 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 le savoir, mais vous pouvez également envisager la possibilité d’utiliser un outil de suivi de la mémoire (tel que valgrind pour Linux) afin de déterminer s’il pouvait détecter des problèmes évidents.
dans mon cas, le fichier était ouvert et donc verrouillé.
Je l'obtenais lorsque j'essayais de charger un fichier Excel avec LinqToExcel qui était également ouvert dans Excel.
c'est tout ce que j'ai cédé
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'avais ce problème aussi . J'utilisais différentes solutions simultanément avec Visual Studio, lors de la fermeture d'autres solutions et de l'exécution de la solution cible uniquement, cela fonctionnait sans problème.
J'ai eu la même erreur dans un projet avec lequel je travaillais dans VB.NET. Le fait de cocher la case "Activer le cadre d'application" sur la page des propriétés m'a résolu le problème.
J'ai eu cette erreur en utilisant pinvoke sur une méthode qui prend une référence à un 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(); // Likely overflow of default capacity of 16
Utilisez une plus grande capacité:
StringBuilder windowText = new StringBuilder(3000);
Dans certains cas, cela peut arriver lorsque:
obj = new obj();
...
obj.Dispose(); // <----------------- Incorrect disposal causes it
obj.abc...
Ma réponse dépend beaucoup de votre scénario, mais nous avons rencontré un problème lorsque nous avons essayé de mettre à niveau une application .NET pour un client de plus de 10 ans, afin que cela puisse fonctionner sous Windows 8.1. La réponse de @ alhazen était assez bonne pour moi. L'application s'appuyait sur un tiers DLL que le client ne voulait pas payer pour mettre à jour (Pegasus/Accusoft ImagXpress). Nous avons redirigé l'application pour .NET 4.5, mais chaque fois que la ligne suivante s'est exécutée, nous avons reçu le message AccessViolationException was unhandled:
UnlockPICImagXpress.PS_Unlock (1908228217,373714400,1341834561,28447);
Pour résoudre ce problème, nous avons dû ajouter l'événement suivant à la construction 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 que l'exécutable est incompatible avec Data Execution Prevention. Pour plus de détails, voir ici .
Dans mon cas, je devais faire référence à une bibliothèque C/C++ à l'aide de 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/
Vous avez cette erreur au hasard dans VS1017, lorsque vous essayez de construire un projet parfaitement en construction la veille. Le redémarrage du PC a corrigé le problème qui fonctionnait (j'ai également exécuté la commande suivante au préalable, ne sachant pas si cela est nécessaire: netsh winsock reset)