Como posso depurar um erro interno no .NET Runtime?

Eu estou tentando depurar algum trabalho que processa arquivos grandes. O próprio códigotrabalho, mas há erros esporádicos relatados do próprio .NET Runtime. Para o contexto, o processamento aqui é um arquivo de 1,5 GB (carregado na memória apenas uma vez) sendo processado e liberado em um loop, deliberadamente para tentar reproduzir esse erro imprevisível.

Meu fragmento de teste é basicamente:

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
}

(com algum tempo e outras coisas jogadas)

O loop irá processar bem para um número não determinístico de iteraçõestotalmente com sucesso - sem problemas algum; então o processo terminará abruptamente. O manipulador de exceções não é atingido. O teste envolve muito uso de memória, mas ele é muito bom durante cada iteração (não há um vazamento de memória óbvio, e eu tenho bastante espaço - 14GB de memória primária não utilizada nopior ponto no dente de serra). O processo é de 64 bits.

O log de erros do Windows contém 3 novas entradas, que (via código de saída 80131506) sugerem um erro no Mecanismo de Execução - um bicho desagradável. UMAresposta relacionada, sugere um erro de GC, com uma "correção" para desabilitar o GC concorrente; no entanto, essa "correção" não impede o problema.

Esclarecimento: este erro de baixo nível não atinge oCurrentDomain.UnhandledException evento.

Esclarecimento: oGC.Collect existe apenas para monitorar a memória dente-de-serra, para verificar vazamentos de memória e manter as coisas previsíveis; removê-lo não faz o problema desaparecer: ele apenas faz com que ele mantenha mais memória entre as iterações e torne os arquivos dmp maiores;

Adicionando mais rastreio do console, observei falhas durante cada um deles:

durante a desserialização (muitas alocações, etc)durante o GC (entre uma "abordagem" do GC e um GC "completo", usando a API de notificação do GC)durante a validação (apenasforeach sobre alguns dos dados) - curiosamentelogo após um GC "completo" durante a validação

Então, muitos cenários diferentes.

Eu posso obter arquivos de despejo de memória (dmp); Como posso investigar isso mais, para ver o que o sistema está fazendo quando ele falha tão espetacularmente?

questionAnswers(5)

yourAnswerToTheQuestion