| 

.NET C# Java Javascript Exception

4
Hallo zusammen,

ich habe ich einer Anwendung "unerklärliche" Abstürze. Das einzige was ist danach sehe, ist ein Eintrag in der Windows Ereignisanzeige (Anwendung):

Ereignistyp: Fehler
Ereignisquelle: .NET Runtime
Ereigniskategorie: Keine
Ereigniskennung: 1023
Datum: 23.08.2012
Zeit: 17:27:41
Benutzer: Nicht zutreffend
Computer: xyz
Beschreibung:
Anwendung: xyz.exe
Frameworkversion: v4.0.30319
Beschreibung: Der Prozess wurde aufgrund eines internen Fehlers in der .NET-Laufzeit beendet. bei IP 7928EF67 (79140000) mit Exitcode 80131506.


Wie bekomme ich heraus, an welcher Stelle in meinem Quellcode der Fehler passiert ist?
Ich verdächtigen Stellen sind eigentlich mit try Catch - Blöcken "gespickt", aber da wird keine Exception gefangen.

Danke,
Mike

Nachtrag: Den habe ich zu dem Exitcode schon mal gefunden ...
http://stackoverflow.com/questions/4367664/application-crashes-with-internal-error-in-the-net-runtime
That's a nasty one, ExecutionEngineException. Starting with .NET 4.0, this exception immediately terminates the program. The generic cause is corruption of the state of the garbage collected heap. Which in turn is invariably caused by unmanaged code. The exact location in code at which this exception is raised isn't helpful, the corruption usually occurred well before the damage is detected.

Finding the exact cause for this is going to be difficult. Review any unmanaged code your service might be using. Suspect environmental problems if there is no obvious candidate, misbehaving malware scanners are notorious. If it repeats very poorly then suspect hardware problems like soft RAM errors.


Klingt nicht gut :(

Nachtrag 2:
Was für eine Umgebung ist eigentlich vorhanden ...
Die Anwendung läuft hier auf einem Intel Core i5 unter Windows XP SP3 (32bit) und .NET 4.0. Es ist eine Steuerung für ein Meßgerät das zwei Drittanbieter DLLs verwendet. Eine (unmanaged) für eine Schrittmotorsteuerung (seriell angeschlossen) und eine (managed) für eine Ablaufsteuerung (SPS, per Ethernet angeschlossen). Dazu läuft noch die Kommunikation mit dem "Master" der gesamten Roboteranlage per serieller Schnittstelle.

Die Aufrufe der Unmanaged DLL sind in einer SafeNativeMethods Klasse:
[DllImportAttribute(DLLNAME, EntryPoint = "LS_ConnectSimple",
CallingConvention = CallingConvention.StdCall,
CharSet = CharSet.Ansi, BestFitMapping = false, ThrowOnUnmappableChar = true)]
internal static extern int ConnectSimple(
int lAnInterfaceType,
[InAttribute()] [MarshalAsAttribute(UnmanagedType.LPStr)] string pcAComName,
int lABaudRate,
[MarshalAsAttribute(UnmanagedType.Bool)] bool bAShowProt);

Gemäß der Vorschläge des P/Invoke Interop Assistant und der statischen CodeAnalyse.

Im Moment ist der fehler sogar reproduzierbar, leider dauert es jedes Mal ca. 4 Stunden, bis die Anlage die entsprechende Anzahl an Durchläufen gemacht hat. ;)

Die unmanaged DLL könnte ich raus werfen und einen Adapter für die serielle Kommunikation selber schreiben (Fleißarbeit). Es wäre halt nur schön, wenn ich wenigstens ein paar Hinweise hätte, dass es daran liegt.
News:
23.08.2012
Xantiva 2,3k 2 9
Xantiva 2,3k 2 9
Kurzer Zwischenbericht: Ich habe mir die Testversion des ANTS Memory Profilers (http://www.red-gate.com/products/dotnet-development/ants-memory-profiler/) heruntergeladen. Demnach gibt es scheinbar ein Memory Leak im unmanaged Code, aber natürlich nicht in der Komponente, die ich als unmanaged direkt eingebunden habe. Eher in der managed Komponente ...
Xantiva 27.08.2012
2 Antworten
3
Der Fehlercode 80131506 deutet auf eine ExecutionEngineException hin.

Ersteinmal grundsätzlich wird dieser Fehler nicht direkt von irgend einer Stelle in deinem Code ausgelößt, weswegen er auch nicht in diesem Sinne zu lokalisieren ist.

Es gibt mehrere mögliche Ursachen für diesen Fehler. Zum einen kann es sein, das die Managed Heap versaut (mir fällt kein besseres deutsches Wort für "corrupt" ein) ist. Ursache dafür kann Unmanaged-Code in deinem Programm oder im .Net-Framework selbst sein. Die MSDN weißt auf eine weitere Möglichkeit hin, und zwar das die Systemlast zu groß war.

In einigen Fällen löst eine Anwendung, die von .NET Framework abzielt, eine ExecutionEngineException Ausnahme während der Garbage Collection ausgeführt, wenn eine Anwendung oder das System, auf denen sie ausgeführt wird, unter einem schweren Last ist. Als Problemumgehung können Sie die gleichzeitige Garbage Collection deaktiviert werden, indem Sie die Konfigurationsdatei der Anwendung ändern. Weitere Informationen finden Sie unter Gewusst wie: Deaktivieren von gleichzeitigen Garbage Collection-Vorgängen.

Zu diesem Thema gibt es auch einen KB-Artikel von MS:
ExecutionEngineException occurs during Garbage Collection
(An x64 .Net 4 application crashes randomly)

Was kannst du machen. Hmm, zum einen kannst du die kontinuierliche Garbage Collection einmal deaktivieren. Zum anderen kannst du die Benutzung des virtuellen Arbeitsspeichers deines Programms einmal im Auge behalten. Zu guterletzt solltest du auch prüfen ob das Problem auf einer nakten Windows-Installation ohne Virenscanner und Firewall auch auftritt.
23.08.2012
Floyd 14,6k 3 9
+1, gut recherchiert. Sowas ist definitiv Kategorie "Sehr fies". Bin gespannt, was nach Deinen Vorschlägen (clean system, no FW) passiert. Die Nuss wird noch geknackt...
@Xantiva: Vlt. kannast noch etwas mehr zur Projektumgebung sagen: P/Invoke, Unmanaged, COM, ...
ffordermaier 23.08.2012
Nach einem Hinweis aus dem StackOverflow Artikel habe ich gestern noch versucht, mich für das AppDomain.UnhandledException Event zu registrieren, damit ich vielleicht noch den StackTrace oder so loggen kann. Den Fehler bekomme ich aber nicht damit gefangen.

Unter besonderer Last läuft das System auch nicht, die CPU Last liegt <5% (Intel Core i5).

Die Infos zur Umgebung schreibe ich jetzt in die Frage mit rein.
Xantiva 24.08.2012
Wie siehts mit dem "zugesicherten Speicher" / "virtuellen Arbeitsspeicher" aus?
Floyd 24.08.2012
Der Rechner hat 3GB und die Hälfte wird nur genutzt. Den KB Artikel über die Garbage Collection hatte ich schon gelesen, aber der zielt ja auf x64 Systeme. Wie ich (gerade) geschrieben habe, läuft das auf einem 32bit Windows. (Kompiliert für AnyCpu.)
Xantiva 24.08.2012
Hmm, was passiert wenn du den GC ausstellst?
Floyd 24.08.2012
Das werde ich noch testen. Im Moment läuft noch ein Test (der bis zu Stunden dauert). Als schnelles Debuggen ist leider nicht ;)
Xantiva 24.08.2012
Du hast in deinem Edit geschrieben, das du Unmanaged-DLL's verwendest dir aber nicht sicher bist ob diese das Problem auslösen. Wenn die API die du verwendest nicht zu groß ist, könntest du versuchen eine Fake-Klasse die genau so aussieht wie das DLL-Interface schreiben und dort fest definierte Werte zurückgeben. Tritt das Problem dann nicht mehr auf weißt du was du zu tun hast :) (die Fake-Klasse beleben)
Floyd 24.08.2012
Die Ursache ist ein Memory Leak in einer Drittanbieter-Komponente. Der Hersteller kann das Verhalten inzwischen reproduzieren und arbeitet an der Lösung ;)
Danke nochmal für die Tipps!
Xantiva 30.08.2012
2
Für welche Framework Version kompilierst Du Dein Tool? .NET 3.5 hat diese Exception noch ohne Mucken geworfen, seit .NET 4.0 ist sie [Obsolete] attributiert. Auch wenn die EventLog Ausgabe auf 4.0 hindeutet, ...

Mein Tip: Bau die Hütte mal mit 4.0 oder 4.5 und schau, ob Du einen spezifischeren Fehler bekommst.

Florian
23.08.2012
ffordermaier 8,4k 3 9
Zielframework ist bereits .NET 4.0 ...
Deswegen kann ich Exception ja auch nicht fangen.
Xantiva 24.08.2012

Stelle deine .net-Frage jetzt!