Minha instalação do .NET incluída no Windows 7 (3.5 a 2.0) parece muito leve e particularmente corrompida e estou tentando consertá-lo sem reinstalar o Windows ou tentar reverter para backups.
Tudo estava funcionando e então meu disco rígido começou a corromper alguns arquivos e o checkdisk encontrou clusters defeituosos, então criei uma imagem da unidade para uma nova. Assim que inicializei na nova unidade, tudo funcionouexcetoprogramas que chamam os métodos System.Net.NetworkInformation no .NET 3.5 a 2.0 (como Ping() e IsNetworkAvailable()), que travam imediatamente o aplicativo no qual as chamadas estão (essas chamadas no .NET 4.0 funcionam bem). Esses métodos são encontrados dentro de System.dll, e presumo chamar métodos nativos que acredito estarem dentro de winnsi.dll ou iphlpapi.dll ou qualquer outra coisa (ainda não encontrei isso); Presumo que ele chama métodos nativos porque a exceção que causa a falha é o Fatal Execution Engine Error, que as pessoas mencionam geralmente está relacionado à chamada de métodos nativos e ao empacotamento de dados entre eles.
Uma grande pista sobre o culpado provavelmente é encontrada no fato de que quando eu inicio exatamente o mesmo aplicativo com falha por meio de um criador de perfil de código (que executa o exe e captura estatísticas sobre quais métodos demoraram mais), o aplicativo funciona bem, sem travar! Como executá-lo dentro do criador de perfil poderia funcionar e executá-lo fora não funcionar? Essa parece ser a chave do mistério.
- Eu usei o procmon para capturar todos os eventos de registro, sistema de arquivos e rede da execução com falha e da execução bem-sucedida do profiler e comparei as duas saídas, mas não aprendi muito (vejo o momento em que o aplicativo sem perfil trava, mas até então eles se comportavam da mesma forma, carregavam os mesmos módulos, ). A única grande diferença parece ser que, no momento anterior à falha do aplicativo, o código executado pelo criador de perfil cria de 4 a 6 novos threads e o código executado diretamente cria apenas de 1 a 2.
- Eu diferenciei os arquivos/diretórios que pareciam mais relevantes (o material .NET no Windows e Arquivos de Programas) com problemas pré e pós-disco e não vi nenhuma alteração onde eu não esperava (nenhuma corrupção óbvia de arquivo).
- Eu diferenciei as seções do software e do registro do sistema antes e depois dos problemas do disco e não vi nenhuma alteração que parecesse relevante.
- Criei uma nova conta de usuário e limpei todas as variáveis de ambiente caso o ambiente estivesse relacionado. Nenhuma mudança.
- Eu fiz "sfc/scannow" e não encontrei problemas de integridade.
- Tentei "ngen update" para regenerar o código pré-compilado caso eu tenha perdido algo que possa estar danificado e nada tenha mudado.
Presumo que preciso reparar minha instalação do .NET, mas como o Windows 7 inclui o .NET 3.5 - 2.0, você não pode simplesmente executar novamente um instalador do .NET para refazê-lo. Não tenho acesso aos discos do Windows para tentar reinstalar o Windows sobre si mesmo (o computador possui uma partição de recuperação, mas está inutilizável); além disso, a unidade usa uma solução de criptografia de disco inteiro e a reinstalação seria difícil.
Eu absolutamente não quero começar do zero aqui e instalar um Windows novo, reinstalar dezenas de pacotes de software, tentar lembrar dezenas de personalizações relacionadas ao desenvolvimento/etc.
Considerando tudo isso... alguém tem algum conselho útil? Preciso do .NET 3.5 - 2.0 funcionando, pois sou desenvolvedor e preciso compilar e testar nele.
Obrigado!
Quinxy
Responder1
A resposta curta é que meu arquivo System.ni.dll foi danificado, eu o substituí e está tudo bem.
Lembrei-me de que deveria verificar novamente o log do chkdsk. Continuei listando os arquivos que foram danificados pela falha da unidade. Após a falha, transformei todos os ids de arquivos listados em caminhos/nomes de arquivos e substituí todos os mais de 100 arquivos que pude do backup, mas com certeza quando voltei agora e procurei, encontrei uma nota de que, embora tivesse substituído 4 ou 5 arquivos relacionados ao .NET com sucesso, houve um desses arquivos que não consegui substituir porque estava "em uso" no momento. Esse arquivo? System.ni.dll!!! Agora consegui substituir esse arquivo do backup e pronto, minha instalação do .NET voltou ao normal, os aplicativos funcionam com perfil ou não.
O frustrante é que, quando esse incidente ocorreu pela primeira vez, eu esperava que o problema estivesse relacionado a um arquivo danificado e, especificamente, a um arquivo chamado System.dll que hospedava os métodos que falharam. E então eu diferenciei e refiz todos os arquivos chamados System.dll. Mas eu não percebi naquela época que System.ni.dll era uma manifestação nativa compilada de System.dll (ou algo assim). E como eu tinha diferenciado e alterado os diretórios relacionados ao .NET e não percebi isso (não tenho ideia de como não percebi), desisti dessa abordagem.
De qualquer forma... resumindo a história, foi um System.ni.dll danificado que causou meus problemas, um ou mais clusters dentro dele tiveram seu conteúdo substituído por 0x0 e aconteceu de se manifestar como o estranho problema que observei.