Ich versuche, einige Arbeiten zu debuggen, die große Dateien verarbeiten. Der Code selbstfunktioniertEs gibt jedoch sporadische Fehler, die von der .NET-Laufzeit selbst gemeldet werden. Als Verarbeitung wird hier eine 1,5-GB-Datei (die nur einmal in den Speicher geladen wird) verwendet, die in einer Schleife verarbeitet und freigegeben wird, um diesen ansonsten unvorhersehbaren Fehler zu reproduzieren.

Mein Testfragment ist im Grunde:

try {
    byte[] data =File.ReadAllBytes(path);
    for(int i = 0 ; i < 500 ; i++)
    {
        ProcessTheData(data); // deserialize and validate

        // force collection, for tidiness
        GC.Collect(GC.MaxGeneration, GCCollectionMode.Forced);
        GC.WaitForPendingFinalizers();
    }
} catch(Exception ex) {
    Console.WriteLine(ex.Message);
    // some more logging; StackTrace, recursive InnerException, etc
}

(mit ein bisschen Timing und anderem Zeug)

Die Schleife wird für eine nicht deterministische Anzahl von Iterationen gut verarbeitetvoll erfolgreich - überhaupt keine Probleme; dann wird der Prozess abrupt beendet. Der Ausnahmehandler ist nicht betroffen. Der Test verbraucht zwar viel Speicher, zeigt aber bei jeder Iteration eine gute Leistung (es gibt keinen offensichtlichen Speicherverlust, und ich habe viel Headroom - 14 GB unbenutzter Primärspeicher auf der Festplatte)am schlimmsten Punkt im Sägezahn). Der Prozess ist 64-Bit.

Das Windows-Fehlerprotokoll enthält 3 neue Einträge, die (über den Exit-Code 80131506) auf einen Execution-Engine-Fehler hinweisen - ein böses kleines Tier. EINverwandte Antwortschlägt einen GC-Fehler mit einem "Fix" vor, um die gleichzeitige GC zu deaktivieren; Dieses "Update" verhindert das Problem jedoch nicht.

Klarstellung: Dieser Low-Level-Fehler trifft das nichtCurrentDomain.UnhandledException Veranstaltung.

Klarstellung: dieGC.Collect gibt es nur, um das Sägezahn-Gedächtnis zu überwachen, auf Speicherlecks zu prüfen und die Dinge vorhersehbar zu halten; Durch das Entfernen wird das Problem nicht behoben: Es wird lediglich der Speicher zwischen den Iterationen vergrößert und die dmp-Dateien vergrößert

Indem ich mehr Konsolen-Tracing hinzufügte, habe ich festgestellt, dass es bei jedem der folgenden Vorgänge Fehler gab:

während der Deserialisierung (viele Zuordnungen usw.)während der GC (zwischen einem GC-"Ansatz" und einem GC "abgeschlossen" unter Verwendung der GC-Benachrichtigungs-API)während der Validierung (nurforeach über einige der Daten) - neugierigkurz nachdem ein GC "abgeschlossen" während der Validierung

Also viele verschiedene Szenarien.

Ich kann Crash-Dump-Dateien (dmp) erhalten. Wie kann ich das weiter untersuchen, um zu sehen, was das System macht, wenn es so spektakulär ausfällt?