Probleme mit einem x64-Dotnet-Dienst, der zeitweise auf einem Anwendungsserver abstürzt. Der Dienst kann stunden-, tage- oder wochenlang ohne Probleme laufen, fällt dann aber mit wenig Informationen aus.
Der Dienst wird in einem Cluster (3 x Dienst pro Server) auf zwei Servern ausgeführt - und es wurden Abstürze bei allen Diensten auf beiden Servern festgestellt. Eine replizierte Umgebung zeigt dasselbe Verhalten, so dass ich die Idee eines Konfigurationsproblems "ausgeschöpft" habe.
Der ursprünglich aus dem Ereignisprotokoll des Anwendungsservers gezogene Fehler war:
%Vor%Dies zeigt nicht viel Detail und die besten Hinweise, die ich online gefunden habe, sind 'Finger zu kreuzen' ...
Anwendung stürzt mit "Internem Fehler in der .NET-Laufzeit ab "
Endlich, nach einem Monat, in dem wir den AdPlus-Debugger gestartet haben, haben wir eine Reihe von Fehlern und Crash-Dumps. Jetzt, wo ich die Müllhalden habe, habe ich Probleme, etwas von ihnen zu gewinnen.
Ich habe vorher ein paar "Hang" Dumps mit viel Erfolg untersucht und lese viel von Tess Ferrandez Blogs unter anderem, aber die "Crash" Dumps, die ich habe, erweisen sich als Deadends. Die meisten Objekte, Ausnahmen usw. sind alle für die Garbage Collection & amp; Nur der Hauptthread bleibt - ich vermisse wahrscheinlich etwas.
Ich werde das Detail aus! analyze -v und auch den Dump-Protokollen hinzufügen, die Ausnahmen anzeigen.
Also - die eigentliche Frage ist: Kann mir jemand Hinweise geben, wohin ich von hier aus gehen soll. Die Ausnahmen im Speicherprotokoll stimmen nicht überein mit dem, was ich im tatsächlichen Speicherauszug sehen kann.
DUMP 1 Log steht hier zur Verfügung: Ссылка
DUMP 1 Analyse: (Ich habe ein Symbolproblem, das ich nicht lösen kann ..)
%Vor%UPDATE 1 (29. Dez.):
Rekonstruierte eine der CLR-Ausnahmen aus dem Dump-Protokoll, Aufruf-Stack folgt. Es sieht aus wie eine Ausnahme beim Aufruf der Datenbank (über ODAC)
%Vor%Rekonstruierte den Zugriffsverletzungs-Ausnahmeaufruf-Stack. Beim Aufruf des Garbage Collectors nach dem Aufruf der ODAC-Bibliothek wird ein Fehler ausgegeben.
%Vor%Mögliche ähnliche Probleme (von neuen Informationen): Ссылка Ссылка
UPDATE 2 (23. Feb.):
Die ODAC-Komponenten wurden auf die korrekte Version für Dotnet 4.0 aktualisiert (oder auf der Oracle-Website als kompatibel aufgeführt) und das Problem ist immer noch aufgetreten. Es tritt immer noch sehr unregelmäßig auf, alle ein oder zwei Wochen. Der Dienst, der auftritt, wird jeden Tag neu gestartet.
Haben Sie mehr Dumps von den letzten Abstürzen, und diese zeigen immer noch auf Heap-Korruption - obwohl keine vollständigen Dumps (Zugriffsverletzung) sind. Tatsächlich scheint es, als wäre das Erstellen des vollständigen Dump fehlgeschlagen.
%Vor%Außerdem wird eine benutzerdefinierte verwaltete (dotnet) Bibliothek in die Anwendung geladen, und auch diese scheint eine Ausnahme auszulösen, obwohl es nur eine "erste Chance" ist und anscheinend keinen Prozessfehler verursacht (ich bin es es kann allerdings ein Faktor sein). Es ist tatsächlich unsere Bibliothek, also kann ich überprüfen, dass es keinen verwalteten Code aufruft. Der Fehler ist:
%Vor%Jemand mit irgendwelchen Ideen, wie man dies zweckdienlich weiter verfolgt. Ich bin daran interessiert, ein paar mehr volle Dumps zu bekommen - aber natürlich müssen Antworten schneller als der nächste Fehler finden !!
Die Ursache Ihres Absturzes (Unterbrechungspunkttreffer) weist auf eine Heapbeschädigung im Prozess hin. Heap-Korruptionsfehler werden von Heap-Verwaltungsfunktionen gemeldet, indem eine Debug-Unterbrechung ausgegeben wird.
Nach den protokollierten Fehlern zu urteilen, ist die .NET-Laufzeitumgebung unvorbereitet, um mit diesen umzugehen (ich könnte falsch liegen und es könnte eine bessere Erklärung geben). Der übliche Weg, um Heap-Verfälschungen zu verfolgen, ist das Aktivieren des (vollen) Seiten-Heapspeichers, der dabei hilft, die problematische Komponente ausfindig zu machen, indem der Prozess näher an den Punkt der Korruption gebracht wird.
Die Jagd auf einen Haufen Korruption ist ein echter Schmerz gelinde gesagt, aber wenn der Speicherverbrauch es erlaubt, würde ich gehen mit voller Seite Haufen am effektivsten für Anwendungen mit moderaten Speicheranforderungen.
Ich hoffe, es hilft.
Der GC von x64 .NET 4.0 hat einen Fehler. Es könnte sein, dass Sie davon betroffen sind. MS empfiehlt, gleichzeitige GC zu deaktivieren, bis sie einen Hotfix erhalten. Alternativ könnten Sie Server-GC aktivieren, um einen GC-Thread pro Kern zu erhalten, was möglich ist, wenn Sie mehr als einen Kern haben.
Ansonsten hat das Server-GC-Flag keine Wirkung.
Ein paar Dinge 1. Stellen Sie sicher, dass Sie die neueste Version von clr ausführen 2. Für native heap corruption pageheap ist eine gute Option und für verwaltet möglicherweise können Sie versuchen, GCStress Wie aktiviere ich GCStress in Windows 7? 3.Um die Heap-Beschädigung auf dem verwalteten Heap zu validieren, können Sie verifyheap verwenden, das Teil von SOS ist Ссылка "VerifyHeap Überprüft den Garbage-Collector-Heap auf Zeichen von Beschädigung und zeigt alle gefundenen Fehler an. Heap-Fehler können durch Aufrufe von Plattformaufrufen verursacht werden, die falsch erstellt werden."