Es wurde versucht, geschützten Speicher zu lesen oder zu schreiben. Dies ist häufig ein Hinweis darauf, dass der andere Speicher beschädigt ist

Ich hoffe, jemand kann mich aufklären, was diesen Fehler möglicherweise verursachen könnte:

Es wurde versucht, geschützten Speicher zu lesen oder zu schreiben. Dies ist häufig ein Hinweis darauf, dass der andere Speicher beschädigt ist.

Ich kann die Postleitzahl nicht wirklich posten, da dieser Fehler in einem beliebigen Bereich der Anwendung ausgelöst zu werden scheint. Die Anwendung wird zwischen 12 und 48 Stunden ausgeführt, bevor der Fehler ausgelöst wird. Manchmal stoppt es an einer scheinbar zufälligen Stelle und wirft den obigen Fehler aus, manchmal stoppt die gesamte Anwendung und ich erhalte einen Bildschirm mit einem Fehler, der etwas in der Art von "Es gab einen schwerwiegenden Fehler in ... Dies kann ein Fehler sein Fehler in der CLR oder ... "etwas über PInvoke oder andere nicht relevante Informationen. In diesem Fall werden alle Threads beendet und es sind keine Debugging-Informationen verfügbar.

Kurz gesagt, dies ist, was die Anwendung tut:

Es ist eine Multithread-Serveranwendung, die vollständig in C # geschrieben ist. Clients stellen über Socket eine Verbindung zum Server her. Der Server führt eine virtuelle "Umgebung" für die Clients aus, in der sie miteinander und mit der Umgebung interagieren können. Es verbraucht ziemlich viel Speicher, aber ich sehe es nicht undicht. Es verbraucht normalerweise ungefähr 1,5 GB. Ich glaube nicht, dass es undicht ist, da die Speichernutzung während der gesamten Laufzeit der Anwendung relativ konstant bleibt. Es wird ständig Code ausgeführt, um die Umgebung zu erhalten, auch wenn die Clients nichts tun. Es werden keine Software von Drittanbietern oder andere APIs verwendet. Die einzigen externen Ressourcen, die diese Anwendung verwendet, sind Socket-Verbindungen und SQL-Datenbankverbindungen. Es läuft auf einem 64-Bit-Server. Ich habe versucht, dies in VS2008 und VS2010 mit .net 2.0, 3.5 und 4 zu debuggen.

Ich habe versucht, Compiler-Optimierungen und mehrere Microsoft-Hotfixes zu deaktivieren. Nichts scheint dieses Problem zu lösen. Es wäre dankbar, wenn jemand mögliche Ursachen kennt oder auf irgendeine Weise herausfinden könnte, was das Problem verursacht.

Ich habe dieses Problem gerade in VS 2013 .NET 4.5 mit einer MapInfo-DLL konfrontiert. Es stellte sich heraus, dass das Problem darin bestand, dass ich die Platform for Build von x86 auf Any CPU geändert habe und dies ausreichte, um diesen Fehler auszulösen. Das Zurücksetzen auf x86 hat den Trick getan. Könnte jemandem helfen.

Dieses Problem trat auch bei Visual Studio (VS) 2010 auf. Interessanterweise hatte ich mehrere Projekte in meiner Lösung (Konsolenanwendung, WPF-Anwendung, Windows Forms-Anwendung), die jedoch nur fehlschlugen, wenn ich den Typ "Konsolenanwendung" festlegte des Projekts als Startprojekt der Lösung (auch für diejenigen, die buchstäblich keinen Code oder zusätzliche Assemblys hatten, auf die verwiesen wird, abgesehen von den Standard-Assemblys, die mit der Projektvorlage selbst geliefert werden).

Die folgende Änderung hat mir schließlich geholfen, das Problem zu beheben: Gehen Sie zu den Projekteigenschaften des Konsolenanwendungsprojekts (Alternativ wählen Sie die Projektdatei im Lösungs-Explorer aus und drücken Sie die Alt+ EnterTastenkombination) -> Gehe zur DebugRegisterkarte -> Scrollen Sie zum Enable DebuggersAbschnitt im rechten Bereich -> Überprüfen Enable unmanaged code debuggingAktivieren Sie das Kontrollkästchen (siehe Abbildung unten) -> Klicken Sie Floppyin der Symbolleiste auf die Schaltfläche, um die Projekteigenschaften zu speichern. Die Ursache dafür ist mir noch nicht bekannt. Ich habe nur festgestellt, dass in der vergangenen Nacht viele Windows-Updates auf meinem Computer installiert wurden, die hauptsächlich aus Office-Updates und Betriebssystem-Updates bestanden (mehr als ein Dutzend KB-Artikel).

Update : Ab VS 2017 hat sich der Einstellungsname wie im folgenden Screenshot gezeigt geändert:

Schließlich mit Hilfe von WinDBG und SOS aufgespürt. Die Zugriffsverletzung wurde von einer unbekannten DLL ausgelöst. Es stellte sich heraus, dass eine Software namens "Nvidia Network Manager" die Probleme verursachte. Ich habe unzählige Male gelesen, wie dieses Problem durch Firewalls oder Antivirenprogramme verursacht werden kann, von denen ich keines verwende. Daher habe ich diese Idee verworfen. Außerdem ging ich davon aus, dass es sich nicht um eine Umgebung handelt, da es auf mehr als einem Server mit unterschiedlicher Hardware auftritt. Es stellte sich heraus, dass auf allen Computern, auf denen ich dies getestet habe, "NVidia Network Manager" ausgeführt wurde. Ich glaube, es wird mit dem Rest der Motherboard-Treiber installiert.

Hoffentlich hilft dies jemandem, da dieses Problem meine Bewerbung sehr lange plagte.

Das Problem kann auf DLLs mit gemischten Build-Plattformen im Projekt zurückzuführen sein. dh Sie erstellen Ihr Projekt auf einer beliebigen CPU, haben jedoch einige DLLs im Projekt, die bereits für die x86-Plattform erstellt wurden. Diese verursachen zufällige Abstürze aufgrund unterschiedlicher Speicherzuordnungen der 32-Bit- und 64-Bit-Architektur. Wenn alle DLLs für eine Plattform erstellt wurden, kann das Problem gelöst werden.

Versuchen Sie, diesen Befehl auszuführen

Netsh Winsock Reset

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

Dieser Fehler sollte im verwalteten Code nicht auftreten. Dies könnte das Problem lösen:

Wechseln Sie zu Visual Studio Debugger, um diese Ausnahme zu umgehen:

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

Hoffe es wird helfen.

Ich bin auf diese Ausnahme gestoßen und habe heute eine Lösung gefunden. Es trat auf, als ich versuchte, einen Unit-Test (NUnit) zu debuggen, der eine virtuelle Methode für eine abstrakte Klasse aufrief.

Das Problem scheint bei der Installation von .NET 4.5.1 zu liegen.

Ich habe .NET 4.5.2 heruntergeladen und installiert (meine Projekte verweisen immer noch auf .NET 4.5.1) und das Problem wurde behoben.

Quelle der Lösung:

https://connect.microsoft.com/VisualStudio/feedback/details/819552/visual-studio-debugger-throws-accessviolationexception

Es könnte Hardware sein. Es könnte etwas Kompliziertes sein ... aber ich würde versuchen zu behaupten, dass Ihr Threading-Code irgendwo eine Sammlung (wie ein Wörterbuch) nicht mit einer geeigneten Sperre schützt.

Welches Betriebssystem und Service Pack verwenden Sie?

Ich hatte dieses Problem kürzlich, als ich den Entwicklungsserver für ein Projekt geändert habe. Ich habe diesen Fehler in der Codezeile erhalten, in der ich eine neue OracleConnection-Variable deklariert habe.

Nachdem ich viele Dinge ausprobiert hatte, einschließlich der Installation von Hotfixes, habe ich versucht, die Referenzen Oracle.DataAccess und System.Data.OracleClient im Projekt zu ändern, und es hat funktioniert!

Wenn ein Projekt auf einen neuen Computer verschoben wird, sollten Sie alle in diesem Projekt hinzugefügten Referenzen erneuern.

Haben Sie versucht, DEP (Data Execution Prevention) für Ihre Anwendung zu deaktivieren?

Ich stand vor dem gleichen Problem. Mein Code war eine .NET-DLL (AutoCAD-Erweiterung), die in AutoCAD 2012 ausgeführt wurde. Ich verwende auch Oracle.DataAccess und mein Code hat während ExecuteNonQuery () dieselbe Ausnahme ausgelöst. Zum Glück habe ich dieses Problem gelöst, indem ich die .net-Version des von mir verwendeten ODP geändert habe (dh 2.x von Oracle.DataAccess).

Dieses Problem ist fast immer einfach. Der Code ist schlecht. Es sind selten die Werkzeuge, nur aus einer statistischen Analyse. Unzählige Millionen von Menschen verwenden Visual Studio jeden Tag und vielleicht einige verwenden Ihren Code - welcher Code wird besser getestet? Ich garantiere, wenn dies ein Problem mit VS wäre, hätten wir es wahrscheinlich bereits gefunden.

Wenn Sie versuchen, auf Speicher zuzugreifen, der nicht Ihnen gehört, liegt dies normalerweise daran, dass Sie dies mit einem beschädigten Zeiger tun, der von einem anderen Ort stammt. Deshalb wird die Angabe angegeben.

Bei einer Speicherbeschädigung liegt das Abfangen des Fehlers selten in der Nähe der Grundursache des Fehlers. Und die Effekte sind genau das, was Sie beschreiben, scheinbar zufällig. Sie müssen sich nur die üblichen Schuldigen ansehen, Dinge wie:

• nicht initialisierte Zeiger oder andere Werte.
• Schreiben mehr in einen Puffer als seine Größe.
• Ressourcen, die von Threads gemeinsam genutzt werden, die nicht durch Mutexe geschützt sind.

Von einem solchen Problem rückwärts zu arbeiten, um die Grundursache zu finden, ist unglaublich schwierig, da zwischen der Entstehung des Problems und der Erkennung des Problems so viel hätte passieren können.

Ich finde es meistens einfacher, einen Blick darauf zu werfen, was ist beschädigt (z. B. einen bestimmten Zeiger), und dann eine manuelle statische Analyse des Codes durchzuführen, um festzustellen, was ihn möglicherweise beschädigt hat, und nach den üblichen Schuldigen zu suchen, wie oben gezeigt. Selbst dies wird jedoch keine langen Problemketten verursachen.

Ich bin mit VS nicht vertraut genug, um es zu wissen, aber Sie sollten auch die Möglichkeit prüfen, ein Speicher-Tracking-Tool (wie valgrind für Linux) zu verwenden, um festzustellen, ob es offensichtliche Probleme erkennen kann.

Überprüfbarer Code sollte nicht in der Lage sein, den Speicher zu beschädigen, daher ist etwas Unsicheres im Gange. Verwenden Sie irgendwo unsicheren Code, beispielsweise bei der Pufferverarbeitung? Außerdem ist das Material zu PInvoke möglicherweise nicht irrelevant, da PInvoke einen Übergang zu nicht verwaltetem Code und das damit verbundene Marshalling beinhaltet.

Meine beste Empfehlung ist, eine Verbindung zu einer abgestürzten Instanz herzustellen und WinDBG und SOS zu verwenden, um tiefer in die Ereignisse zum Zeitpunkt des Absturzes einzudringen . Dies ist nichts für schwache Nerven, aber an diesem Punkt müssen Sie möglicherweise leistungsfähigere Tools ausbrechen, um festzustellen, was genau falsch läuft.

Ok, das könnte ziemlich nutzlos und einfach anekdotisch sein, aber ...

Diese Ausnahme wurde von einigen Twain32-Bibliotheken, die wir in meinem Projekt verwendeten, konsistent ausgelöst, trat jedoch nur auf meinem Computer auf.

Ich habe viele Lösungsvorschläge über das Internet ausprobiert, ohne Erfolg ... Bis ich mein Handy aus der Steckdose gezogen habe (es wurde über USB angeschlossen).

Und es hat funktioniert.

Es stellte sich heraus, dass die Twain32-Bibliotheken versuchten, mein Telefon als Twain-kompatibles Gerät aufzulisten, und etwas, das es in diesem Prozess tat, verursachte diese Ausnahme.

Stelle dir das vor...

Ich habe diesen Fehler erhalten, wenn ich pinvoke für eine Methode verwendet habe, die auf a verweist StringBuilder. Ich hatte den Standardkonstruktor verwendet, der anscheinend nur 16 Bytes zuweist. Windows hat versucht, mehr als 16 Bytes in den Puffer zu stellen, und einen Pufferüberlauf verursacht.

Anstatt

StringBuilder windowText = new StringBuilder(); // Probable overflow of default capacity (16)

Verwenden Sie eine größere Kapazität:

StringBuilder windowText = new StringBuilder(3000);

In meinem Fall war die Datei geöffnet und daher gesperrt.

Ich habe es bekommen, als ich versucht habe, eine Excel-Datei mit LinqToExcel zu laden, die auch in Excel geöffnet wurde.

Das ist alles, was ich getan habe

    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);
    }

Ich habe den gleichen Fehler in einem Projekt erhalten, mit dem ich in VB.NET gearbeitet habe. Das Überprüfen des "Anwendungsframeworks aktivieren" auf der Eigenschaftenseite hat es für mich gelöst.

Ich hatte auch dieses Problem. Ich habe verschiedene Lösungen gleichzeitig mit Visual Studio ausgeführt. Wenn ich andere Lösungen schloss und nur die Ziellösung ausführte, funktionierte dies ohne diesen Fehler einwandfrei.

Ich habe diesen Fehler zufällig in VS1017 erhalten, als ich versucht habe, ein Projekt zu erstellen, das am Tag zuvor einwandfrei funktioniert hat. Durch einen Neustart des PCs wurde das Problem behoben (ich habe zuvor auch den folgenden Befehl ausgeführt, nicht sicher, ob er erforderlich ist: Netsh Winsock Reset)

Meine Antwort hängt sehr stark von Ihrem Szenario ab, aber wir hatten ein Problem beim Versuch, eine .NET-Anwendung für einen Client zu aktualisieren, der älter als 10 Jahre war, damit sie unter Windows 8.1 funktioniert. @ alhazens Antwort war für mich irgendwie im richtigen Stadion. Die Anwendung stützte sich auf eine DLL eines Drittanbieters, für deren Aktualisierung der Client nicht bezahlen wollte (Pegasus / Accusoft ImagXpress). Wir haben die Anwendung für .NET 4.5 neu ausgerichtet, aber jedes Mal, wenn die folgende Zeile ausgeführt wurde, haben wir die folgende AccessViolationException was unhandledNachricht erhalten:

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

Um dies zu beheben, mussten wir dem Projekt das folgende Post-Build-Ereignis hinzufügen:

call "$(DevEnvDir)..\tools\vsvars32.bat"
"C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\bin\amd64\editbin.exe" /NXCOMPAT:NO "$(TargetPath)"

Dies gibt die ausführbare Datei explizit als nicht kompatibel mit Data Execution Prevention an. Weitere Details finden Sie hier .

In einigen Fällen kann dies passieren, wenn:

obj = new obj();
...
obj.Dispose();  // <-----------------    Incorrect disposal causes it
obj.abc...

In meinem Fall musste ich mit P / Invoke auf eine C / C ++ - Bibliothek verweisen, aber ich musste sicherstellen, dass der Speicher zuerst für das Ausgabearray zugewiesen wurde, indem ich 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;
    }

Weitere Informationen finden Sie unter: https://www.c-sharpcorner.com/article/pointers-in-C-Sharp/

Dies ist mir passiert, als ich meine C # WinForms-Anwendung in Visual Studio debuggte. Meine Anwendung ruft Win32-Inhalte über DllImport auf, z

[DllImport("Secur32.dll", SetLastError = false)]
private static extern uint LsaEnumerateLogonSessions(out UInt64 LogonSessionCount, out IntPtr LogonSessionList);

Das Ausführen von Visual Studio "als Administrator" hat das Problem für mich gelöst.

Ich hatte die gleiche Fehlermeldung:

System.AccessViolationException: Es wurde versucht, geschützten Speicher zu lesen oder zu schreiben. Dies ist häufig ein Hinweis darauf, dass der andere Speicher beschädigt ist.

In meinem Fall ist der Fehler nach dem Reinigen und Neuerstellen der Lösung behoben.

In meinem Fall hat das FTDI-Dienstprogramm FT Prog den Fehler beim Scannen nach USB-Geräten ausgelöst. Das Entfernen des Bluetooth-Kopfhörers vom PC hat das Problem behoben.

Ich habe diese Fehlermeldung für den Lambda-Ausdruck erhalten, der Linq zum Filtern einer Sammlung von Objekten verwendet hat. Als ich die Sammlung inspizierte, bemerkte ich, dass ihre Mitglieder nicht besiedelt waren - im LocalsFenster zeigte das Erweitern nur "...". Letztendlich lag das Problem in der Repository-Methode, mit der die Sammlung ursprünglich gefüllt wurde. Dapper versuchte, eine Eigenschaft eines verschachtelten Objekts automatisch zuzuordnen. Ich habe die Dapper-Abfrage behoben, um das Multi-Mapping zu behandeln, und das hat den Speicherfehler behoben.