Как я могу отладить внутреннюю ошибку в .NET Runtime?

Я пытаюсь отладить некоторую работу, которая обрабатывает большие файлы. Сам кодработает, но в самой .NET Runtime сообщается о спорадических ошибках. Для контекста, обработка здесь - это файл объемом 1,5 ГБ (загружаемый в память только один раз), который обрабатывается и освобождается в цикле, специально для того, чтобы попытаться воспроизвести эту иначе непредсказуемую ошибку.

Мой тестовый фрагмент в основном:

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
}

(с некоторыми сроками и другими добавленными вещами)

Цикл будет нормально обрабатываться для недетерминированного числа итерацийполностью успешно - никаких проблем вообще; тогда процесс резко прекратится. Обработчик исключений не ударил. Тест включает в себя много использования памяти, но он очень хорошо работает во время каждой итерации (нет явной утечки памяти, и у меня много свободного места - 14 ГБ неиспользуемой первичной памяти внаихудший точка в пиле). Процесс 64-битный.

Журнал ошибок Windows содержит 3 новые записи, которые (через код выхода 80131506) указывают на ошибку механизма выполнения - неприятный маленький фактор.связанный ответ, предлагает ошибку GC, с «исправлением» для отключения одновременного GC; однако это «исправление» не предотвращает проблему.

Пояснение: эта ошибка низкого уровня не затрагиваетCurrentDomain.UnhandledException мероприятие.

Пояснение:GC.Collect есть только для того, чтобы контролировать пилообразную память, проверять утечки памяти и сохранять вещи предсказуемыми; его удаление не устраняет проблему: оно просто удерживает больше памяти между итерациями и увеличивает размер dmp-файлов; p

Добавив больше трассировки консоли, я заметил, что она дает сбой во время каждого из:

во время десериализации (много выделений и т. д.)во время GC (между «подходом» GC и «завершением» GC с использованием API уведомлений GC)во время проверки (простоforeach по некоторым данным) - любопытнотолько после GC "завершено" во время проверки

Так много разных сценариев.

Я могу получить файлы аварийного дампа (dmp); как я могу исследовать это дальше, чтобы увидеть, что делает система, когда она так эффектно выходит из строя?

Ответы на вопрос(5)

Ваш ответ на вопрос