Como executar o sfc /scannow para reparar os arquivos de sistema do Windows

O que o sfc /scannow realmente faz

O System File Checker compara cada arquivo de sistema protegido — as DLLs e executáveis de que o próprio Windows é feito — com as cópias de referência guardadas em C:\Windows\WinSxS. Se um arquivo no disco difere do exemplar de referência, o SFC o substitui; se o exemplar no repositório é que está danificado, o SFC informa o arquivo mas não consegue repará-lo — é exatamente para isso que existe o DISM. A verificação exige um console com direitos de administrador: Win+X → Terminal (Administrador). Só o disco local é lido, então internet não é necessária.

Recorre-se ao SFC quando o Windows se comporta como se ele mesmo estivesse danificado: depois de uma atualização falha, de um desligamento bruto durante a manutenção ou da remoção de um malware que deixou sequelas. O comando é totalmente inofensivo para os dados pessoais: perfis de usuário, documentos e as pastas próprias dos programas não são lidos nem alterados.

• Depois de uma atualização do Windows que quebra no meio ou reverte em loop
• Quando telas azuis como CRITICAL_PROCESS_DIED ou IRQL_NOT_LESS_OR_EQUAL surgem sem motivo de hardware
• Após remover malware, para confirmar que os arquivos de sistema sobreviveram
• Quando os aplicativos internos, o menu Iniciar ou as Configurações crasham ao abrir
• Antes de uma reparação in-place — talvez os 20 minutos de verificação economizem a hora de reinstalação
• Quando o próprio DISM ou o Windows Update relatam repositório corrompido

Rodar o SFC e ler o resultado

Abra o Terminal (Administrador) pelo Win+X ou pelo clique direito no Iniciar, digite sfc /scannow e pressione Enter. A verificação mostra uma porcentagem e normalmente termina em 5 a 20 minutos — bem mais em HDDs antigos —, e a janela do console precisa ficar aberta até o fim. São quatro os desfechos possíveis, e cada um tem o seu próximo passo.

“Windows Resource Protection did not find any integrity violations” quer dizer que os arquivos de sistema estão limpos e que a causa do problema está em outro lugar. “Found corrupt files and successfully repaired them” é a vitória: reinicie para que os arquivos reparados sejam mesmo carregados. “Found corrupt files but was unable to fix some of them” aponta para um repositório de componentes danificado: execute DISM /Online /Cleanup-Image /RestoreHealth e repita a passada do SFC. “Could not perform the requested operation” quase sempre indica operações de manutenção pendentes — reinicie e tente de novo.

Quando o SFC não dá conta: DISM primeiro, repetir depois

O SFC só é tão saudável quanto o repositório de onde ele repara, então a escada que funciona é DISM RestoreHealth → sfc /scannow → reinício. Os detalhes de cada reparo caem em C:\Windows\Logs\CBS\CBS.log; para ver só as linhas do SFC, o findstr /c:[SR] %windir%\Logs\CBS\CBS.log resolve. Para casos específicos há variantes: sfc /verifyonly compara sem alterar nada, e sfc /scanfile=C:\Windows\System32\broken.dll examina um único arquivo.

Um aviso sobre o repositório de que o SFC depende: nunca apague nada de dentro de C:\Windows\WinSxS na mão, nem deixe que “otimizadores” o façam — um repositório esvaziado transforma cada SFC futuro num relatório de danos irrecuperáveis. Use o caminho oficial do StartComponentCleanup. Rodar o SFC por rotina não acrescenta nada: dispare-o sob suspeita e depois de incidentes, não por agenda.

Perguntas e respostas

Continue lendo

Todos os artigos · FAQ