[gelöst] Beim Bereinigen von Daten kommt es zu internem Fehler der .NET Runtime

Hallo Zusammen,

sorry wegen der Wenig sagend Überschrift, ich wusste jetzt nicht was ich da genau verwenden sollte, der genaue Fehlertext in den Eventlogs lautet.

Fehlermeldung:
Anwendung: SQLTraceToTraceImport.exe
Frameworkversion: v4.0.30319
Beschreibung: Der Prozess wurde aufgrund eines internen Fehlers in der .NET-Laufzeit beendet. bei IP 73F5E24F (73E70000) mit Exitcode 80131506.

Soweit ich es bis jetzt raus bekommen habe Scheint es sich um diesen Fehler zu handeln.
FIX: "Faulting module name: clr.dll" error message when you run a Microsoft .NET Framework 4-based application

Den Support von MS hatte ich Freitag kontaktiert um den HotFix zu bekommen. Bis auf eine Bestätigungsmail habe ich aber noch keine Rückmeldung bekommen.

Was mich zu meiner 1. Frage bringt.
**Kann mir zufällig jemand hier den HotFix zu Verfügung stellen. **

Da ich aber auch von meiner eigenen Dummheit ausgehe (ist in 99,9% der Fälle das Problem X( )
Möchte ich nicht ausschließen, das es an was anderen hängen kann.

Deshalb hier mal eine grobe Übersicht was ich mache.
Ich hab ein Windows Forms Programm, was die Datenübernahme von einer alten SQL Datenstruktur in eine neue machen soll. Es handelt sich dabei um ca. 90GB an Daten. Im Programm verwende ich einen BackgroundWorker und das EF6. Im 1. Schritt gehe ich hin und bereinige Fehler in der alten Datenstruktur (Fehlerhafte Doppelte Einträge usw. sind halt alte Daten).

Hierbei kommt es schon zum Absturz mit oben genannten Fehler. Auf meinen Windows 7 Entwicklungsrechen und gegen unseren SQL 2016 Server (läuft auf einen 2012 Server) funktioniert es Problemlos und brauch ca. 3h.

Bei uns auf dem 2012 Server tritt der Fehler auch auf, so wie bei unseren Kunden auf 2 Verschiedenen 2012 Server und auf einen Windows 7 Rechnern mit installiertem VS2015.
Vereinfacht tritt der Fehler mal bei dem 10 Datensatz auf und manchmal bei den 90.000. Und er tritt auch bei Unterschiedlichen Methoden Aufrufen auf. Weshalb ich denke es könnte das in dem Link beschrieben Problem mit dem GC sein.

Das Verhalten das GC hab ich schon probiert zu ändern mit:

 <runtime>
       <gcConcurrent enabled="true/false"/>
   </runtime>  

Was auch nicht funktioniert hat.

Ich bin da für jede Hilfe dankbar.

Hab mal kurz hinterher gegoogled.. hast Du gcServer enabled="true" probiert?

Scheint wirklich ein Bug im GC zu sein, es sei denn Du benutzt irgendwo nativen Code.

Danke erst mal für die Antwort.

gcServer enabled="true" hatte ich bei dem 2012 Server schon benutzt. Da hatte es nicht funktioniert. Aktuell lasse ich es mit der Option auf den W7 Testsystem beim Kunden laufen (Da es kein Server System ist, hatte ich eigendlich gedacht das es die Standard Option wäre. Scheint aber eher von der Anzahl der Prozessoren abzuhängen. Je nach dem wie man die MSDN interpretiert) . Und habe seit grob 1,5 h keinen Absturz. Muss aber noch nichts heißen.

Nativen Code nutze ich nirgendwo direkt.

Ich mache da jetzt auch nichts großartig Ungewöhnliches.
Windows Forms Anwendung um den aktuellen Stand zu Visualisieren.
Einen BackgroundWorker damit die UI nicht einfriert.
Datenzugriff über EF6.
Ansonsten hab ich noch ein paar Dictionarys für Daten die ich immer wieder brauche.
Und nach gewissen Abschnitten Dispose ich den Context des EF und erstelle ihn wider neu.(Ich hatte vorher ein paar Out Of Memory Exeptions, bein 90GB durch aus verständlich)

Ein Hinweis war auch das es nur im 64 bit gc vorkommt. Schon probiert gegen 32bit zu kompilieren?

Du hast recht.. Sowas nervt. Ansonsten müsstest halt mit winDbg den crash dump auseinander nehmen. Aber ob das dann zum Ziel führt ist auch wieder so eine Sache.

Umbau auf ef4/6 oder natives SQL könnte vielleicht auch funktionieren.

So es war jetzt mit der Option (gcServer enabled="true") erst mal durch gelaufen.

Dann hab ich zur Sicherheit noch mal das Backup wiederhergestellt (20min), die Indexe erstellt (20min) und das Programm noch mal gestartet. Nach ca. 30min ist es dann Abgestürzt. Gleicher Fehler.

Neu Gestartet, direkt Absturz, gleicher Fehler. Neu Gestartet, aktuell läuft es. In 2h weiß ich mehr.

x86, x64 und Any CPU bin ich auch schon durch. Hat nichts geholfen.

Umbau hab ich auch schon überlegt, ist nur leider ein recht großer Aufwand. Ich hoffe ja das da MS mit ihrem HotFix/ Update schneller sind.

Wäre den eine Umstellung auf eine neue .Net Version keine Alternative?
Oder könnt ihr es auf dem 2012 nicht hochstufen.
Bzw. könnt ihr euren 2012 nicht updaten um den Hotfix einzuspielen?

Ich würde fast vermuten, dass ihr ohne eine Umstellung auf eine neue .Net Version oder den Hotfix das Problem nicht lösen könnt.
Kann das Tool alternativ auch auf einer anderen Maschine laufen?
Anbei wäre es doch sinnvoller anstelle einer WinForms Anwendungen direkt eine Konsolen Anwendung zu nutzen für solche Aufgaben.
Output kann man dann entweder direkt in die Konsole oder auch noch in eine Log Datei schreiben.
Oder hat es einen Grund warum es WinForms sein muss?

T-Virus

Aktuell verwenden die Anwendung Framework 4.5.
An dem Punkt könnte ich es eher Runterstufen 4.0 sollte kein Problem sein. Bei 2.0 werde ich wohl Probleme mit einigen Linq abfragen bekommen.

Den HotFix hab ich nicht und weiß auch nicht in welchen Update er enthalten ist/sein wird.
(Bin gerade ein wenig verdutzt, die letzte Änderung im Deutschen Artikel ist vom 10.01.2017 weswegen ich davon Ausgegangen bin das das Problem recht aktuell ist. Der Englische Artikel wurde am 12.01.2012 letzte mal aktualisiert.)

Grundlegend kann es auch auf einen anderen Rechner beim Kunden laufen, es brauch halt zugriff auf dem SQL Server. Da ich es jetzt W7 und 2012 könnte ich es nochmal mit W10 testen.

Grundlegend spricht nicht dagegen, das Programm in eine Konsolen Anwendung umzuwandeln.
Ich denke nur nicht, das es das Problem beheben wird.

Also wenn ich 90GB, Massendaten und ORMapper lese kräuselt sich bei mir alles.

Habe auch mal so eine SW gesehen, die hat Tage gebraucht für die Aufgabe und hat irre Speicher verbraucht.

Habe das dann auf normale ADO.NET ( also DataReader und co, keine DataTable/DataSet ) umgebaut und die Aufgabe war in unter 1 Stunde mit sehr geringem Speicherbedarf erledigt.

Nur so eine Idee.

Das EF6 ist in der Standardkonfiguration unperformant.
Aber FZelle, wenn man bei EF Proxy, Tracking und Co deaktiviert, dann ist es nicht mehr wirklich arg viel langsamer als ADO.NET Plain...

Das EF6 hat aber in meinen Augen konzeptionelle Fehler, weshalb ich da auch kategorisch aus dem Weg gehen.
EF Core ist aber wieder ein riesen Schritt nach Vorn und ein notwendiger Neubeginn.

Ok ich habe es jetzt auf das Framework 4.6.1 umgestellt, damit läuft es.

Das es im Framework 4.6.x Änderungen im GC gegeben hat, hab ich ehrlich gesagt nicht mitbekommen.
MSDN:Significant Garbage Collector Changes in .NET 4.6.2

@Palin
Man muss auch bei .Net immer mal die Augen aufhalten und schauen was sich bei neuen Versionen ändert.
Manchmal sind die Änderungen schon gar nicht mal ohne.

Gutes Beispiel war der Support bei großen Arrays um 64 Bit Index und entsprechend Größe it mehr als 2 GB, was schon einen gewissen Impact hat bei bestimmten Anwendungen.

Auch wenn ich bisher nur selten geschafft habe, solche Speicherbrocken zu erstellen 😃
Ich versuche immer meinen Code und meine Programmierung möglichst speicherschonend zu entwickeln.
Nur in manchen Ausnahmen, lasse ich auch mal meine Anwendung 10GB fressen 😃
Dies ist mache ich aber aktuell mit .Net 2.0 und nur in sehr seltenen Ausnahmen, wenn man lokal ein Task Daten verarbeiten muss die auch nur einmalig in dieser größe verarbeitet werden müssen.

T-Virus