AccessViolationException in einer seltsamen Situation ausgelöst

Question

AccessViolationException in einer seltsamen Situation ausgelöst

8

Ich bin ziemlich lange in c #, aber ich habe nie einen solchen Fehler bekommen. Zuallererst, siehst du irgendetwas falsches (möglicherweise falsch) über diesen einzelnen Codeblock (außer es ist natürlich Logik, ich weiß, dass es immer 0 zurückgibt)?

%Vor%

Projekteinstellungen freigeben: DEBUG constant = false; TRACE konstant = wahr; Optimiere Code = wahr; Ausgabe / Erweitert / Debug-Info = keine;

IIS = Version 7.5

Diese Methode hat nach Angabe der Freigabeeinstellungen " System.AccessViolationException : Es wurde versucht, geschützten Speicher zu lesen oder zu schreiben. Dies ist häufig ein Hinweis darauf, dass anderer Speicher beschädigt ist."

Und hier ist der lustige Teil. Dies sind Fälle, in denen diese Ausnahme nicht ausgelöst wird:

Führen Sie es unter IIS (Express und nicht-Express) 8.5 aus (keine Projektbearbeitung erforderlich).
Set Optimize code = false; und Ausgabe / Erweitert / Debug info = false;
Wirf die Methode hinein, um den Block zu versuchen / zu fangen (versuchte auch, die Ausnahme mit log4net im catch-Block zu protokollieren - leeres Protokoll)
Ersetzen Sie das Innere der Methode durch einen anderen Code.

Zu beachten:

Die Ausnahme musste mit dem Win Debugger auf dem Server abgefangen werden (Nr regulärer .NET-Ausnahmehandler wurde aufgerufen)
Die Anwendung stürzt nach der Ausnahme ab.
Dieser Codeblock funktionierte vor einigen Monaten (lange nicht mehr freigegeben). Der Fehler hat wahrscheinlich mit einigen Updates begonnen.
Getestet auf zwei verschiedenen Servern mit IIS 7.5 und einem Computer mit IIS 8.5 und IIS Express (VS2012). Gleiche Ergebnisse.
Ich habe viele verschiedene Kombinationen von Projekteinstellungen ausprobiert. Grundlegend, wenn ich die Einstellungen nicht wie in Punkt 2. setze, wirft es das Ausnahme für IIS 7.5.
Auf meinem Arbeitscomputer (und Build) wird Windows 8.1 mit den neuesten Updates ausgeführt.
Der Codeblock befindet sich in einem separaten Projekt (Klassenbibliothek).

Ich weiß, wie ich das beheben kann. Aber ich mag es nicht, Probleme zu schließen, ohne die Ursache zu kennen. Auch das möchte ich in Zukunft vermeiden. Denkst du, du könntest mir dabei helfen? Wenn es eine Null-Referenz-Ausnahme gibt, warum passiert das? Und warum ist es debug / release-spezifisch oder IIS-versionsspezifisch?

* Anmerkung2 :

Kürzlich hatte ich Probleme mit fehlenden DLLs (System.Net.Http.Formatting.dll, System.Web.Http.dll, System.Web.Http.WebHost.dll) während der Veröffentlichung. Es war wegen einiger Microsoft Sicherheitsupdates. Vielleicht ist das etwas ähnlich. *

Bearbeiten 1 Struktur der Enum-Deklaration hinzufügen.

%Vor%

Ich habe auch versucht, [MethodImpl (MethodImplOptions.NoInlining)] hinzuzufügen, aber keine Hilfe.

.net c# asp.net iis access-violation

Martin Brabec 03.12.2014, 21:07

quelle

2 Antworten

0

Ich bin mir nicht sicher, ob das für Sie noch relevant ist, aber ich habe diesen AccessViolation-Fehler erzeugt, indem ich einfach einen sehr kleinen und unbedeutenden Bool in einem vollständig verwalteten Codeabschnitt geändert habe. Der beste Teil jedoch, wenn ich Code-Optimierung im Compiler für dieses Teilprojekt deaktivieren, läuft alles gut. Es scheint ein Fehler zu sein, der vom Compiler in einer sehr spezifischen Situation eingeführt wird, die keinen logischen Sinn ergeben muss.

Oliver Bernhardt 31.05.2017 11:49

quelle

Tags und Links .net c# asp.net iis access-violation

Django: Verwenden von Annotate, Count und Distinct in einem Queryset Memcached vs Redis als Rails.cache, wenn ein LRU-Cache benötigt wird

score 3 · Accepted Answer

Es ist untypisch, dass diese Arten von Zugriffsverletzungsfehlern aus verwaltetem Code stammen. Sie stammen aus einer Speicherbeschädigung, die auf fehlerhafte Hardware hinweisen kann - in extrem seltenen Fällen weist dies auf einen Fehler in der CLR hin.

Die wahrscheinlichste Ursache für diesen Fehlertyp stammt aus anderen Quellen, z. Wenn dieser Code irgendwie systemeigenen Code verwendet - entweder durch Aufruf von systemeigenem Code in einem unsicheren Kontext oder durch Aufruf von systemeigenem Code.

Um MSDN AccessViolationException zu zitieren:

In Programmen, die ausschließlich aus verifizierbarem verwaltetem Code bestehen, sind alle Referenzen entweder gültig oder null und Zugriffsverletzungen sind unmöglich. Eine AccessViolationException tritt nur auf, wenn überprüfbarer verwalteter Code mit nicht verwaltetem Code oder unsicherem verwaltetem Code interagiert.

In jedem Fall müssen Sie normalerweise an einer anderen Stelle im Code suchen, um den fehlerhaften Code zu finden, der den Speicher beschädigt. Leider ist das ein ziemlich schwer zu lösendes Problem. Viel Glück!