Tentative de lecture ou d'écriture de la mémoire protégée
J'ai commencé à voir une exception AccessViolationException générée dans mon application à plusieurs endroits différents. Cela ne s'est jamais produit sur mon PC de développement, notre serveur de test. De plus, il ne s'est manifesté que sur l'un de nos 2 serveurs de production. Comme cela ne semblait se produire que sur l'un de nos serveurs de production, j'ai commencé à examiner les versions du framework .net installées sur les serveurs.
J'ai constaté que (pour une raison étrange), le serveur de production qui rencontrait des problèmes avait 2.0 sp2, 3.0 sp2 et 3.5 sp1, tandis que l'autre serveur de production et le serveur de test avaient 2.0 sp1.
Mon application ne cible que le framework 2.0, a décidé de désinstaller toutes les versions du framework du serveur de production et d’installer uniquement la version 2.0 sp1. Jusqu'à présent, je n'ai pas été capable de reproduire le problème. Très intéressant.
PC de développement: compact 2.0 sp2, compact 3.5, 2.0 sp2, 3.0 sp2, 3.5 sp1 Serveur d’essai: 2.0 sp1 Serveur de production1: 2.0 sp1 Serveur de production2: 2.0 sp2, 3.0 sp2, 3.5 sp1
Maintenant, pourquoi je ne peux pas reproduire le problème sur mon PC de développement qui a 2.0 sp2 dessus, je ne peux pas comprendre. J'ai entendu des rumeurs selon lesquelles cette violation d'accès pourrait se produire sur certains logiciels qui utilisent la communication à distance, comme le mien, mais la violation d'accès ne se produit jamais lorsque la communication à distance est en cours. Je n’accepte pour l’instant que l’utilisation de la version 2.0 sp1, mais j’aimerais vraiment savoir si quelqu'un a eu ce problème et s’il a trouvé une solution de contournement pour les nouvelles versions de frameowork.
Voici quelques exceptions et leurs traces de pile:
System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
at ICSharpCode.TextEditor.TextArea.HandleKeyPress(Char ch)
at ICSharpCode.TextEditor.TextArea.SimulateKeyPress(Char ch)
at ICSharpCode.TextEditor.TextArea.OnKeyPress(KeyPressEventArgs e)
at System.Windows.Forms.Control.ProcessKeyEventArgs(Message& m)
at System.Windows.Forms.Control.ProcessKeyMessage(Message& m)
at System.Windows.Forms.Control.WmKeyChar(Message& m)
at System.Windows.Forms.Control.WndProc(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
at System.Windows.Forms.UnsafeNativeMethods.CallWindowProc(IntPtr wndProc, IntPtr hWnd, Int32 msg, IntPtr wParam, IntPtr lParam)
at System.Windows.Forms.NativeWindow.DefWndProc(Message& m)
at System.Windows.Forms.Control.DefWndProc(Message& m)
at System.Windows.Forms.Control.WndProc(Message& m)
at System.Windows.Forms.TextBoxBase.WndProc(Message& m)
at System.Windows.Forms.RichTextBox.WndProc(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
J'ai eu le même problème . 2.0 a bien fonctionné. après avoir installé jusqu'à 3,5 sp1, l'application obtient une violation d'accès.
installed http://support.Microsoft.com/kb/971030 et mon problème est résolu même si je n'utilise pas LCG.
Microsoft a également publié un correctif logiciel (2 juillet 2007) pour éviter l’erreur "Tentative de lecture ou d’écriture de mémoire protégée" qui sévit depuis un certain temps sur la plate-forme .NET 2.0. Regardez http://support.Microsoft.com/kb/923028 - ne savez pas si cela s'applique à vous, mais pensez pouvoir le vérifier.
J'ai eu le même problème après la mise à niveau de .NET 4.5 à .NET 4.5.1. Ce qui a résolu le problème pour moi, c'était d'exécuter cette commande:
netsh winsock reset
Pour VS 2013, .NET Framework 4.5.1 a également un bogue AccessViolationException (KB2915689) lorsqu’il traite avec SQL Server/TCP Sockets. La mise à niveau vers .NET Framework 4.5.2 corrige ce problème.
Exception VS.NET AccessViolationException signalée
Tentative de lecture ou d'écriture de la mémoire protégée. Cela indique souvent qu'une autre mémoire est corrompue.
J'utilisais OLEDB et je suis passé à SQL Client, ce qui a résolu mon problème avec cette erreur.
Dans certains cas, l'ajout de "Option Strict On" dans VB.NET et la résolution de tous les problèmes détectés par un casting approprié ont résolu ce problème.
Assurez-vous de ne pas avoir de threads dans les threads. C'est ce qui a causé cette erreur pour moi. Voir ce lien: Tentative de lecture ou d’écriture de mémoire protégée. Cela indique souvent que l’autre mémoire est corrompue
Je reçois généralement le message "Tentative de lecture ou d'écriture de la mémoire protégée" lors de l'appel de la méthode "Show" sur certains fichiers WinForm. J'ai vérifié et il ne semble rien de spécial à propos de ces formulaires. Je ne sais pas pourquoi cela fonctionne (peut-être que quelqu'un peut me le dire), mais généralement, le fait de déplacer le code exécuté dans l'événement "Load" du formulaire vers l'événement "Shown" me permet de le réparer et je ne le vois plus jamais.
Dans mon cas, j'ai eu des problèmes avec les "variables d'environnement" lors de l'ajout d'une référence à ma DLL COM.
Quand j'ai ajouté la référence à mon projet, je cherchais P:\Core chemin, alors que j'avais ajouté le c:\core chemin dans le passé dans l'environnement de chemin varaible.
Donc, mon code essayait d'abord le mauvais chemin. J'ai supprimé cela, annulé la référence DLL et ré-enregistré ma DLL référence à l'aide de (regsvr32). J'espère que cela t'aides.
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. Par sécurité, essayez le regroupement pour une architecture 32 bits x86 car il s’agit de la plus compatible.
Dans mon cas, les polices utilisées dans l'une des bibliothèques partagées n'étaient pas installées sur le système.
Dans mon cas, cela a été corrigé lorsque j'ai configuré "Activer les applications 32 bits" = True pour le pool d'applications sur le serveur IIS.