Você abre o Windows Update, procura novas atualizações e o Windows 11 encontra normalmente uma atualização cumulativa.
O download começa.
Chega a 100%.
A instalação avança.
Então alguma coisa dá errado.
Depois de alguns minutos, aparece um código:
0x80073712
À primeira vista, esse erro pode parecer apenas mais uma falha genérica do Windows Update. Porém, ele merece uma investigação diferente daquela utilizada para problemas de Internet ou simples falhas de download.
O código 0x80073712 está associado a situações em que arquivos necessários ao Windows Update ou ao mecanismo de manutenção do Windows estão ausentes ou danificados.
Isso nos leva diretamente a uma das estruturas mais importantes — e menos compreendidas — do Windows:
o armazenamento de componentes, ou Component Store.
Neste guia da VMIA, vamos entender o que acontece dentro do Windows 11 quando o erro 0x80073712 aparece, qual é sua relação com WinSxS, Component-Based Servicing, DISM, SFC, CBS.log e Windows Update e, principalmente, como diagnosticar a causa antes de começar a apagar pastas ou executar dezenas de comandos.
O que significa o erro 0x80073712?
O código:
0x80073712
pode aparecer quando arquivos ou componentes necessários a uma operação de atualização estão ausentes ou apresentam problemas.
Existe uma diferença importante em relação a uma simples falha de download.
O computador pode:
- estar conectado à Internet;
- acessar sites normalmente;
- encontrar atualizações;
- baixar os pacotes;
e ainda assim não conseguir instalar a atualização.
Por quê?
Porque baixar um pacote e conseguir aplicá-lo ao Windows são etapas diferentes.
O Windows Update pode conseguir obter a atualização dos servidores e, posteriormente, encontrar um problema quando o mecanismo de servicing tenta processar componentes, dependências ou informações necessárias à instalação.
É por isso que trocar DNS ou reiniciar o roteador nem sempre faz qualquer diferença nesse erro.
0x80073712 não significa simplesmente “Windows Update quebrado”
Essa distinção será fundamental durante todo o artigo.
Quando alguém diz:
“Meu Windows Update não funciona.”
a informação ainda é insuficiente.
Precisamos perguntar:
Em qual etapa ele não funciona?
O Windows precisa realizar várias operações durante uma atualização:
- procurar atualizações;
- determinar quais pacotes são aplicáveis;
- baixar conteúdo;
- validar o pacote;
- preparar a instalação;
- processar dependências;
- atualizar componentes;
- realizar operações que exigem reinicialização;
- confirmar o novo estado do sistema.
O 0x80073712 pode aparecer em uma etapa muito diferente daquela de um erro de conexão.
Portanto, o diagnóstico também precisa ser diferente.
O que é o Component Store?
O Windows não funciona apenas com os arquivos que enxergamos em:
C:\Windows\System32
Existe uma infraestrutura responsável pela manutenção dos componentes do sistema.
Uma parte fundamental dessa infraestrutura é conhecida como:
Component Store
Ela está associada principalmente ao diretório:
C:\Windows\WinSxS
Essa estrutura permite que o Windows mantenha e gerencie componentes utilizados para:
- atualizações;
- recursos opcionais;
- reparações;
- manutenção;
- substituição de componentes;
- compatibilidade entre diferentes estados do sistema.
Portanto, WinSxS não é simplesmente uma enorme pasta cheia de “arquivos velhos”.
Ela participa diretamente da capacidade do Windows de manter a si próprio.
Por que o Windows precisa de um armazenamento de componentes?
Imagine uma atualização que precisa substituir determinado componente do Windows.
Não basta simplesmente:
- baixar uma DLL;
- copiar para System32;
- reiniciar.
O Windows precisa controlar:
- qual pacote fornece aquele componente;
- qual versão está instalada;
- quais dependências existem;
- qual atualização modificou o componente;
- quais recursos dependem dele;
- quais operações precisam ocorrer durante a reinicialização.
É um sistema muito mais complexo.
Essa arquitetura permite que o Windows mantenha milhares de componentes sem depender de substituições aleatórias de arquivos.
Por outro lado, se as informações necessárias para esse mecanismo ficarem inconsistentes, as atualizações podem falhar.
O que significa Component-Based Servicing?
Outro termo importante é:
CBS — Component-Based Servicing
O Windows utiliza uma arquitetura de manutenção baseada em componentes.
Isso significa que atualizações e alterações do sistema são processadas considerando componentes, pacotes, versões e dependências.
Por isso existe um log extremamente importante chamado:
CBS.log
Normalmente localizado em:
C:\Windows\Logs\CBS\CBS.log
Quando o Windows apresenta problemas relacionados a servicing, esse arquivo pode fornecer pistas que a tela do Windows Update simplesmente não mostra.
Voltaremos a ele mais adiante.
Por que o erro 0x80073712 pode impedir uma atualização cumulativa?
Uma atualização cumulativa não funciona como um instalador convencional de um pequeno programa.
Ela pode modificar diversos componentes do Windows.
Durante o processo, o mecanismo de servicing precisa avaliar o estado atual do sistema e aplicar as alterações correspondentes.
Se informações ou arquivos necessários a esse processo estiverem ausentes ou corrompidos, a atualização pode não conseguir avançar.
O Windows pode então:
- interromper a instalação;
- desfazer alterações;
- solicitar nova tentativa;
- apresentar um código de erro.
Entre esses códigos pode aparecer:
0x80073712
Por isso, simplesmente baixar novamente a atualização pode não resolver.
O pacote novo pode estar perfeito.
O problema pode estar no estado da instalação que deverá recebê-lo.
O download chega a 100%, mas a atualização falha
Esse comportamento confunde muitos usuários.
Se chegou a 100%, parece lógico concluir:
“A atualização foi baixada corretamente, então deveria instalar.”
Mas download e instalação são processos diferentes.
Imagine um arquivo ZIP.
Você pode baixar o arquivo perfeitamente.
Isso não garante que seu conteúdo possa ser integrado corretamente a outro sistema complexo.
No Windows Update acontece algo conceitualmente parecido.
O pacote pode chegar ao computador, mas o Windows ainda precisa processá-lo.
Portanto:
100% de download não significa 100% de atualização concluída.
O erro pode aparecer somente depois da reinicialização?
Sim.
Algumas operações de atualização não podem ser concluídas enquanto determinados componentes estão em uso.
Nesses casos, parte do processo acontece durante a reinicialização.
O usuário pode observar mensagens como:
Trabalhando nas atualizações
ou perceber que o computador reinicia mais de uma vez.
Se o Windows não conseguir completar uma etapa crítica, poderá tentar reverter alterações.
Depois que o sistema iniciar novamente, o Histórico de Atualizações poderá indicar falha.
Esse cenário merece atenção especial aos logs e ao estado do Component Store.
O que é corrupção do Component Store?
A palavra “corrupção” pode parecer assustadora, mas precisamos utilizá-la de maneira técnica.
Não significa necessariamente que todo o Windows esteja destruído.
Pode existir uma inconsistência envolvendo determinados componentes necessários à manutenção do sistema.
Dependendo da extensão do problema, o computador pode continuar:
- inicializando;
- abrindo programas;
- navegando na Internet;
- imprimindo;
- executando jogos;
- acessando arquivos normalmente.
O problema aparece somente quando o Windows precisa realizar uma operação específica de servicing.
É por isso que alguns computadores parecem completamente normais até o dia em que uma atualização não instala.
Como o Component Store pode apresentar problemas?
Não existe uma única causa.
Problemas podem aparecer depois de situações como:
- interrupções durante atualizações;
- desligamentos inesperados;
- operações de manutenção incompletas;
- corrupção do sistema de arquivos;
- problemas de armazenamento;
- interferência de software;
- alterações indevidas em arquivos protegidos;
- falhas durante servicing.
Mas atenção:
encontrar 0x80073712 não permite concluir automaticamente qual desses fatores ocorreu.
Precisamos investigar.
Uma queda de energia pode causar 0x80073712?
Pode contribuir para inconsistências se ocorrer durante uma operação crítica, mas o código sozinho não prova que uma queda de energia foi a causa.
Esse é um princípio importante para diagnóstico.
Existe diferença entre:
“isso pode causar o problema”
e:
“isso causou este problema”.
Para chegar à segunda afirmação precisamos de evidências.
Logs, histórico, eventos e o contexto em que a falha começou ajudam a reconstruir o que aconteceu.
O SSD pode causar o erro?
Problemas de armazenamento também podem contribuir para corrupção de dados.
Entretanto:
0x80073712 não é um diagnóstico de SSD defeituoso.
Não troque o SSD simplesmente porque encontrou esse código.
Por outro lado, se o computador também apresenta:
- corrupção recorrente;
- arquivos desaparecendo;
- erros de leitura;
- travamentos;
- erros do sistema de arquivos;
- problemas relacionados ao armazenamento nos logs;
então faz sentido ampliar a investigação.
O erro do Windows Update pode ser apenas um dos sintomas.
E a memória RAM?
O mesmo princípio vale para a memória.
Instabilidade de RAM pode produzir diversos comportamentos estranhos, mas 0x80073712 isoladamente não comprova defeito de memória.
Se existem:
- travamentos aleatórios;
- telas azuis;
- corrupção recorrente;
- programas fechando inesperadamente;
- erros diferentes a cada tentativa;
uma investigação de hardware pode entrar no diagnóstico.
Mas não devemos transformar possibilidades em certezas.
Primeiro passo: identifique exatamente o Windows instalado
Antes de reparar qualquer coisa, pressione:
Windows + R
Digite:
winver
Anote:
- versão;
- compilação.
Depois abra o Terminal como administrador e execute:
DISM /Online /Get-CurrentEdition
Isso ajuda a identificar a edição instalada.
Também podemos executar:
systeminfo
para obter informações adicionais.
Esses dados serão importantes caso seja necessário utilizar uma mídia de instalação posteriormente.
Segundo passo: descubra qual atualização está falhando
Abra:
Configurações → Windows Update → Histórico de atualizações
Procure a atualização que apresentou falha.
Anote o número:
KBxxxxxxx
Esse identificador é extremamente importante.
Em vez de investigar:
“Windows Update não funciona”
passamos a investigar:
“KB específica falha no Windows 11 com 0x80073712.”
Isso reduz drasticamente o universo de possibilidades.
Todas as atualizações falham ou somente uma?
Faça essa pergunta antes de modificar o sistema.
Temos dois cenários muito diferentes.
Cenário A
Várias atualizações falham.
Isso pode indicar um problema mais amplo no mecanismo de atualização ou servicing.
Cenário B
Somente uma atualização específica falha.
Nesse caso, devemos investigar aquela KB, seus requisitos e o estado dos componentes que ela tenta atualizar.
Essa distinção evita redefinir todo o Windows Update quando o problema está restrito a uma operação específica.
Terceiro passo: execute CheckHealth
Abra o Terminal como administrador.
Execute:
DISM /Online /Cleanup-Image /CheckHealth
Esse comando realiza uma verificação rápida para descobrir se a imagem já está marcada como corrompida e se existe indicação de possibilidade de reparação.
Ele não substitui uma análise completa.
Sua principal vantagem é a velocidade.
Quarto passo: execute ScanHealth
Agora execute:
DISM /Online /Cleanup-Image /ScanHealth
Essa análise é mais profunda.
Pode levar algum tempo.
Não interrompa simplesmente porque a porcentagem parece permanecer parada.
O DISM pode continuar trabalhando mesmo quando o indicador visual demora para avançar.
O resultado desse comando começa a responder uma pergunta fundamental:
o armazenamento de componentes apresenta corrupção detectável?
Quinto passo: tente RestoreHealth
Se o diagnóstico indicar necessidade de reparação, podemos utilizar:
DISM /Online /Cleanup-Image /RestoreHealth
O objetivo é reparar a imagem do Windows.
Observe cuidadosamente a mensagem final.
Não feche a janela imediatamente.
Anote:
- código de erro;
- mensagem;
- porcentagem em que ocorreu;
- horário aproximado.
Essas informações ajudarão na análise dos logs.
Não execute DISM dez vezes seguidas
Se:
DISM /Online /Cleanup-Image /RestoreHealth
falhar, repetir exatamente o mesmo comando várias vezes sem modificar nenhuma condição geralmente acrescenta pouca informação.
A próxima etapa deve ser:
descobrir por que falhou.
É aí que entram:
DISM.log
e:
CBS.log
Onde fica o DISM.log?
Normalmente:
C:\Windows\Logs\DISM\dism.log
O arquivo registra detalhes das operações executadas pelo DISM.
Procure:
- código 0x80073712;
error;failed;- mensagens próximas ao horário da tentativa.
Mas não analise apenas a linha onde aparece o código.
Leia também o contexto.
O erro final pode ser consequência de uma falha registrada algumas linhas antes.
Onde fica o CBS.log?
Normalmente:
C:\Windows\Logs\CBS\CBS.log
Esse log merece atenção especial neste artigo.
Como o 0x80073712 pode envolver problemas relacionados ao armazenamento de componentes, o CBS.log pode fornecer pistas importantes sobre o processo que falhou.
Procure eventos próximos ao horário em que:
- DISM falhou;
- Windows Update apresentou erro;
- atualização foi revertida.
Essa correlação temporal ajuda muito.
Por que anotar o horário da falha?
Imagine um CBS.log contendo milhares de registros.
Você encontra dezenas de ocorrências de:
error
Qual delas corresponde ao problema atual?
Uma técnica simples é:
- anotar o horário;
- executar novamente a operação;
- esperar o erro;
- consultar os logs imediatamente;
- procurar eventos naquele intervalo.
Por exemplo:
10:17 — iniciei RestoreHealth
10:24 — ocorreu o erro
Agora temos uma janela de aproximadamente sete minutos para investigar.
Isso é muito mais eficiente.
CBS.log pode revelar mais do que o código mostrado na tela
A interface do Windows Update precisa apresentar uma mensagem compreensível e relativamente curta.
O mecanismo interno trabalha com muito mais informações.
Nos logs podemos encontrar referências a:
- pacotes;
- componentes;
- arquivos;
- operações;
- manifestos;
- estados;
- tentativas de reparação.
Essas informações ajudam a descobrir se estamos realmente diante de corrupção do Component Store ou de outro problema.
E onde entra o SFC?
Depois de investigar o estado do Component Store, também podemos verificar os arquivos protegidos do Windows.
Execute:
sfc /scannow
SFC significa:
System File Checker.
Ele verifica arquivos protegidos do sistema e tenta reparar problemas encontrados.
Mas existe uma relação importante:
o SFC depende da infraestrutura de componentes do Windows para realizar determinadas reparações.
Se o armazenamento utilizado como referência estiver problemático, o SFC pode encontrar arquivos corrompidos e não conseguir restaurá-los corretamente.
Por isso, DISM e SFC são frequentemente utilizados juntos.
DISM e SFC não são a mesma ferramenta
Esse ponto merece destaque.
DISM /Online /Cleanup-Image /RestoreHealth
e:
sfc /scannow
não fazem exatamente a mesma coisa.
De forma simplificada:
DISM: trabalha com a imagem e o armazenamento de componentes.
SFC: verifica arquivos protegidos do sistema.
Quando o Component Store está saudável, ele pode fornecer conteúdo necessário para que outros mecanismos restaurem arquivos corretamente.
Essa relação explica por que, em determinados cenários, faz sentido reparar primeiro a imagem e depois executar SFC novamente.
Como saber quais arquivos o SFC não conseguiu reparar?
As informações do SFC são registradas no CBS.log.
Podemos extrair entradas relacionadas ao SFC com:
findstr /c:"[SR]" %windir%\Logs\CBS\CBS.log > "%userprofile%\Desktop\sfcdetails.txt"
Isso cria:
sfcdetails.txt
na Área de Trabalho.
O arquivo facilita a leitura das entradas relacionadas ao SFC.
Mas existe um detalhe:
ele pode conter registros de várias execuções.
Observe datas e horários.
Não baixe arquivos individuais para “consertar” o Windows
Se o CBS.log indicar problema envolvendo uma DLL ou outro componente, não procure simplesmente o nome daquele arquivo na Internet.
Evite sites que oferecem:
“Download DLL grátis.”
O arquivo pode:
- pertencer a outra build;
- possuir versão diferente;
- ter dependências incompatíveis;
- não possuir origem confiável;
- comprometer a segurança do computador.
O Windows possui mecanismos próprios de servicing justamente para evitar substituições aleatórias de componentes.
Não apague WinSxS manualmente
Outro erro grave é tentar resolver o problema apagando conteúdo de:
C:\Windows\WinSxS
Não faça isso.
A pasta participa diretamente do armazenamento de componentes.
Excluir arquivos manualmente pode prejudicar ainda mais:
- Windows Update;
- DISM;
- SFC;
- recursos opcionais;
- reparações;
- futuras atualizações.
Se o Component Store apresenta problema, devemos repará-lo através das ferramentas apropriadas.
Não destruí-lo para economizar espaço.
0x80073712 e 0x800f081f são a mesma coisa?
Não.
Os dois códigos podem aparecer em contextos envolvendo servicing e reparação, e por isso podem acabar sendo tratados juntos em tutoriais.
Mas eles não devem ser considerados sinônimos.
No artigo anterior da VMIA, analisamos o 0x800f081f, especialmente importante quando o Windows não consegue localizar os arquivos de origem necessários para determinada operação.
Agora estamos investigando o 0x80073712, no qual precisamos dar atenção especial à integridade dos componentes e arquivos necessários ao processo de atualização.
Os procedimentos podem se cruzar.
O diagnóstico, porém, precisa partir do código e das evidências encontradas naquele computador.
O que não fazer ao encontrar 0x80073712
Evite começar desta forma:
- apagar SoftwareDistribution;
- apagar WinSxS;
- baixar DLLs;
- alterar Registro;
- remover serviços;
- executar scripts desconhecidos;
- instalar “programas reparadores”;
- formatar imediatamente.
Algumas ferramentas utilizadas em tutoriais podem fazer sentido em situações específicas.
O problema está em aplicá-las sem saber qual componente falhou.
Primeiro investigue.
Depois corrija.
Nossa sequência inicial de diagnóstico
Até aqui, temos uma metodologia:
1. Identificar o Windows
winver
DISM /Online /Get-CurrentEdition
2. Identificar a atualização
Anotar a KB problemática.
3. Verificar o Component Store
DISM /Online /Cleanup-Image /CheckHealth
DISM /Online /Cleanup-Image /ScanHealth
4. Tentar reparação
DISM /Online /Cleanup-Image /RestoreHealth
5. Se falhar
Consultar:
C:\Windows\Logs\DISM\dism.log
e:
C:\Windows\Logs\CBS\CBS.log
6. Verificar arquivos protegidos
sfc /scannow
A partir dos resultados, podemos decidir a próxima etapa.
Isso é muito mais seguro do que executar uma sequência fixa de comandos para qualquer erro do Windows Update.
Como descobrir o que está causando o erro 0x80073712 no Windows 11
Na primeira parte entendemos que o erro 0x80073712 não deve ser tratado simplesmente como uma falha genérica do Windows Update.
O Windows pode localizar uma atualização, baixá-la completamente e ainda assim não conseguir instalá-la.
Isso acontece porque obter o pacote e aplicar suas alterações ao sistema são processos diferentes.
Agora vamos aprofundar o diagnóstico.
Nosso objetivo será descobrir se a falha está relacionada:
- ao armazenamento de componentes;
- a arquivos protegidos;
- a uma atualização específica;
- ao mecanismo do Windows Update;
- ao cache de atualização;
- aos serviços envolvidos;
- ou a uma combinação desses fatores.
A principal ferramenta para essa investigação será algo que muitos usuários nunca abrem:
os logs do próprio Windows.
Comece reproduzindo o problema de maneira controlada
Antes de abrir um arquivo enorme de log, faça algo simples.
Anote o horário.
Por exemplo:
14:32 — tentativa de instalar KBxxxxxxx.
Depois abra:
Configurações → Windows Update
e tente novamente a atualização.
Espere o erro aparecer.
Anote:
- horário;
- número da KB;
- código apresentado;
- etapa aproximada em que ocorreu;
- se houve reinicialização;
- se o Windows desfez alterações.
Agora temos uma referência temporal.
Isso ajuda bastante na leitura dos logs.
O primeiro log: DISM.log
Se você executou:
DISM /Online /Cleanup-Image /RestoreHealth
o registro principal do DISM normalmente fica em:
C:\Windows\Logs\DISM\dism.log
Abra o arquivo em um editor de texto.
Procure pelo horário da tentativa.
Depois pesquise:
0x80073712
Também podem ser úteis termos como:
error
failed
corrupt
repair
package
Mas existe um cuidado importante.
Encontrar a palavra:
error
não significa necessariamente que encontramos a causa.
Logs registram várias operações internas, tentativas e condições intermediárias.
Precisamos analisar o contexto.
O erro final pode ser apenas a consequência
Imagine esta situação simplificada:
O DISM tenta processar um componente.
Encontra uma inconsistência.
Tenta localizar informação necessária.
A operação falha.
Depois, no final, registra:
0x80073712
Se olharmos apenas a última linha, saberemos qual foi o resultado.
Mas talvez não saibamos por que ele aconteceu.
Por isso, examine também as linhas anteriores.
O objetivo é encontrar a primeira falha relevante dentro daquela sequência.
O CBS.log é ainda mais importante neste erro
O arquivo:
C:\Windows\Logs\CBS\CBS.log
registra informações do Component-Based Servicing.
Como estamos investigando um problema potencialmente relacionado ao armazenamento de componentes, esse log pode ser extremamente útil.
Ele pode conter referências a:
- pacotes;
- componentes;
- manifestos;
- arquivos;
- estados de instalação;
- reparações;
- operações pendentes;
- inconsistências.
Isso não significa que cada linha seja fácil de interpretar.
Mas podemos reduzir bastante o trabalho usando horário, código de erro e nome da atualização.
Como pesquisar o CBS.log
Comece pelo código:
0x80073712
Depois procure:
corrupt
error
failed
package
Se você conhece a KB problemática, procure também:
KBxxxxxxx
Nem sempre todos esses termos estarão presentes exatamente dessa forma.
Eles servem como pontos iniciais.
O mais importante é correlacionar os registros com o horário em que a operação falhou.
O CBS.log ficou grande demais?
Isso é normal.
O arquivo pode crescer bastante porque registra muitas operações de servicing.
Além disso, o Windows pode manter arquivos anteriores rotacionados ou compactados dentro da pasta de logs.
Por isso, pesquisar por horário é muito mais eficiente do que tentar ler tudo.
Se você acabou de reproduzir o erro, comece pelas entradas mais recentes.
Não altere o CBS.log
O CBS.log serve para diagnóstico.
Não tente:
- editar;
- apagar linhas;
- substituir conteúdo;
- “corrigir” entradas manualmente.
Modificar o arquivo não corrige o componente que gerou o registro.
É como apagar uma mensagem de erro de um relatório: o problema que originou a mensagem continua existindo.
O que é um pacote no contexto do Windows?
Em servicing, o Windows trabalha com estruturas organizadas.
Uma atualização pode envolver pacotes que descrevem componentes e operações necessárias.
Isso permite que o Windows saiba:
- o que está instalado;
- o que precisa ser atualizado;
- quais dependências existem;
- quais operações devem ocorrer;
- qual estado determinado componente possui.
Quando informações necessárias a esse processo estão inconsistentes, o Windows pode não conseguir aplicar corretamente uma atualização.
É por isso que simplesmente copiar uma DLL para System32 não resolve necessariamente um problema de servicing.
O que são manifestos?
De forma simplificada, manifestos fornecem informações que ajudam o Windows a identificar e gerenciar componentes.
Eles fazem parte da infraestrutura que permite ao sistema compreender:
- componentes;
- versões;
- dependências;
- características da instalação.
Se uma operação precisa dessas informações e elas estão ausentes ou inconsistentes, o servicing pode falhar.
Isso ajuda a entender por que uma atualização aparentemente simples pode depender de muito mais do que os arquivos visíveis ao usuário.
O Component Store não é apenas um depósito de DLLs
Essa é uma ideia importante.
Quando falamos em:
C:\Windows\WinSxS
não estamos falando apenas de uma pasta contendo cópias de arquivos.
O armazenamento de componentes participa de uma estrutura de manutenção muito mais ampla.
Por isso, duas ações são particularmente perigosas:
1. apagar arquivos manualmente;
2. substituir componentes com arquivos baixados aleatoriamente da Internet.
Essas práticas podem criar exatamente o tipo de inconsistência que estamos tentando reparar.
Como o DISM classifica o estado do Component Store?
Execute:
DISM /Online /Cleanup-Image /ScanHealth
Dependendo do estado encontrado, o DISM pode indicar que:
- não detectou corrupção;
- detectou corrupção reparável;
- existem problemas que exigem investigação adicional.
A mensagem apresentada deve ser lida integralmente.
Não observe apenas se o comando chegou a 100%.
O resultado textual é o que interessa.
CheckHealth e ScanHealth não fazem a mesma coisa
CheckHealth é rápido:
DISM /Online /Cleanup-Image /CheckHealth
Ele verifica informações já existentes sobre o estado da imagem.
Já:
DISM /Online /Cleanup-Image /ScanHealth
realiza uma análise mais detalhada.
Portanto, executar CheckHealth e concluir imediatamente que “o Windows está perfeito” pode ser precipitado.
Quando existe suspeita real de corrupção, ScanHealth oferece uma investigação mais profunda.
E o RestoreHealth?
Quando apropriado:
DISM /Online /Cleanup-Image /RestoreHealth
tenta reparar a corrupção encontrada.
Se terminar corretamente, execute novamente:
DISM /Online /Cleanup-Image /ScanHealth
O objetivo é confirmar que o estado mudou.
Depois execute:
sfc /scannow
Isso verifica os arquivos protegidos do sistema.
O DISM diz que está saudável, mas 0x80073712 continua
Esse cenário é interessante.
Se:
ScanHealth
não detecta corrupção, mas uma atualização específica continua apresentando 0x80073712, precisamos evitar a conclusão automática de que “o DISM está errado”.
Podemos estar diante de:
- problema específico do pacote;
- estado pendente;
- falha no mecanismo do Windows Update;
- inconsistência que não está sendo exposta pela verificação executada;
- problema ocorrido durante outra etapa da atualização.
Nesse caso, os logs e a identificação da KB ganham ainda mais importância.
Todas as KBs funcionam menos uma
Esse é um dado diagnóstico extremamente valioso.
Imagine:
KB1 → instalada.
KB2 → instalada.
KB3 → 0x80073712.
KB4 → instalada.
Nesse computador, o Windows Update não está simplesmente “sem funcionar”.
Ele continua capaz de detectar, baixar e instalar atualizações.
A investigação deve se concentrar na KB que falha e no estado dos componentes envolvidos naquela instalação.
Nenhuma atualização instala
Agora temos outro cenário.
Se todas as atualizações começam a falhar, podemos investigar mais amplamente:
- serviços;
- cache;
- Component Store;
- políticas;
- integridade do sistema;
- operações pendentes;
- logs.
É nesse contexto que redefinir determinados componentes do Windows Update pode fazer mais sentido.
Onde entra o WindowsUpdate.log?
O Windows 11 utiliza mecanismos modernos de rastreamento do Windows Update.
Podemos gerar uma representação legível desses registros pelo PowerShell.
Execute:
Get-WindowsUpdateLog
O comando processará os rastreamentos disponíveis e criará um arquivo:
WindowsUpdate.log
Analise os eventos próximos ao horário da falha.
Procure:
- KB;
- código de erro;
- operações que falharam;
- sequência anterior ao erro.
Mas lembre-se:
WindowsUpdate.log e CBS.log observam partes diferentes do processo.
Uma falha pode começar no Windows Update e terminar no servicing.
Por isso, correlacionar logs é mais poderoso do que analisar somente um.
Uma forma prática de pensar nos logs
Podemos imaginar:
WindowsUpdate.log:
“O que aconteceu durante o processo de atualização?”
DISM.log:
“O que aconteceu durante a operação executada pelo DISM?”
CBS.log:
“O que aconteceu dentro do mecanismo de servicing baseado em componentes?”
Essa simplificação ajuda a escolher onde procurar.
SoftwareDistribution: o que é?
A pasta:
C:\Windows\SoftwareDistribution
é utilizada pelo Windows Update para armazenar dados relacionados ao processo de atualização.
Ela pode conter:
- arquivos temporários;
- conteúdo baixado;
- informações relacionadas às operações do Windows Update.
Problemas nesse cache podem causar determinados comportamentos estranhos.
Por isso, redefinir SoftwareDistribution aparece em muitos tutoriais.
Mas existe um problema:
a técnica virou solução universal para qualquer erro do Windows Update.
Ela não é.
Quando redefinir SoftwareDistribution pode ajudar?
Pode fazer sentido quando existem indícios de problemas relacionados a:
- downloads incompletos;
- cache inconsistente;
- atualização que tenta utilizar conteúdo problemático;
- Windows Update preso em determinado estado.
Mas se o verdadeiro problema é corrupção do Component Store, limpar o cache de download não necessariamente repara essa corrupção.
É como baixar novamente um instalador para um sistema que não consegue processá-lo.
O novo download pode estar perfeito e a instalação continuar falhando.
Não apague SoftwareDistribution com serviços trabalhando
Modificar pastas utilizadas pelo Windows Update enquanto seus componentes estão ativos pode gerar acesso negado ou comportamento inconsistente.
Quando existe motivo técnico para redefinir o cache, o procedimento precisa ser feito corretamente.
Normalmente é preferível renomear a pasta em vez de simplesmente apagá-la imediatamente.
Assim mantemos uma possibilidade de retorno e permitimos que o Windows crie uma nova estrutura.
Exemplo de redefinição controlada do cache
Abra o Terminal como administrador.
Podemos parar os serviços relacionados ao procedimento, por exemplo:
net stop wuauserv
e:
net stop bits
Depois, quando o diagnóstico justificar a ação, podemos renomear:
C:\Windows\SoftwareDistribution
para algo como:
SoftwareDistribution.old
Depois reiniciamos os serviços:
net start bits
net start wuauserv
O Windows poderá recriar a estrutura necessária.
Mas atenção:
isso não deve ser executado automaticamente só porque apareceu 0x80073712.
Faça quando existirem indícios de problema no mecanismo ou cache de atualização.
O histórico visual pode mudar depois da redefinição?
Dados apresentados pela interface do Windows Update podem ser afetados quando determinadas estruturas locais são recriadas.
Isso não significa necessariamente que atualizações instaladas foram desinstaladas.
Existe diferença entre:
informações locais utilizadas pela interface
e:
pacotes efetivamente instalados no sistema.
Por isso, não use apenas a aparência do histórico como prova de que uma atualização deixou de existir.
Como verificar atualizações instaladas por outro caminho?
Podemos consultar informações pelo sistema usando diferentes ferramentas.
Uma opção é:
Get-HotFix
no PowerShell.
Também podemos utilizar:
DISM /Online /Get-Packages
Esse segundo comando pode produzir uma lista grande.
Quando procuramos uma atualização específica, podemos filtrar ou pesquisar a saída.
Isso ajuda a comparar o que a interface mostra com o estado registrado pelo sistema.
E a pasta Catroot2?
Outro nome recorrente em tutoriais é:
C:\Windows\System32\catroot2
Ela participa de operações importantes relacionadas ao processamento de atualizações e dados criptográficos utilizados pelo Windows.
Problemas nessa estrutura podem interferir em determinadas operações.
Entretanto, novamente:
Catroot2 não deve ser redefinida automaticamente para qualquer erro.
Primeiro determine se existe motivo para suspeitar dessa camada.
Catroot e Catroot2 não são a mesma coisa
Esse detalhe é importante.
Existe:
catroot
e existe:
catroot2
Não trate as duas pastas como se fossem equivalentes.
Tutoriais que simplesmente dizem “apague a pasta catroot” sem especificar exatamente o que estão fazendo merecem cautela.
No contexto de redefinição de componentes do Windows Update, normalmente vemos referências à catroot2, não à remoção indiscriminada da estrutura catroot.
Não apague Catroot2 manualmente sem entender os serviços envolvidos
Assim como SoftwareDistribution, a pasta pode estar em uso.
Uma redefinição correta precisa considerar os serviços associados.
Além disso, se o problema estiver no Component Store, recriar Catroot2 pode não resolver nada.
A regra permanece:
ação deve corresponder à hipótese.
E o serviço Cryptographic Services?
O serviço de criptografia do Windows participa de diversas operações relacionadas a certificados, catálogos e validação.
Podemos consultar seu estado:
sc query cryptsvc
Mas encontrar o serviço parado em determinado instante não prova que ele esteja quebrado.
Serviços do Windows possuem diferentes comportamentos de inicialização.
Precisamos analisar:
- configuração;
- eventos;
- erro apresentado;
- momento da falha.
Não basta olhar “RUNNING” ou “STOPPED”.
Windows Update Service
Podemos consultar:
sc query wuauserv
Esse é o serviço associado ao Windows Update.
Novamente, o estado observado isoladamente não é diagnóstico.
O Windows pode iniciar determinados serviços quando necessário.
Se o serviço não inicia quando solicitado ou registra erro, aí temos uma pista mais relevante.
BITS
Outro serviço frequentemente associado ao Windows Update é:
BITS
Podemos consultar:
sc query bits
BITS significa:
Background Intelligent Transfer Service.
Ele participa de transferências em segundo plano utilizadas por diferentes recursos do Windows.
Se o problema acontece na fase de download, BITS ganha relevância.
Se o pacote já foi baixado e a falha ocorre durante servicing, talvez precisemos olhar para outra camada.
Não reinicie todos os serviços como primeira solução
Existe uma tendência em tutoriais de apresentar dezenas de comandos:
net stop...
net start...
regsvr32...
ren...
del...
O usuário copia tudo, executa e reinicia.
Às vezes funciona.
Mas perdemos a informação mais importante:
qual ação resolveu?
Em diagnóstico técnico, essa informação importa.
Se não sabemos qual camada estava defeituosa, teremos dificuldade para agir caso o problema retorne.
Operações pendentes podem interferir
O Windows pode ter alterações aguardando reinicialização.
Isso acontece porque determinados arquivos e componentes não podem ser modificados enquanto estão em uso.
Se existem operações pendentes, tentar iniciar novas reparações ou atualizações pode gerar comportamentos confusos.
Por isso, antes de executar uma longa sequência de manutenção, verifique se o Windows está solicitando reinicialização.
Uma reinicialização simples pode permitir que operações já preparadas sejam concluídas.
Reiniciar não é uma solução “boba”
Em sistemas modernos, reiniciar possui função técnica importante.
O Windows pode concluir:
- substituição de arquivos;
- instalação de componentes;
- atualização de drivers;
- processamento de operações pendentes;
- finalização de pacotes.
Portanto, quando existe uma reinicialização pendente, fazê-la antes de iniciar novos procedimentos pode evitar diagnósticos falsos.
Mas reiniciar vinte vezes também não resolve corrupção
Existe o outro extremo.
Se a atualização falha repetidamente com o mesmo código depois de cada reinicialização, precisamos investigar.
Reiniciar novamente sem alterar nenhuma condição provavelmente não fornecerá novas informações.
Nesse momento:
- anote o horário;
- reproduza o erro;
- leia os logs.
Como saber se a atualização foi revertida?
Depois de uma falha durante reinicialização, o Windows pode tentar desfazer alterações para voltar a um estado inicializável.
Consulte:
Configurações → Windows Update → Histórico de atualizações
Depois compare com:
DISM /Online /Get-Packages
e com os registros do CBS.
O objetivo é descobrir em qual estado o pacote terminou.
Ele pode estar:
- instalado;
- ausente;
- pendente;
- substituído;
- com falha.
Estados de pacote ajudam no diagnóstico
Quando utilizamos:
DISM /Online /Get-Packages
o Windows mostra informações sobre os pacotes registrados.
Essa lista pode ser extensa.
Podemos procurar termos relacionados à atualização ou ao pacote que estamos investigando.
Isso ajuda a descobrir se uma atualização deixou algum estado intermediário.
Mas não remova pacotes manualmente apenas porque encontrou algo que parece estranho.
Primeiro identifique exatamente o que ele representa.
Um pacote “superseded” não significa necessariamente problema
O Windows trabalha com atualizações cumulativas e substituição de pacotes.
Determinados componentes antigos podem permanecer registrados em estados que fazem parte do funcionamento normal do servicing.
Por isso, palavras como:
Superseded
não significam automaticamente corrupção.
O contexto é fundamental.
Limpar Component Store resolve 0x80073712?
Existe um comando conhecido:
DISM /Online /Cleanup-Image /StartComponentCleanup
Ele executa manutenção do armazenamento de componentes.
Mas isso não é equivalente a:
RestoreHealth
StartComponentCleanup tem objetivo de manutenção e limpeza de componentes substituídos.
RestoreHealth tem objetivo relacionado à reparação da imagem.
Portanto, não devemos tratar:
StartComponentCleanup
como comando genérico para corrigir corrupção.
São operações diferentes.
Cuidado com /ResetBase
Alguns tutoriais recomendam opções mais agressivas de manutenção do Component Store sem explicar as consequências.
O parâmetro /ResetBase, usado em determinados contextos de limpeza, pode alterar a possibilidade de desinstalar atualizações substituídas.
Isso não é algo que deve entrar automaticamente em uma sequência de reparação do 0x80073712.
Quanto mais agressivo o comando, maior deve ser a justificativa técnica para utilizá-lo.
Primeiro repare, depois pense em limpeza
Se existe suspeita de corrupção, nossa prioridade não é economizar alguns gigabytes.
É recuperar a integridade do sistema.
Portanto:
diagnóstico → reparação → validação → manutenção.
Não:
limpeza agressiva → torcer para funcionar.
Como validar depois do RestoreHealth?
Se:
DISM /Online /Cleanup-Image /RestoreHealth
terminou corretamente, execute:
DISM /Online /Cleanup-Image /ScanHealth
Depois:
sfc /scannow
Agora reinicie quando apropriado.
Depois tente novamente a atualização que originalmente apresentava:
0x80073712
Essa última etapa é indispensável.
O erro desapareceu? Ainda precisamos confirmar a KB
Abra:
Configurações → Windows Update → Histórico de atualizações
Procure a KB.
Também podemos consultar pacotes pelo DISM quando necessário.
O objetivo é confirmar que a atualização foi realmente integrada ao sistema.
Uma simples ausência da mensagem de erro não basta.
E se o 0x80073712 continuar?
Agora temos um cenário mais interessante.
Já verificamos:
- Component Store;
- DISM;
- SFC;
- logs;
- Windows Update;
- atualização específica;
- cache;
- serviços.
Se o erro continua, a próxima pergunta será:
o Windows ainda possui uma fonte íntegra capaz de reconstruir os componentes danificados?
Essa pergunta nos leva à próxima etapa do artigo.
Erro 0x80073712 continua: como reparar o Windows 11 quando o DISM não consegue resolver
Até aqui seguimos uma sequência lógica.
Identificamos a atualização problemática.
Verificamos o estado do Component Store.
Executamos DISM.
Analisamos CBS.log e DISM.log.
Verificamos arquivos protegidos com SFC.
Investigamos WindowsUpdate.log e separamos possíveis problemas do cache de atualização daqueles relacionados ao armazenamento de componentes.
Mas existe um cenário mais complicado:
DISM /Online /Cleanup-Image /RestoreHealth
também falha.
Se o próprio mecanismo utilizado para reparar a imagem não consegue completar a operação, precisamos descobrir de onde o Windows está tentando obter os componentes íntegros necessários ao reparo.
É aqui que uma mídia de instalação do Windows 11 pode se tornar importante.
Por que o DISM precisa de uma fonte?
Reparar um componente danificado exige uma referência válida.
Imagine que determinado componente esteja inconsistente.
O Windows identifica o problema.
Agora precisa substituir ou reconstruir aquilo que está incorreto.
Para isso, necessita de conteúdo íntegro.
Dependendo da situação e da configuração do computador, o mecanismo de reparação pode utilizar conteúdo disponível no próprio sistema ou recorrer a uma fonte de reparação apropriada.
Quando essa fonte não está disponível ou não contém o conteúdo necessário, o RestoreHealth pode falhar.
Portanto, antes de concluir que o DISM “não funciona”, precisamos perguntar:
ele possui uma fonte adequada para realizar o reparo?
A ISO do Windows 11 pode servir como fonte
Uma mídia de instalação compatível pode fornecer arquivos utilizados pelo DISM em determinados cenários.
Mas existe uma regra fundamental:
não use qualquer ISO simplesmente porque ela também é do Windows 11.
Precisamos observar:
- arquitetura;
- edição;
- idioma;
- versão;
- compatibilidade da imagem com o sistema instalado.
Quanto mais próximo o estado da mídia estiver do sistema que estamos reparando, menor a chance de encontrar incompatibilidades durante o procedimento.
Primeiro identifique novamente o Windows instalado
Execute:
winver
Anote a versão e a compilação.
Depois:
DISM /Online /Get-CurrentEdition
Isso identifica a edição atual.
Também podemos utilizar:
systeminfo
para consultar informações adicionais.
Não pule essa etapa.
Escolher a fonte antes de conhecer o sistema é trabalhar ao contrário.
Obtenha a mídia de uma fonte confiável
Para reparações do Windows, utilize mídia oficial e compatível.
Evite imagens modificadas encontradas em sites desconhecidos.
Uma ISO alterada pode:
- remover componentes;
- modificar serviços;
- integrar programas;
- alterar políticas;
- desabilitar recursos;
- possuir conteúdo diferente do Windows original.
Isso torna a imagem uma fonte ruim para diagnóstico.
Se estamos tentando reparar o Component Store, precisamos reduzir variáveis, não adicionar novas.
Monte a ISO no Windows 11
Depois de obter a imagem apropriada, podemos montá-la pelo próprio Explorador de Arquivos.
O Windows criará uma unidade virtual.
Imagine que a unidade seja:
D:
Abra:
D:\sources
Procure:
install.wim
ou:
install.esd
O arquivo existente determinará como construiremos o parâmetro /Source.
O que é install.wim?
WIM significa:
Windows Imaging Format.
O arquivo pode conter uma ou várias imagens do Windows.
Por exemplo, uma mesma mídia pode incluir diferentes edições.
Cada imagem possui um índice.
É por isso que não basta escrever:
D:\sources\install.wim
e presumir que o Windows escolherá exatamente o conteúdo que queremos utilizar.
Precisamos conhecer a imagem correta.
Como descobrir os índices do install.wim?
Execute:
DISM /Get-WimInfo /WimFile:D:\sources\install.wim
Substitua D: pela letra correspondente à mídia montada.
O resultado poderá apresentar várias entradas.
Exemplo conceitual:
Index : 1
Name : Windows 11 Home
Index : 6
Name : Windows 11 Pro
Os números são apenas exemplos.
Não copie esses índices para seu computador sem verificar a mídia.
Como consultar um índice específico?
Depois de identificar o índice desejado:
DISM /Get-WimInfo /WimFile:D:\sources\install.wim /index:6
Novamente, 6 é apenas um exemplo.
Essa consulta fornece informações adicionais sobre a imagem selecionada.
E se existir install.esd?
Se a mídia possuir:
D:\sources\install.esd
podemos consultar:
DISM /Get-WimInfo /WimFile:D:\sources\install.esd
Localize a edição correspondente ao Windows instalado.
O princípio permanece o mesmo.
Precisamos saber exatamente qual imagem será utilizada como fonte.
Como utilizar WIM como fonte de reparação?
Depois de confirmar o índice correto, a estrutura pode ser:
DISM /Online /Cleanup-Image /RestoreHealth /Source:wim:D:\sources\install.wim:ÍNDICE
Substitua:
D:
pela letra correta da mídia.
E:
ÍNDICE
pelo número encontrado na sua própria imagem.
Não copie automaticamente um índice encontrado em outro tutorial.
Como utilizar ESD?
Para uma mídia contendo install.esd, a estrutura pode ser:
DISM /Online /Cleanup-Image /RestoreHealth /Source:esd:D:\sources\install.esd:ÍNDICE
Novamente, confirme:
- unidade;
- arquivo;
- edição;
- índice.
Um pequeno erro nessa etapa pode fazer parecer que o DISM está quebrado quando, na verdade, a fonte foi especificada incorretamente.
O que /Source realmente faz?
O parâmetro:
/Source
informa uma origem que poderá fornecer conteúdo necessário para a operação de reparação.
Isso é diferente de simplesmente dizer ao DISM:
“procure nesta pasta porque acho que vai funcionar”.
A origem precisa possuir conteúdo adequado ao componente que o sistema precisa restaurar.
Por isso, a escolha da imagem importa.
E o /LimitAccess?
Podemos encontrar comandos como:
DISM /Online /Cleanup-Image /RestoreHealth /Source:wim:D:\sources\install.wim:ÍNDICE /LimitAccess
O parâmetro:
/LimitAccess
impede que o DISM utilize o Windows Update como fonte durante aquela operação.
Isso pode ser útil quando queremos limitar a reparação à origem especificada.
Mas existe uma consequência importante.
Se a fonte fornecida não contém o que o DISM precisa, ele não poderá tentar obter conteúdo pelo Windows Update durante aquela operação.
Portanto:
/LimitAccess não torna o reparo mais forte.
Ele simplesmente limita as fontes disponíveis.
Por que uma ISO pode não funcionar?
Você pode montar uma ISO perfeitamente válida, escolher a edição correta e ainda receber erro.
Isso pode acontecer porque a palavra:
compatível
envolve mais do que “Windows 11 Pro”.
Considere:
- arquitetura;
- idioma;
- versão;
- nível de atualização;
- componentes presentes;
- edição.
O sistema instalado pode estar significativamente mais atualizado do que a imagem utilizada.
Dependendo do componente necessário, a mídia pode não oferecer uma correspondência apropriada.
Uma ISO antiga demais merece atenção
Imagine um computador que recebeu meses de atualizações cumulativas.
Agora tentamos reparar determinados componentes usando uma mídia muito anterior.
Embora ambos sejam Windows 11, os componentes podem estar em estados diferentes.
Isso não significa que uma mídia mais antiga nunca possa ajudar.
Significa que devemos considerar a diferença entre a fonte e o sistema quando o reparo falha.
O idioma pode interferir?
Em determinados cenários, diferenças de idioma podem importar porque existem componentes específicos de idioma.
Por isso, quando possível, utilize uma mídia correspondente à instalação.
Novamente:
quanto menos diferenças introduzirmos, melhor será o diagnóstico.
O DISM com Source também falhou. E agora?
Não repita o mesmo comando indefinidamente.
Volte aos logs.
Abra:
C:\Windows\Logs\DISM\dism.log
e:
C:\Windows\Logs\CBS\CBS.log
Observe a tentativa mais recente.
Pergunte:
o código continua sendo exatamente o mesmo?
Essa pergunta é essencial.
A primeira falha pode ter sido 0x80073712.
Depois de alterar a fonte, o processo pode avançar e encontrar outro problema.
Se o código mudou, o diagnóstico também mudou.
Um erro diferente pode representar progresso
Isso parece estranho, mas é possível.
Suponha que inicialmente o Windows não consiga nem processar determinado estado do Component Store.
Depois de uma intervenção, ele ultrapassa essa etapa e encontra outra inconsistência.
O novo erro não significa necessariamente que pioramos o computador.
Pode significar que o processo avançou.
Por isso, registre cada tentativa.
Faça um pequeno diário do diagnóstico
Para problemas persistentes, anote:
Tentativa 1
Comando:
DISM /Online /Cleanup-Image /RestoreHealth
Resultado:
código X.
Tentativa 2
Comando com /Source.
Resultado:
código Y.
Tentativa 3
Depois de determinada correção.
Resultado:
concluído ou código Z.
Essa metodologia evita repetir procedimentos e ajuda a compreender a evolução do problema.
Não copie arquivos manualmente para WinSxS
Mesmo quando o log identifica um componente específico, não tente simplesmente copiar arquivos para:
C:\Windows\WinSxS
O Component Store não funciona como uma pasta comum de backup.
Existem:
- permissões;
- versões;
- manifestos;
- catálogos;
- dependências;
- registros internos.
Uma substituição manual pode criar inconsistências ainda mais difíceis de reparar.
Também não assuma propriedade de WinSxS para apagar arquivos
Alguns tutoriais sugerem alterar propriedade e permissões de diretórios protegidos para permitir exclusão manual.
Isso pode quebrar o modelo de servicing.
Se o Windows protege determinado componente, contornar essa proteção não significa que a alteração seja segura.
No contexto de 0x80073712:
evite reparações manuais destrutivas dentro do Component Store.
E se DISM e SFC não conseguirem recuperar o sistema?
Nesse ponto, precisamos considerar uma reparação mais profunda.
Existe uma opção intermediária entre:
executar DISM
e:
formatar completamente o computador.
Ela é conhecida como:
reinstalação de reparo
ou, dependendo do contexto:
in-place repair / in-place upgrade repair.
O que é uma reinstalação de reparo?
A ideia consiste em executar o instalador do Windows sobre a instalação existente, permitindo que o Setup reconstrua componentes do sistema.
Quando as condições são compatíveis, podemos preservar:
- arquivos pessoais;
- aplicativos instalados;
- configurações.
Isso torna a técnica particularmente interessante quando o Windows ainda inicializa normalmente, mas sua infraestrutura interna apresenta problemas que DISM e SFC não conseguem corrigir.
Reinstalação de reparo não é a mesma coisa que “Restaurar este PC”
São mecanismos diferentes.
A reinstalação executada através de uma mídia compatível pode permitir uma atualização/reinstalação sobre o Windows existente.
Já as opções de recuperação do Windows possuem fluxos próprios.
Não devemos tratar todas como se fossem o mesmo procedimento.
Antes de executar qualquer uma delas, entenda:
- o que será mantido;
- o que será removido;
- qual mídia será utilizada;
- qual resultado esperamos.
Como iniciar uma reinstalação de reparo?
Com o Windows funcionando normalmente, monte uma mídia compatível.
Dentro da unidade montada, execute:
setup.exe
O instalador analisará o sistema.
Em determinado momento, deverá apresentar as opções disponíveis para preservação.
Quando o objetivo é uma reparação mantendo o ambiente existente, precisamos verificar cuidadosamente se existe a opção equivalente a manter:
arquivos pessoais e aplicativos.
Se essa opção não estiver disponível, não continue automaticamente.
Descubra por quê.
Por que a opção de manter aplicativos pode não aparecer?
Existem várias possibilidades, incluindo incompatibilidades entre a mídia e o sistema instalado.
Podem existir diferenças relacionadas a:
- edição;
- arquitetura;
- idioma;
- versão;
- caminho de atualização suportado.
Isso reforça a importância de escolher corretamente a mídia.
Faça backup mesmo quando a opção promete preservar arquivos
Esse ponto é obrigatório em qualquer manutenção séria.
Antes de uma reparação profunda, copie os dados importantes.
Inclua:
- documentos;
- fotos;
- vídeos;
- arquivos profissionais;
- bancos de dados;
- certificados;
- configurações críticas;
- arquivos que não podem ser recriados;
- chaves de recuperação importantes quando aplicável.
Uma opção chamada “manter arquivos” não substitui backup.
Por que a reinstalação de reparo pode corrigir problemas que DISM não resolve?
DISM trabalha dentro da infraestrutura de servicing existente.
Quando essa infraestrutura apresenta inconsistências profundas, sua capacidade de reparação pode ficar limitada.
Uma reinstalação de reparo reconstrói uma parcela muito maior do Windows.
Isso pode restaurar:
- componentes;
- arquivos do sistema;
- estruturas de servicing;
- recursos internos;
sem exigir necessariamente uma instalação limpa.
É uma ferramenta importante antes da formatação.
Depois da reinstalação, teste novamente o Windows Update
Não considere o trabalho terminado porque o Windows iniciou.
O problema original era:
0x80073712
Portanto, precisamos voltar ao cenário inicial.
Abra:
Configurações → Windows Update
Procure atualizações.
Verifique se a KB que falhava consegue instalar.
Depois consulte:
Histórico de atualizações.
Também podemos executar:
DISM /Online /Cleanup-Image /ScanHealth
e:
sfc /scannow
para verificar o estado do sistema depois da reparação.
E se a corrupção voltar?
Esse é um cenário muito importante.
Imagine:
DISM repara.
SFC fica limpo.
Windows Update volta a funcionar.
Alguns dias depois:
corrupção novamente.
Agora temos uma nova pergunta:
o que está causando a corrupção recorrente?
Nesse ponto, simplesmente executar DISM repetidamente pode mascarar a causa.
Precisamos ampliar o diagnóstico.
Investigue o sistema de arquivos
Problemas no sistema de arquivos podem contribuir para inconsistências.
Uma ferramenta conhecida é:
chkdsk
Mas existem diferentes parâmetros e impactos.
Não execute opções agressivas automaticamente.
Podemos começar verificando o estado e os eventos relacionados ao armazenamento antes de decidir se uma verificação mais profunda é necessária.
O objetivo continua sendo diagnóstico.
Verifique o Visualizador de Eventos
Abra:
Visualizador de Eventos
e examine principalmente eventos próximos aos horários em que:
- ocorreram travamentos;
- atualizações falharam;
- arquivos ficaram corrompidos;
- o computador reiniciou inesperadamente.
Eventos relacionados a armazenamento, sistema de arquivos ou hardware podem fornecer pistas.
Uma ocorrência isolada não prova defeito físico.
Procure padrões.
Verifique a saúde do SSD
Se existem sinais adicionais de problemas de armazenamento, vale verificar informações SMART do SSD.
Ferramentas apropriadas podem mostrar indicadores relacionados à saúde e funcionamento da unidade.
Mas atenção:
SMART saudável não é garantia absoluta de que um SSD nunca apresentará problema.
Da mesma forma:
0x80073712 não significa SSD defeituoso.
Precisamos correlacionar evidências.
E a RAM?
Se a corrupção aparece repetidamente junto com:
- telas azuis;
- programas fechando;
- arquivos corrompidos;
- erros aleatórios;
- instalações falhando de maneiras diferentes;
uma verificação da memória pode ser apropriada.
Novamente, o erro do Windows Update sozinho não justifica trocar memória.
Hardware entra na investigação quando o conjunto de sintomas aponta nessa direção.
Desligamentos inesperados também importam
Atualizações do Windows podem realizar operações críticas durante reinicializações.
Interromper o computador durante essas etapas pode contribuir para estados inconsistentes.
Por isso, evite desligar à força o computador durante uma atualização simplesmente porque a porcentagem parece parada.
Algumas etapas podem demorar.
Isso é particularmente importante em computadores mais lentos ou com grande quantidade de componentes para processar.
Antivírus pode causar 0x80073712?
Não devemos culpar automaticamente o antivírus.
Softwares de segurança podem interferir em determinados processos dependendo de sua implementação e configuração, mas o código isolado não demonstra essa relação.
Se houver suspeita, procure:
- eventos;
- registros do produto;
- bloqueios;
- correlação temporal.
Evite desabilitar proteção indiscriminadamente sem evidência de que ela participa do problema.
Programas de “otimização” merecem atenção
Ferramentas que prometem:
- limpar profundamente o Windows;
- apagar componentes antigos;
- remover arquivos “desnecessários”;
- modificar serviços;
- desativar recursos;
- limpar Registro;
podem alterar áreas importantes do sistema.
Se o problema começou depois do uso de uma ferramenta desse tipo, essa informação deve entrar no diagnóstico.
Isso não significa que todo otimizador cause corrupção.
Significa que qualquer programa que modifica profundamente o Windows aumenta o número de variáveis que precisamos considerar.
Scripts de debloat também podem complicar o diagnóstico
Scripts que removem aplicativos, componentes, tarefas, serviços ou recursos do Windows variam muito em qualidade.
Alguns fazem alterações relativamente simples.
Outros modificam profundamente a instalação.
Quando encontramos um Windows altamente modificado apresentando problemas de servicing, precisamos considerar essas alterações.
Uma atualização futura pode depender de algo que foi removido ou modificado.
Quando uma instalação limpa passa a ser considerada?
Uma instalação limpa pode fazer sentido quando:
- a corrupção é extensa;
- reparações convencionais falham;
- reinstalação de reparo não é possível ou não resolve;
- existem múltiplos problemas estruturais;
- o sistema foi profundamente modificado;
- o tempo necessário para reconstruir manualmente a instalação supera o custo de reinstalá-la corretamente.
Mas isso deve ser uma decisão técnica.
Não uma reação automática ao primeiro:
0x80073712
que aparece.
Formatar não resolve defeito de hardware
Esse ponto é importante.
Se corrupção recorrente é causada por:
- armazenamento defeituoso;
- memória instável;
- outro problema físico;
uma instalação limpa pode funcionar inicialmente e apresentar problemas novamente.
Por isso, quando existe corrupção repetitiva, avalie hardware antes de concluir que uma nova instalação será a solução definitiva.
Uma árvore prática de decisão
Podemos resumir o raciocínio:
0x80073712 apareceu
↓
Identifique a KB e o horário.
↓
Execute ScanHealth.
↓
Component Store saudável?
Se sim:
investigue a atualização específica, Windows Update e logs.
Se não:
tente RestoreHealth.
↓
RestoreHealth funcionou?
Se sim:
execute SFC e teste novamente a atualização.
Se não:
analise DISM.log e CBS.log.
↓
Existe necessidade de fonte alternativa?
Se sim:
utilize mídia compatível e /Source.
↓
Reparo com fonte funcionou?
Se sim:
valide DISM, SFC e Windows Update.
Se não:
avalie reinstalação de reparo.
↓
Problema retorna depois da reparação?
Investigue:
- armazenamento;
- memória;
- sistema de arquivos;
- desligamentos;
- modificações de terceiros;
- estabilidade geral.
Essa árvore evita saltar diretamente do código de erro para a formatação.
O verdadeiro objetivo não é fazer o código desaparecer
O objetivo é conseguir responder três perguntas:
1. O que estava falhando?
2. O que corrigimos?
3. O problema original deixou de acontecer?
Se não conseguimos responder nenhuma delas, talvez tenhamos apenas executado comandos até o erro desaparecer temporariamente.
Isso não é o mesmo que diagnóstico.
Depois de analisar o 0x80073712, podemos perceber por que simplesmente redefinir o Windows Update nem sempre resolve esse problema.
O Windows Update é apenas uma parte de uma infraestrutura muito maior.
Uma atualização precisa ser encontrada, baixada, validada, preparada e integrada aos componentes existentes no sistema. Quando arquivos ou informações necessários ao processo de servicing estão ausentes ou danificados, o Windows pode receber perfeitamente o pacote e ainda assim não conseguir concluir sua instalação.
É justamente por isso que um computador pode:
- navegar normalmente;
- baixar a atualização;
- chegar a 100%;
- reiniciar;
- tentar aplicar alterações;
- falhar;
- desfazer as alterações;
- iniciar novamente apresentando o código 0x80073712.
Nesse cenário, continuar procurando exclusivamente um problema de Internet pode desviar completamente o diagnóstico.
0x80073712 e 0x800f081f: qual é a diferença?
Como acabamos de publicar também um guia sobre 0x800f081f, vale separar claramente os dois códigos.
Eles podem aparecer em contextos relacionados ao Windows Update, DISM e servicing, mas não significam exatamente a mesma coisa.
Erro 0x80073712
Devemos investigar especialmente problemas envolvendo arquivos ou componentes necessários ao processo de atualização e a integridade do armazenamento de componentes.
O Component Store, CBS.log e DISM ganham grande importância nesse diagnóstico.
Erro 0x800f081f
Nesse erro, uma questão importante é a incapacidade de localizar os arquivos de origem necessários para determinada operação de reparação ou servicing.
Isso torna a investigação da fonte de reparação particularmente importante.
Em determinadas situações, uma mídia compatível pode ser necessária.
Os dois erros podem aparecer no mesmo computador?
Sim.
Um computador pode inicialmente apresentar um problema de integridade.
Durante uma tentativa de reparação, o DISM pode precisar de conteúdo adicional.
Se não conseguir obter uma fonte adequada, outro código pode aparecer.
Por isso, registre o resultado de cada tentativa.
Não continue tratando o computador pelo primeiro código se o erro posteriormente mudou.
Uma forma simples de separar os dois
Podemos pensar assim:
0x80073712:
“Existe um problema com arquivos ou componentes necessários à operação.”
0x800f081f:
“Não consegui encontrar uma fonte adequada contendo o conteúdo necessário para a reparação.”
Essa é uma simplificação didática.
O diagnóstico definitivo deve considerar a operação executada, os logs e o estado real daquele Windows.
Tabela rápida de diagnóstico do erro 0x80073712
| Situação | O que investigar |
|---|---|
| Atualização nem baixa | Windows Update, rede e transferência |
| Download chega a 100%, mas instalação falha | Servicing, KB e Component Store |
| ScanHealth detecta corrupção | RestoreHealth |
| RestoreHealth conclui | Executar SFC e testar novamente |
| RestoreHealth falha | DISM.log e CBS.log |
| DISM precisa de fonte alternativa | ISO compatível e /Source |
| Somente uma KB falha | Investigar especificamente essa atualização |
| Todas as atualizações falham | Investigar Windows Update e servicing de forma ampla |
| Cache parece inconsistente | Avaliar SoftwareDistribution |
| Problemas de validação aparecem nos registros | Investigar componentes relacionados e logs |
| Corrupção retorna | Investigar estabilidade, armazenamento e RAM |
| DISM e SFC não resolvem | Considerar reinstalação de reparo |
| Reinstalação de reparo falha | Ampliar diagnóstico antes da instalação limpa |
A tabela serve como orientação.
Ela não transforma cada linha em uma regra automática.
Sequência recomendada de diagnóstico
Uma sequência organizada pode economizar muito tempo.
Etapa 1 — Identifique o sistema
Execute:
winver
Depois:
DISM /Online /Get-CurrentEdition
Anote:
- versão;
- build;
- edição.
Etapa 2 — Identifique a atualização
Abra:
Configurações → Windows Update → Histórico de atualizações
Anote:
KBxxxxxxx
e o código:
0x80073712
Se possível, anote também o horário da tentativa.
Etapa 3 — Verifique rapidamente a imagem
Execute como administrador:
DISM /Online /Cleanup-Image /CheckHealth
Leia a mensagem apresentada.
Etapa 4 — Faça uma análise mais profunda
Execute:
DISM /Online /Cleanup-Image /ScanHealth
Aguarde a conclusão.
Não interrompa apenas porque a porcentagem demora para avançar.
Etapa 5 — Repare quando apropriado
Execute:
DISM /Online /Cleanup-Image /RestoreHealth
Se funcionar, prossiga para a validação.
Se falhar, anote exatamente o código.
Etapa 6 — Consulte os logs
DISM:
C:\Windows\Logs\DISM\dism.log
CBS:
C:\Windows\Logs\CBS\CBS.log
Procure eventos correspondentes ao horário da tentativa.
Etapa 7 — Verifique arquivos protegidos
Execute:
sfc /scannow
Leia o resultado.
Se o SFC encontrar problemas que não consegue reparar, analise as entradas correspondentes no CBS.log.
Etapa 8 — Teste novamente o problema original
Volte ao Windows Update.
Tente instalar a KB que apresentava erro.
Essa etapa é essencial.
O objetivo não é fazer DISM e SFC chegarem a 100%.
O objetivo é resolver o problema que iniciou a investigação.
Quando investigar SoftwareDistribution?
Considere essa camada quando existirem indícios de:
- downloads inconsistentes;
- atualização presa;
- cache problemático;
- conteúdo baixado que parece não ser reutilizado corretamente;
- comportamento anormal do cliente Windows Update.
A pasta normalmente fica em:
C:\Windows\SoftwareDistribution
Redefinir essa estrutura pode ajudar em alguns problemas do Windows Update.
Mas ela não substitui o reparo do Component Store.
Se o problema está dentro da infraestrutura de servicing, baixar novamente o mesmo pacote pode produzir exatamente o mesmo erro.
Quando investigar Catroot2?
A pasta:
C:\Windows\System32\catroot2
participa de processos importantes utilizados durante operações de atualização.
Existem situações em que sua redefinição pode entrar no diagnóstico.
Mas não utilize:
“apagar SoftwareDistribution + apagar Catroot2”
como receita automática para todo código de Windows Update.
Cada intervenção deve responder a uma hipótese.
Quando usar uma ISO?
Uma mídia compatível pode ser considerada quando o mecanismo de reparação precisa de uma fonte que não está conseguindo obter normalmente.
Antes disso, confirme:
- versão;
- arquitetura;
- edição;
- idioma;
- conteúdo da mídia;
- WIM ou ESD;
- índice correto.
Depois utilize /Source de maneira controlada.
Comandos principais utilizados neste guia
Verificação rápida
DISM /Online /Cleanup-Image /CheckHealth
Análise do Component Store
DISM /Online /Cleanup-Image /ScanHealth
Reparação
DISM /Online /Cleanup-Image /RestoreHealth
Verificação dos arquivos protegidos
sfc /scannow
Consultar edição
DISM /Online /Get-CurrentEdition
Consultar imagens WIM
DISM /Get-WimInfo /WimFile:D:\sources\install.wim
Consultar ESD
DISM /Get-WimInfo /WimFile:D:\sources\install.esd
Gerar WindowsUpdate.log
Get-WindowsUpdateLog
Consultar pacotes
DISM /Online /Get-Packages
Consultar Windows Update Service
sc query wuauserv
Consultar BITS
sc query bits
Consultar Cryptographic Services
sc query cryptsvc
Execute apenas aquilo que corresponde à investigação em andamento.
Erros comuns ao tentar corrigir 0x80073712
Executar vinte comandos de uma vez
Essa abordagem elimina nossa capacidade de saber qual intervenção produziu resultado.
Prefira:
comando → resultado → interpretação → próxima ação.
Apagar WinSxS
Não faça isso.
WinSxS participa diretamente do Component Store.
Apagar conteúdo manualmente pode comprometer ainda mais a capacidade de atualização e reparação do Windows.
Baixar DLL de sites desconhecidos
Um nome de DLL encontrado no CBS.log não significa que devemos procurar uma cópia na Internet.
A versão pode ser incompatível ou o arquivo pode não ser confiável.
Use os mecanismos oficiais de servicing e fontes adequadas.
Usar qualquer ISO
“Windows 11” não é informação suficiente.
Confirme a compatibilidade da mídia antes de utilizá-la como fonte.
Copiar o índice WIM de outro tutorial
Execute:
DISM /Get-WimInfo
na sua própria mídia.
Os índices não devem ser presumidos.
Usar /LimitAccess sem saber o que ele faz
/LimitAccess restringe o acesso do DISM ao Windows Update como fonte durante aquela operação.
Ele não torna o comando “mais potente”.
Formatar imediatamente
O código 0x80073712 sozinho não significa que o Windows precise de instalação limpa.
Ainda existem:
- DISM;
- SFC;
- análise de logs;
- fonte alternativa;
- reinstalação de reparo.
A formatação é uma possibilidade posterior, não a primeira resposta.
Perguntas frequentes sobre o erro 0x80073712
O que significa erro 0x80073712 no Windows 11?
O erro pode aparecer quando arquivos ou componentes necessários ao Windows Update ou ao processo de servicing estão ausentes, corrompidos ou inconsistentes.
Por isso, a investigação costuma envolver Component Store, DISM, SFC e CBS.log.
0x80073712 significa que meu Windows está corrompido?
Pode existir corrupção relacionada aos componentes necessários à operação, mas não conclua que todo o Windows está comprometido apenas pelo código.
Execute:
DISM /Online /Cleanup-Image /ScanHealth
e analise os logs.
O diagnóstico precisa mostrar o estado real do sistema.
Posso continuar usando o computador?
Muitas vezes o Windows continua funcionando normalmente.
O problema pode aparecer apenas quando uma atualização tenta modificar determinados componentes.
Entretanto, não é recomendável ignorar indefinidamente uma falha que esteja impedindo atualizações, principalmente atualizações de segurança.
Investigue a causa.
Por que o Windows Update chega a 100% e depois dá erro?
Porque 100% pode representar a conclusão de uma etapa, como o download.
O Windows ainda precisa preparar e aplicar o pacote.
Se o mecanismo de servicing encontrar inconsistências, a instalação pode falhar mesmo com o pacote completamente baixado.
Reiniciar resolve 0x80073712?
Uma reinicialização pode concluir operações pendentes e, por isso, deve ser considerada quando o Windows está solicitando reinicialização.
Mas se o mesmo erro reaparece repetidamente, continuar reiniciando sem investigar provavelmente não resolverá a causa.
DISM corrige 0x80073712?
Pode corrigir problemas do Component Store relacionados ao erro, dependendo da causa.
Comece verificando:
DISM /Online /Cleanup-Image /ScanHealth
Quando apropriado:
DISM /Online /Cleanup-Image /RestoreHealth
Depois valide novamente.
O que fazer se RestoreHealth falhar?
Anote o código apresentado.
Depois analise:
C:\Windows\Logs\DISM\dism.log
e:
C:\Windows\Logs\CBS\CBS.log
Dependendo do problema, uma fonte de reparação compatível pode ser necessária.
O que é CBS.log?
CBS significa:
Component-Based Servicing.
O arquivo registra informações relacionadas ao mecanismo de servicing baseado em componentes do Windows.
Normalmente fica em:
C:\Windows\Logs\CBS\CBS.log
Ele pode ser extremamente útil quando atualizações, DISM ou SFC apresentam problemas.
O que é DISM.log?
É o registro das operações realizadas pelo DISM.
Normalmente fica em:
C:\Windows\Logs\DISM\dism.log
O arquivo ajuda a investigar por que uma operação DISM falhou.
O que é Component Store?
É a infraestrutura de armazenamento e gerenciamento de componentes utilizada pelo Windows para servicing, recursos, reparações e atualizações.
Ela está fortemente associada ao diretório:
C:\Windows\WinSxS
Não deve ser tratada como uma pasta comum de arquivos temporários.
Posso apagar WinSxS para recriá-la?
Não.
Não existe uma estratégia segura de simplesmente apagar WinSxS e esperar que o Windows a recrie como se fosse um cache de navegador.
Isso pode danificar seriamente o sistema.
Devo limpar SoftwareDistribution?
Somente quando o diagnóstico justificar uma redefinição do cache e dos componentes do Windows Update.
Não presuma que SoftwareDistribution seja a causa do 0x80073712.
Posso apagar Catroot2?
Existem procedimentos de redefinição que envolvem a estrutura catroot2, mas isso deve ser feito de maneira controlada e somente quando fizer sentido para o problema investigado.
Não confunda catroot2 com catroot.
SFC e DISM fazem a mesma coisa?
Não.
De maneira simplificada:
DISM trabalha com a imagem e o armazenamento de componentes.
SFC verifica arquivos protegidos do sistema.
Eles podem complementar um ao outro.
Devo executar DISM ou SFC primeiro?
Não transforme a sequência em uma regra universal.
Quando existe suspeita de problemas no Component Store, verificar e reparar a imagem antes de uma nova execução do SFC pode fazer sentido.
O resultado de cada ferramenta deve determinar a próxima etapa.
O erro pode ser causado pelo SSD?
0x80073712 sozinho não comprova defeito no SSD.
Entretanto, se corrupção reaparece depois das reparações e existem outros sintomas relacionados ao armazenamento, investigue a unidade.
Procure padrões e evidências adicionais.
RAM defeituosa pode corromper o Windows?
Instabilidade de memória pode contribuir para comportamentos anormais e corrupção, mas o 0x80073712 isoladamente não diagnostica memória defeituosa.
Investigue RAM quando existirem outros sintomas que sustentem essa hipótese.
Antivírus causa 0x80073712?
Não podemos concluir isso pelo código.
Se houver suspeita de interferência, procure registros e evidências do software de segurança.
Evite desativar proteção aleatoriamente.
Um programa de limpeza pode causar problemas no Component Store?
Ferramentas que modificam agressivamente componentes, serviços ou arquivos do Windows podem interferir no funcionamento normal do sistema.
Se o erro começou depois do uso de uma ferramenta desse tipo, inclua essa informação na investigação.
Isso não significa que qualquer programa de limpeza seja automaticamente responsável.
Scripts de debloat podem afetar o Windows Update?
Depende das alterações realizadas.
Alguns scripts removem ou modificam componentes, serviços e tarefas.
Quanto mais profunda a alteração, maior a possibilidade de interferir posteriormente em recursos que dependiam daquele estado original.
Se o Windows foi modificado, isso precisa ser considerado no diagnóstico.
Preciso baixar a atualização manualmente?
Instalar manualmente uma KB pode ser útil em alguns diagnósticos.
Porém, se o problema estiver no Component Store, utilizar outro método para entregar o mesmo pacote pode terminar na mesma falha.
A instalação manual não substitui a investigação da integridade do sistema.
Uma ISO resolve 0x80073712?
Ela pode servir como fonte de reparação em determinados cenários.
Mas precisa ser adequada ao Windows instalado.
Verifique:
- versão;
- edição;
- arquitetura;
- idioma;
- WIM/ESD;
- índice.
Não existe garantia de que simplesmente montar uma ISO resolverá qualquer ocorrência do erro.
O que é reinstalação de reparo?
É uma forma de reinstalar componentes do Windows sobre a instalação existente.
Quando as condições permitem, o procedimento pode preservar:
- arquivos pessoais;
- programas;
- configurações.
Ela representa uma alternativa importante antes de considerar uma instalação limpa.
Reinstalação de reparo apaga meus programas?
Quando o procedimento e a mídia são compatíveis e o instalador oferece a opção apropriada, é possível preservar aplicativos e arquivos.
Verifique cuidadosamente as opções mostradas pelo Setup antes de prosseguir.
E faça backup independentemente disso.
Quando devo formatar?
Uma instalação limpa pode ser considerada quando:
- a corrupção é extensa;
- reparações falham;
- reinstalação de reparo não resolve;
- o sistema apresenta várias inconsistências;
- existe uma necessidade técnica clara de reconstruir o ambiente.
Não formate apenas porque encontrou 0x80073712.
Como saber se realmente resolvemos o problema?
Essa pergunta é mais importante do que parece.
Suponha que executamos:
DISM /RestoreHealth
e recebemos uma mensagem de sucesso.
Isso é bom.
Mas o problema inicial era:
uma determinada KB não instalava.
Então precisamos instalar novamente aquela KB.
Depois:
- consulte o Histórico de Atualizações;
- confirme o estado da KB;
- execute
ScanHealth; - execute SFC quando apropriado;
- observe se o erro retorna.
Só então temos evidência de que a reparação resolveu o problema original.
Corrupção que retorna não é normal
Se você repara o Windows e a corrupção aparece novamente repetidas vezes, pare de simplesmente executar DISM.
Procure a causa.
Investigue:
- SSD;
- sistema de arquivos;
- RAM;
- desligamentos inesperados;
- software que modifica o sistema;
- estabilidade geral;
- eventos registrados pelo Windows.
Reparar continuamente sem investigar a origem pode apenas esconder um problema maior.
Conclusão: 0x80073712 exige diagnóstico, não uma receita pronta
O erro 0x80073712 no Windows 11 mostra por que o Windows Update não deve ser entendido apenas como um programa que baixa arquivos da Internet.
Existe toda uma infraestrutura trabalhando por trás da tela de Configurações.
O Windows precisa controlar pacotes, componentes, dependências, versões, arquivos protegidos e operações que podem continuar durante a reinicialização.
O Component Store ocupa uma posição central nessa arquitetura.
Quando os arquivos ou informações necessários ao servicing ficam ausentes ou inconsistentes, uma atualização pode ser baixada perfeitamente e ainda assim não conseguir ser instalada.
Por isso, o caminho correto começa identificando:
qual atualização falhou?
Depois:
em qual etapa?
Em seguida:
o Component Store está saudável?
Se existe corrupção:
o DISM consegue repará-la?
Se não consegue:
o que DISM.log e CBS.log mostram?
Se falta uma fonte:
uma mídia compatível pode fornecê-la?
E se nem isso resolver:
uma reinstalação de reparo pode reconstruir o Windows preservando o ambiente existente?
Essa sequência evita transformar manutenção em uma loteria de comandos.
O código 0x80073712 não é apenas uma mensagem de erro.
Ele é o começo da investigação.
Windows Update apresenta erro? A VMIA pode ajudar
Se o Windows 11 apresenta 0x80073712, atualizações que não instalam, erros no DISM, arquivos corrompidos ou problemas recorrentes no Windows Update, a VMIA pode realizar o diagnóstico do computador.
O atendimento pode incluir análise de:
- Windows Update;
- DISM;
- SFC;
- CBS.log;
- Component Store;
- drivers;
- integridade do Windows;
- desempenho;
- armazenamento;
- problemas relacionados a atualizações.
O atendimento pode ser realizado por acesso remoto ou por visita técnica com agendamento, dependendo do problema.
VMIA – Manutenção e Configuração
Rua Prof. Sud Menucci, 291
Vila Mariana – São Paulo – SP
CEP 04017-080
Telefone e WhatsApp: (11) 99779-7772
Site: https://vmia.site
Blog: https://vmia.com.br
Avaliações: https://avaliacao.vmia.com.br
WhatsApp: https://whats.vmia.com.br
Antes de formatar o computador por causa de um erro do Windows Update, descubra exatamente qual camada está falhando. Muitas vezes, o código apresentado pelo Windows fornece justamente a pista necessária para encontrar a verdadeira causa.
Faça um comentário