Windows 7 .NET 3.5.1 - 2.0 Levemente Corrompido, Como Consertar?

Question

Meu Windows 7, que inclui a instalação do .NET (3.5 para 2.0), aparece muito pouco e está particularmente corrompido, e estou tentando corrigi-lo sem reinstalar o Windows ou tentar reverter para backups.

Tudo estava funcionando e, em seguida, meu disco rígido começou a corromper alguns arquivos e o checkdisk encontrou clusters defeituosos, então gravei a unidade para um novo. Assim que eu iniciei na nova unidade, tudo funcionou exceto programas que chamam os métodos System.Net.NetworkInformation dentro do .NET 3.5 para 2.0 (como Ping () e IsNetworkAvailable ()), que imediatamente causam aplicativo em que as chamadas são (as chamadas no .NET 4.0 funcionam bem). Esses métodos são encontrados dentro System.dll, e eu assumo chamar métodos nativos que eu acredito que estão dentro winnsi.dll ou iphlpapi.dll ou outra coisa (eu não encontrei isso ainda); Suponho que ele chame métodos nativos porque a exceção que causa a falha é o erro Fatal Execution Engine, 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 está no fato de que quando eu inicio o mesmo aplicativo que falha por meio de um profiler de código (que executa o exe e captura estatísticas sobre quais métodos demoraram mais tempo) o aplicativo funciona bem, sem travamento em absoluto! Como poderia executá-lo dentro do trabalho de profiler e executá-lo fora não funciona? Essa parece a chave para o mistério.

• Eu usei 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 gerenciador de perfis e comparei as duas saídas, mas não aprendi muito (vejo o momento em que -profile app falha, mas até então eles se comportam da mesma forma, carregou 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 4-6 novos encadeamentos e o código executado diretamente cria apenas 1-2.
• Eu diferi os arquivos / diretórios que pareciam mais relevantes (o material do .NET no Windows e Program Files) antes e depois do disco e não vi nenhuma alteração onde eu não esperava nenhum (nenhuma corrupção de arquivo óbvia).
• Eu desviei o registro do software e do sistema para problemas pré e pós-disco e não vi alterações que parecessem relevantes.
• Eu criei uma nova conta de usuário e limpei todas as variáveis de ambiente no caso de o ambiente estar relacionado. Nenhuma mudança.
• Eu fiz "sfc / scannow" e não encontrei problemas de integridade.
• Eu tentei "ngen update" para regenerar o código pré-compilado caso eu perdesse algo que poderia estar danificado e nada mudou.

Suponho 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. Eu não tenho acesso aos discos do Windows para tentar reinstalar o Windows sobre si mesmo (o computador tem uma partição de recuperação, mas é 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 novo Windows, reinstalar dezenas de pacotes de software, tentar lembrar dezenas de customizações relacionadas ao desenvolvimento / etc.

Dado tudo isso ... alguém tem algum conselho útil? Eu preciso do .NET 3.5 - 2.0 funcionando, pois sou um desenvolvedor e preciso criar e testar.

Obrigado!

Quinxy

    

Answer 1

A resposta curta é que meu arquivo System.ni.dll foi danificado, eu o substituí e tudo está bem.

Lembrei-me de que deveria verificar novamente o log chkdsk que mantive listando os arquivos que foram danificados pela falha da unidade. Após a falha eu tinha transformado todos os ids de arquivo listados em arquivos caminhos / nomes e eu tinha substituído todos os 100 + arquivos que eu poderia de backup, mas com certeza quando voltei agora e olhei eu encontrei uma nota que enquanto eu tinha substituído 4 ou 5 arquivos relacionados ao .NET com sucesso, havia um desses arquivos que não consegui substituir porque estava "em uso" no momento. Aquele arquivo? System.ni.dll !!! Eu agora era capaz de substituir este arquivo de backup e voila minha instalação do .NET está de volta ao normal, aplicativos funcionam se perfilado ou não.

O mais frustrante é que, quando esse incidente ocorreu pela primeira vez, esperava-se que o problema se relacionasse a um arquivo danificado e, especificamente, a um arquivo chamado System.dll, que abrigava os métodos que falharam. E assim, eu fiz a diferença e retifiquei todos os arquivos denominados System.dll. Mas eu não percebi naquele momento que System.ni.dll foi uma manifestação nativa compilada de System.dll (ou algo assim). E porque eu tinha diffed e rediffed os diretórios relacionados .NET e não percebi isso (não faço idéia de como eu perdi) eu tinha desistido dessa abordagem.

Enfim ... longa história, foi um System.ni.dll danificado que causou meus problemas, um ou mais clusters dentro dele teve seu conteúdo substituído por 0x0 e isso só aconteceu para se manifestar como o problema estranho que eu observei .