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 trouvé 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 réussi à 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’access pourrait se produire sur certains logiciels qui utilisent la communication à distance, comme le mien, mais la violation d’access 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 stack:

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

J’ai installé 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) destiné à é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. Consultez la page 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 s’agit de 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.

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

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 la mémoire protégée. C’est souvent une indication que d’autres mémoires sont corrompues

Dans certains cas, l’ajout de “Option Ssortingct 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.

Dans mon cas, cela a été corrigé lorsque j’ai configuré “Activer les applications 32 bits” = True pour le pool d’applications dans le serveur IIS.

Dans mon cas, les fonts utilisées dans l’une des bibliothèques partagées n’étaient pas installées sur le système.

Le problème peut être dû à des DLL de plates-formes de construction mixtes dans le projet. C’est-à-dire que vous construisez votre projet sur n’importe quel processeur, mais que certaines de ces DLL sont déjà créées pour la plate-forme x86. Celles-ci provoqueront des pannes 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 architecture 32 bits x86 car il s’agit de la plus compatible.

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.

Lorsque j’ai ajouté la référence à mon projet, je recherchais le chemin P: \ Core , alors que j’avais ajouté le chemin c: \ core dans past dans l’environnement de chemin varaible.

Donc, mon code essayait d’abord le mauvais chemin. J’ai supprimé cela, annulé la référence de la DLL et ré-enregistré ma référence de DLL à l’aide de (regsvr32). J’espère que cela t’aides.

Salut Il y a deux raisons possibles.

  1. Nous avons du code non géré et nous l’appelons à partir du code géré. cela empêche d’exécuter ce code. essayez d’exécuter ces commandes et redémarrez votre ordinateur

    cmd: netsh winsock reset

Ouvrez cmd.exe et exécutez la commande "netsh winsock reset catalog"

  1. L’antivirus considère que le code non géré est dangereux et restreint l’exécution de ce code, désactive l’anti-virus , puis vérifie