Jak mogę debugować błąd wewnętrzny w środowisku wykonawczym .NET?

Próbuję debugować niektóre prace, które przetwarzają duże pliki. Sam kodPrace, ale sporadycznie zgłaszane są błędy z samego środowiska wykonawczego .NET. W kontekście przetwarzania tutaj jest to plik 1,5 GB (ładowany do pamięci tylko raz) przetwarzany i uwalniany w pętli, celowo w celu odtworzenia tego nieprzewidzianego w inny sposób błędu.

Mój fragment testowy to w zasadzie:

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
}

(z czasem i innymi rzeczami)

Pętla będzie się dobrze przetwarzać dla niedeterministycznej liczby iteracjiw pełni pomyślnie - żadnych problemów; wtedy proces zakończy się nagle. Program obsługi wyjątków nie został trafiony. Test wymaga dużego wykorzystania pamięci, ale bardzo dobrze sprawdza się podczas każdej iteracji (nie ma wyraźnego wycieku pamięci, a mam mnóstwo miejsca - 14 GB nieużywanej pamięci podstawowej wnajgorszy punkt w zębie piły). Proces jest 64-bitowy.

Dziennik błędów systemu Windows zawiera 3 nowe wpisy, które (poprzez kod wyjścia 80131506) sugerują błąd silnika wykonawczego - paskudny mały critter. ZAodpowiednia odpowiedźsugeruje błąd GC z „poprawką” wyłączającą współbieżne GC; jednak ta „poprawka” nie zapobiega problemowi.

Wyjaśnienie: ten błąd niskiego poziomu nie trafia wCurrentDomain.UnhandledException zdarzenie.

Wyjaśnienie:GC.Collect jest tylko po to, aby monitorować pamięć uzębienia, sprawdzać wycieki pamięci i utrzymywać rzeczy w przewidywalnym stanie; usunięcie go nie sprawi, że problem zniknie: po prostu sprawia, że ​​zachowuje więcej pamięci między iteracjami i sprawia, że ​​pliki dmp są większe; p

Dodając więcej śledzenia konsoli, zauważyłem, że to błąd podczas każdego z:

podczas deserializacji (wiele przydziałów itp.)podczas GC (między podejściem „GC” a GC „kompletne”, przy użyciu interfejsu API powiadomienia GC)podczas walidacji (tylkoforeach nad niektórymi danymi) - ciekawiezaraz po GC „kompletne” podczas walidacji

Tak wiele różnych scenariuszy.

Mogę uzyskać pliki zrzutu awaryjnego (dmp); jak mogę to dalej zbadać, aby zobaczyć, co robi system, gdy zawodzi tak spektakularnie?

questionAnswers(5)

yourAnswerToTheQuestion