A recuperação de instalações corrompidas de softwares e principalmente do sistema operacional/ambiente gráfico na grande maioria dos casos não tem sucesso, resultando em um sistema bastante instável, além do tempo gasto na tentativa de recuperação, bem maior do que o tempo gasto em uma instalação do zero.
Isto ocorre porque o DOS/Windows tem muitas dependências. DLLs, Registry, arquivos INI, TypeLibs (para OLE) são compartilhados e atualizados sem nenhum controle por diversos softwares.
Após um problema de consistência de disco, nunca se sabe até onde foi o estrago e quais aplicativos foram afetados. Não existe alternativa a não ser reinstalar os aplicativos um-a-um e aguardar que o próximo aplicativo "dê pau" para reinstalar o próximo.
Entretanto, muitos aplicativos instalam DLLs e realizam outras modificações no sistema sem verificar se esta modificação pode ser realizada (por exemplo, sobreescrevendo uma DLL já existente por uma de versão mais antiga ou apagando uma sub-árvore inteira do Registry para gravar uma árvore nova, em vez de simplesmente editar as chaves necessárias). Por outro lado, se o instalador foi corretamente escrito, ele nunca irá recuperar as DLLs corrompidas porque não irá sobreescrever arquivos já existentes.
Resumindo, em vez de se tentar recuperar uma instalação corrompida, deve-se remover toda a instalação e realizar uma nova do zero. No Windows, a maioria das situações implica em se formatar o HD e reinstalar o Windows, service packs e aplicativos.
É um processo muito demorado, mas na maioria das vezes a tentativa de recuperação demora ainda mais. Só que a instalação do zero pode ser acelerada, enquanto que a tentativa de recuperação não pode. Você pode acelerar a reinstalação tendo todos os softwares (ou os principais) disponíveis em local de fácil acesso, como CDs, ZIP Drive ou drive de rede (esta é a mais rápida), escrevendo scripts de instalação automatizada e mantendo uma clara separação dos arquivos de programas, do sistema e de dados do usuário tanto no disco local quanto no de rede, de modo que os dados não necessitem ser sempre reinstalados, e que eles sejam "beckapeados" e restaurados fácil e rapidamente.
Outro problema que normalmente acontece é relativo a hardware. O hardware do PC é de muito má qualidade, e existem diversos conflitos entre as diversas PROMs de placa-mãe, placa de vídeo, SCSI, placa de rede, etc. Juntando-se a memórias também de baixa qualidade, é muito difícil estabelecer se a instabilidade de um PC é de software ou de hardware.
Entretanto, se pouco após uma instalação do zero os problemas ressurgem, podemos suspeitar de hardware ou de rede elétrica. Problemas de rede elétrica cedo ou tarde danificam o hardware. No Windows, é sempre uma boa idéia trocar a placa de vídeo de um PC instável por outro modelo de outro fabricante, visto que este é o componente mais susceptível a problemas de bugs no device-driver e de conflitos de PROM (esses conflitos de PROM são na verdade bugs no firmware). É procedimento padrão da Microsoft mudar o vídeo para driver VGA ou trocar a placa de uma vez. Persistindo a instabilidade, troque os pentes de memória, depois outras placas como de rede ou SCSI, e por fim troque a placa-mãe.
Lembre-se: o fato de um componente funcionar sem problemas em um dado PC não significa que ele irá funcionar ok em outros PCs.
Lembre-se também que o fato de um componente funcionar bem em DOS ou Windows 3.x não significa que ele irá funcionar bem em outros sistemas como Windows 95, NT, OS/2, SCO Unix, Linux ou Netware. Além desses sistemas exigirem bem mais do hardware, eles trazem seu próprio conjunto de situações em que bugs de device-drivers e de PROMs se manifestam. Somando-se isto ao fato de que poucas empresas tem pessoal especializado e capacidade de investimento para escrever e depurar os device-drivers e firmware em sistemas que não do DOS/Windows e o Netware (esses são os mais conhecidos, mais simples e conseqüentemente os mais baratos), não espere que um PC DOS/Windows continue funcionando 100% em outros sistemas. Com micros e componentes mais antigos, o Windows 95 também se torna um risco.
O problema é tão sério que os maiores fabricantes de PCs dos Estados Unidos (Compaq, HP, IBM, Acer e Gateway) liberaram patches nos seus sites web pouco depois do lançamento do Windows 98. Alguns patches modificavam o próprio Windows 98, enquanto que outros eram fixes para os device-drivers e firmware dos próprios fabricantes.
A maioria do pessoal certificado como MCSE que tem também experiência com outros sistemas (Netwre, Unix, OS/2) concorda que o NT é de longe o mais instável de todos em relação a hardware. E tinha que ser, pois o NT, apesar de 8 anos de existência, já teve 3 modelos diferentes de arquitetura de kernel e interface de device-drivers, e terá o quarto modelo quando sair o NT 5.0. Ou seja, a experiência anterior em escrever e depurar hardware para NT será jogada fora. Contraste isto com o modelo de interface e arquitetura de kernel mantidos sem alterações significativas pelo Netware, OS/2 e Unix durante o mesmo período. Esta estabilidade de kernel não impediu que o Netware incorpore o NDS e o HSS, que o OS/2 incorpore novos protocolos de rede e dispositivos de armazenamento ou que o Unix evolua para 64bits. Esta estabilidade é sinal de um bom projeto, enquanto que a instabilidade (das APIs) do kernel do NT demonstra um projeto incompleto seguido por remendos diversos.
