Você abre o Windows Update.
Existe uma atualização disponível:
KBxxxxxxx
O Windows baixa.
Instala.
Pede para reiniciar.
Depois da reinicialização, o Histórico de Atualizações mostra que a KB foi instalada.
Tudo parece resolvido.
Algum tempo depois, você clica novamente em:
Verificar se há atualizações
e encontra algo estranho.
A mesma:
KBxxxxxxx
aparece novamente.
O Windows baixa outra vez.
Instala outra vez.
Em alguns computadores, esse ciclo pode continuar.
A primeira reação costuma ser:
“O Windows Update está baixando exatamente a mesma atualização sem motivo.”
Pode ser.
Mas antes precisamos confirmar algo fundamental:
é realmente o mesmo pacote sendo reinstalado ou apenas parece ser a mesma atualização?
Essa diferença será o ponto central deste artigo.
A mesma KB pode aparecer mais de uma vez?
Sim, mas precisamos analisar o contexto.
Ver o mesmo número de KB em diferentes locais não prova, sozinho, que o Windows instalou exatamente o mesmo conteúdo repetidamente.
Precisamos comparar:
- KB;
- tipo de atualização;
- build antes;
- build depois;
- data;
- resultado;
- pacote;
- estado do servicing.
O Histórico de Atualizações não conta toda a história
Abra:
Configurações → Windows Update → Histórico de atualizações
Essa tela é extremamente útil.
Mas ela apresenta uma visão amigável do processo.
O servicing do Windows trabalha com estruturas mais detalhadas.
Por isso, não devemos concluir:
“está no histórico, então todo o pacote foi aplicado exatamente como esperado”.
Precisamos confirmar o estado real do sistema.
Primeiro anote a KB
Suponha que apareça:
KBxxxxxxx
Anote esse número.
Depois registre:
- data;
- horário;
- categoria;
- status.
Agora reinicie quando solicitado.
Antes de instalar, execute winver
Pressione:
Windows + R
Digite:
winver
Anote:
Versão: XXXXX
Build: XXXXX.XXXX
Depois instale a atualização.
Reinicie.
Execute novamente:
winver
Compare.
A build mudou?
Essa é uma das primeiras pistas.
Imagine:
Antes
XXXXX.1000
Depois
XXXXX.1200
A atualização alterou a compilação.
Agora, se a mesma KB reaparece, precisamos descobrir por que o mecanismo de detecção ainda considera algum conteúdo aplicável.
A build não mudou
Isso também é importante.
A interface pode ter registrado uma tentativa como concluída ou pode existir uma situação que precisa ser analisada mais profundamente.
Não conclua imediatamente que o Histórico de Atualizações está errado.
Investigue.
Diferencie instalação de detecção
O Windows Update precisa responder:
“esta atualização é aplicável a este computador?”
Depois precisa:
- obter conteúdo;
- preparar;
- aplicar;
- registrar;
- concluir.
Se o estado final não corresponde ao esperado pelo mecanismo de detecção, uma atualização pode voltar a ser oferecida.
A pergunta muda
Em vez de:
“por que o Windows baixou duas vezes?”
pergunte:
“por que o Windows ainda considera essa atualização aplicável?”
Essa pergunta nos leva muito mais perto do diagnóstico.
Pode existir instalação parcial?
Uma atualização pode envolver diferentes componentes e etapas.
Se determinada parte não termina como esperado, o sistema pode apresentar um estado que merece investigação.
Mas não devemos chamar qualquer repetição de:
“instalação parcial”.
Precisamos verificar os registros e o estado dos pacotes.
Atualizações cumulativas tornam o assunto ainda mais interessante
No Windows 11, atualizações cumulativas agregam correções.
Isso significa que não devemos imaginar cada KB como um conjunto totalmente isolado de arquivos sem relação com o estado anterior.
O servicing avalia:
- sistema atual;
- componentes;
- pacotes;
- aplicabilidade;
- conteúdo necessário.
A mesma KB apareceu duas vezes no histórico
Antes de considerar isso um erro, compare:
- datas;
- resultado;
- categoria;
- build;
- descrição.
Pode existir diferença no contexto das entradas.
Faça uma captura ou anote as duas ocorrências
Registre:
Ocorrência 1
KB: KBxxxxxxx
Data: XX/XX
Resultado: instalado
Ocorrência 2
KB: KBxxxxxxx
Data: XX/XX
Resultado: instalado/falhou
Agora temos algo concreto.
Verifique a build após cada instalação
Use:
winver
Essa informação ajuda a descobrir se o Windows realmente avançou para outra revisão.
Use Get-HotFix como informação complementar
No PowerShell, podemos consultar:
Get-HotFix
Procure a KB quando ela estiver representada nessa consulta.
Mas não dependa exclusivamente desse comando.
Nem todo estado de atualização do Windows deve ser inferido apenas por Get-HotFix.
Consulte os pacotes do servicing
Abra o Terminal como administrador.
Execute:
DISM /Online /Get-Packages
Essa lista pode ser extensa.
Procure informações relacionadas à atualização investigada.
Por que DISM /Get-Packages é importante?
Porque agora não estamos olhando apenas para a interface do Windows Update.
Estamos consultando o servicing.
Queremos descobrir:
qual é o estado do pacote?
Não remova nada
Este artigo não começa com:
DISM /Remove-Package
Nosso objetivo é entender.
Remover um pacote porque ele aparece duas vezes ou parece estranho pode criar um problema muito maior.
Pacote e KB não são exatamente a mesma visão
O usuário pensa em:
KBxxxxxxx
O servicing pode apresentar identidades de pacotes mais detalhadas.
Por isso, a relação nem sempre aparece como uma linha simples:
“KBxxxxxxx = pacote X”.
Precisamos correlacionar informações.
O Windows Update está realmente baixando tudo novamente?
Outra pergunta importante.
A interface pode mostrar atividade de download, mas isso não significa necessariamente que todos os bytes do pacote original estão sendo transferidos novamente da mesma maneira.
O mecanismo pode avaliar e obter o conteúdo necessário conforme o estado do dispositivo.
Portanto, evite concluir apenas pela barra de progresso.
Registre o tráfego apenas se necessário
Para este diagnóstico inicial, não precisamos capturar pacotes de rede.
Primeiro determine:
- KB;
- build;
- histórico;
- estado do pacote.
Se ainda existir dúvida sobre download, aprofundamos depois.
Gere WindowsUpdate.log
Abra o PowerShell:
Get-WindowsUpdateLog
Procure:
KBxxxxxxx
Compare duas tentativas.
Queremos descobrir:
o mecanismo detectou novamente a atualização como aplicável?
Use o horário
Suponha:
Primeira instalação:
14:10
Segunda oferta:
16:35
Procure esses intervalos.
Não misture entradas das duas operações.
O que procurar conceitualmente?
Queremos reconstruir:
detecção
↓
aplicabilidade
↓
download
↓
instalação
↓
resultado
↓
nova detecção.
O ponto mais interessante é:
por que a nova detecção ainda encontra algo aplicável?
CBS.log também pode ajudar
Abra:
C:\Windows\Logs\CBS\CBS.log
Procure o horário da instalação.
O CBS.log pode fornecer informações sobre o servicing e os pacotes processados.
O Histórico diz sucesso, mas CBS mostra falha?
Esse seria um achado importante.
Não significa automaticamente que o Histórico esteja mentindo.
Pode existir diferença entre:
- operação geral registrada;
- componente específico;
- fase posterior;
- tentativa subsequente.
Precisamos interpretar a sequência.
Procure a primeira falha relevante
Assim como fizemos nos artigos anteriores, não procure apenas:
Error
Leia o contexto.
Um problema anterior pode explicar por que o estado final não ficou como esperado.
A reinicialização foi concluída?
Essa pergunta parece simples, mas é importante.
Algumas operações precisam de reinicialização para finalizar.
Se o usuário:
- desligou forçadamente;
- interrompeu o reboot;
- ficou sem energia;
- iniciou outro processo de atualização antes de concluir o anterior;
o estado merece atenção.
Isso não prova que a interrupção causou o problema.
É apenas parte da cronologia.
Faça uma reinicialização normal
Se o Windows está pedindo:
Reiniciar
não continue acumulando verificações de atualização.
Conclua primeiro a reinicialização.
Depois:
winver
e:
Verificar se há atualizações.
A mesma KB voltou imediatamente
Agora temos um cenário reproduzível.
Registre:
- KB;
- horário;
- build;
- estado no histórico.
Depois consulte os logs.
A KB voltou dias depois
Isso é um cenário diferente.
Pode existir:
- nova detecção;
- revisão;
- alteração no conteúdo aplicável;
- mudança no estado do sistema;
- outro contexto associado à mesma referência.
Não trate automaticamente como o mesmo ciclo imediato.
Consulte a documentação da KB
O número da KB precisa ser analisado junto à documentação oficial correspondente.
Verifique:
- data;
- versão;
- build;
- problemas conhecidos;
- alterações relevantes.
Isso ajuda a descobrir se existe um comportamento conhecido ou mudança relacionada à atualização.
Cuidado com tutoriais antigos
Uma solução para uma KB específica de outra versão do Windows pode não representar o comportamento atual.
Sempre relacione:
KB + versão + build + data.
Pode ser apenas o Windows Update com cache inconsistente?
Pode ser uma hipótese.
Se o mecanismo local mantém informações inconsistentes sobre a atualização, SoftwareDistribution pode entrar na investigação.
Mas não comece apagando o cache.
Primeiro confirme:
- build;
- histórico;
- pacotes;
- logs.
Quando SoftwareDistribution começa a fazer sentido?
Se observamos que:
- atualização foi aplicada;
- build corresponde ao esperado;
- pacote parece adequado;
- Windows Update continua detectando a mesma atualização de maneira incoerente;
então a camada de detecção/cache ganha importância.
Reconstrução controlada de SoftwareDistribution
Quando justificado:
net stop wuauserv
net stop bits
Depois:
ren C:\Windows\SoftwareDistribution SoftwareDistribution.old
Reinicie:
net start bits
net start wuauserv
Depois faça nova verificação.
O que queremos descobrir?
Antes:
KB reaparece.
Depois da reconstrução:
Não reaparece
A hipótese relacionada ao estado local do Windows Update ganha força.
Reaparece
Precisamos continuar.
Não recrie SoftwareDistribution repetidamente
Se a intervenção não mudou o comportamento, não existe vantagem diagnóstica em repetir a mesma ação várias vezes.
Avance para outra hipótese.
E catroot2?
Não devemos associar toda repetição de KB automaticamente a:
catroot2
Ela participa de outras estruturas relacionadas ao processo de atualização, mas precisa existir motivo para investigá-la.
Neste artigo, nosso primeiro foco é:
aplicabilidade e estado do pacote.
Component Store também pode influenciar?
Se o servicing não consegue manter um estado coerente dos componentes, o Component Store merece análise.
Comece com:
DISM /Online /Cleanup-Image /CheckHealth
Quando necessário:
DISM /Online /Cleanup-Image /ScanHealth
Se ScanHealth encontra corrupção
Agora existe evidência.
Execute:
DISM /Online /Cleanup-Image /RestoreHealth
Depois confirme novamente:
DISM /Online /Cleanup-Image /ScanHealth
E execute:
sfc /scannow
quando apropriado.
Depois teste novamente a mesma situação
Volte ao Windows Update.
Clique:
Verificar se há atualizações
A KB continua sendo oferecida?
Essa pergunta é mais importante do que simplesmente:
“DISM terminou com sucesso?”
Se a KB não reaparecer
Ótimo.
Registre:
- intervenção;
- resultado;
- build final.
Isso ajuda a relacionar a correção ao comportamento observado.
Se a KB continuar aparecendo
Não formate.
Ainda precisamos investigar:
- pacote;
- detecção;
- aplicabilidade;
- servicing;
- possíveis diferenças entre a KB exibida e o conteúdo efetivamente processado.
O problema pode estar no próprio critério de aplicabilidade?
Esse é um ponto importante.
O Windows Update precisa avaliar se determinada atualização ainda é necessária.
Se o sistema continua correspondendo aos critérios de aplicabilidade, a atualização pode voltar a ser oferecida.
Precisamos descobrir por que o estado esperado não está sendo reconhecido.
O objetivo da Parte 1
Nossa investigação inicial ficou assim:
mesma KB reaparece
↓
confirmar que é realmente a mesma KB
↓
registrar datas
↓
winver
↓
comparar build
↓
Histórico de Atualizações
↓
Get-HotFix como informação complementar
↓
DISM /Get-Packages
↓
WindowsUpdate.log
↓
CBS.log
↓
investigar aplicabilidade
↓
SoftwareDistribution somente quando justificado
↓
Component Store quando houver evidência.
O ponto central deste artigo será:
não confundir “a mesma KB apareceu novamente” com “o Windows reinstalou exatamente o mesmo conteúdo sem motivo”.
Precisamos primeiro entender como o Windows chegou à conclusão de que aquela atualização ainda era aplicável.
Windows Update instala a mesma KB várias vezes: pacotes, supersedence e aplicabilidade
Na primeira parte começamos com uma situação aparentemente simples:
KBxxxxxxx
é instalada.
O computador reinicia.
A atualização aparece no Histórico.
Depois:
KBxxxxxxx
volta ao Windows Update.
Antes de tentar corrigir, precisamos responder:
o Windows realmente está reinstalando exatamente o mesmo conteúdo?
Para isso, precisamos separar quatro conceitos:
- KB;
- pacote;
- build;
- aplicabilidade.
Essa diferença é fundamental para entender como o Windows Update decide o que oferecer ao computador.
KB não é sinônimo de arquivo
Quando vemos:
KBxxxxxxx
é fácil imaginar que esse número representa um único arquivo.
Na prática, uma KB funciona como uma referência de conhecimento e atualização utilizada para identificar determinado conjunto de informações e conteúdo.
O servicing pode trabalhar com estruturas mais detalhadas.
Por isso:
mesmo número de KB na interface
não deve ser interpretado automaticamente como:
mesmo arquivo sendo copiado novamente para os mesmos locais.
Pacote é outra camada
Quando executamos:
DISM /Online /Get-Packages
podemos encontrar identidades muito mais longas do que:
KBxxxxxxx
Isso acontece porque o servicing precisa distinguir características do pacote.
A identidade pode carregar informações necessárias para diferenciar versões, arquitetura e outros elementos.
E a build?
A build é uma das maneiras mais úteis de verificar o estado do Windows depois de uma atualização cumulativa.
Pressione:
Windows + R
Digite:
winver
Anote o número.
Por exemplo, conceitualmente:
XXXXX.1234
Depois de determinada atualização:
XXXXX.1300
A mudança ajuda a confirmar que o sistema avançou para outra revisão.
KB, pacote e build respondem perguntas diferentes
Podemos simplificar assim:
KB
Qual atualização estamos investigando?
Pacote
Qual objeto o servicing está processando?
Build
Em qual revisão o Windows terminou?
Essas três informações precisam ser correlacionadas.
Por que apenas olhar o Histórico pode enganar?
O Histórico de Atualizações é voltado ao usuário.
Ele não pretende substituir ferramentas de servicing ou logs técnicos.
Podemos encontrar entradas que representam tentativas e resultados de maneira muito mais amigável do que a estrutura interna do sistema.
Por isso, use o Histórico para começar.
Não necessariamente para encerrar o diagnóstico.
O que é aplicabilidade?
Antes de oferecer uma atualização, o Windows Update precisa determinar se ela é aplicável ao computador.
Em outras palavras:
este dispositivo precisa desse conteúdo?
Essa decisão depende do estado do sistema e das regras associadas à atualização.
Por que a aplicabilidade importa quando uma KB reaparece?
Porque o problema pode não ser:
“o Windows esqueceu que instalou”.
Pode ser:
“depois da instalação, alguma condição ainda faz o mecanismo considerar conteúdo aplicável”.
Essa diferença muda completamente a investigação.
Pense no estado, não apenas no histórico
Imagine:
Histórico:
KBxxxxxxx — instalada com sucesso
Mas o mecanismo de detecção posteriormente conclui:
determinado conteúdo ainda é aplicável.
O usuário vê a KB novamente.
Nosso trabalho é descobrir por que existe essa diferença.
O que é supersedence?
No ecossistema de atualizações, conteúdo mais novo pode substituir conteúdo anterior.
Esse relacionamento é importante porque o Windows não precisa necessariamente tratar todas as atualizações como blocos independentes que precisam permanecer sendo aplicados um por um para sempre.
Atualizações cumulativas tornam esse conceito especialmente relevante.
O que significa uma atualização cumulativa?
De maneira simplificada, uma atualização cumulativa incorpora correções acumuladas até determinado ponto.
Isso permite que um computador que não recebeu todas as atualizações cumulativas anteriores avance utilizando uma atualização posterior aplicável.
Por isso, não devemos imaginar:
KB A → obrigatoriamente KB B → obrigatoriamente KB C
como se cada pacote anterior sempre precisasse ser instalado individualmente.
Uma cumulativa mais nova pode substituir a anterior
Suponha:
KB-A
depois:
KB-B
e:
KB-B
é uma atualização cumulativa posterior aplicável.
Dependendo do relacionamento entre elas, a atualização posterior pode tornar a anterior desnecessária como instalação separada.
Por que isso importa para uma KB repetida?
Porque às vezes o usuário pesquisa:
“como instalar novamente a KB antiga?”
quando o sistema já possui uma atualização cumulativa posterior.
A pergunta correta passa a ser:
qual é a build atual e qual atualização é aplicável a ela agora?
Sempre confira a build antes de insistir em uma KB antiga
Execute:
winver
Depois compare com a documentação oficial das atualizações relevantes para aquela versão do Windows.
Se o computador já está em uma revisão posterior, insistir manualmente em um pacote antigo pode não fazer sentido.
O Windows pode dizer que a atualização não se aplica
Ao tentar instalar manualmente uma KB, podemos encontrar uma mensagem indicando que o pacote não é aplicável.
Isso não significa automaticamente:
Windows Update quebrado.
Pode significar simplesmente que o estado atual não corresponde aos critérios daquele pacote.
Não confunda “não aplicável” com “arquivo corrompido”
São situações diferentes.
Um pacote pode estar perfeitamente íntegro e ainda assim não ser aplicável à instalação atual.
Como investigar os pacotes com DISM
Execute:
DISM /Online /Get-Packages
O resultado pode ser extenso.
Procure informações relacionadas ao período e à atualização investigada.
Quando necessário, salve a saída em arquivo para facilitar a pesquisa.
Podemos salvar a lista de pacotes
No Prompt de Comando:
DISM /Online /Get-Packages > "%userprofile%\Desktop\pacotes.txt"
Agora você pode abrir:
pacotes.txt
e pesquisar com mais facilidade.
O que procurar?
Queremos encontrar:
- identidade do pacote;
- estado;
- relação temporal;
- referências que possam ser correlacionadas ao CBS.log.
Não queremos apenas encontrar qualquer linha contendo números parecidos com a KB.
Estados dos pacotes
O servicing pode apresentar diferentes estados para os pacotes.
A interpretação depende do contexto.
Um erro comum é encontrar um estado que não parece familiar e concluir:
“está corrompido”.
Não faça isso.
Estado de pacote não deve ser interpretado sem considerar a operação que estava acontecendo.
Pacote instalado
Se encontramos evidência de que o pacote foi instalado e a build corresponde ao resultado esperado, mas o Windows Update continua oferecendo conteúdo associado à mesma KB, a investigação de detecção ganha força.
Pacote em estado inesperado
Agora precisamos consultar:
CBS.log
e verificar se a tentativa anterior realmente terminou de maneira limpa.
O estado pode ser consequência de uma operação interrompida ou de outra condição.
Não tente corrigi-lo manualmente antes de entender a sequência.
CBS.log: compare instalação e nova detecção
Temos dois momentos:
Momento A
A KB foi instalada.
Momento B
A KB reapareceu.
O CBS.log é particularmente útil para o Momento A.
WindowsUpdate.log pode ajudar muito no Momento B.
Momento A — o que queremos saber?
Queremos descobrir:
- pacote processado;
- resultado;
- eventual erro;
- necessidade de reinicialização;
- conclusão do servicing.
Momento B — o que queremos saber?
Queremos descobrir:
por que o mecanismo voltou a considerar a atualização aplicável?
Essa é uma pergunta de detecção.
Não misture as duas fases
Se você procura apenas:
KBxxxxxxx
em um arquivo enorme, pode misturar:
- primeira instalação;
- reboot;
- nova detecção;
- segunda tentativa.
Use data e horário.
Crie uma pequena linha do tempo
Exemplo:
09:10 — KB detectada
09:18 — download concluído
09:25 — instalação
09:30 — reinicialização
09:40 — winver conferido
10:15 — nova verificação
10:16 — mesma KB oferecida novamente
Agora os logs ficam muito mais fáceis de interpretar.
WindowsUpdate.log e aplicabilidade
Execute:
Get-WindowsUpdateLog
Abra o arquivo gerado.
Procure:
KBxxxxxxx
Depois concentre-se no horário:
10:15–10:16
do exemplo.
Queremos entender o que aconteceu durante a nova verificação.
Não procure apenas “download”
A parte mais interessante acontece antes.
Queremos saber por que o Windows chegou à conclusão de que precisava oferecer a atualização.
O mecanismo pode detectar conteúdo aplicável novamente
Quando isso acontece, precisamos comparar o estado esperado após a primeira instalação com o estado que o sistema realmente possui.
Isso pode envolver:
- pacote;
- componentes;
- build;
- conclusão da reinicialização;
- informações locais de detecção.
O computador reiniciou, mas concluiu tudo?
Reiniciar e voltar à Área de Trabalho não garante, por si só, que todas as operações terminaram exatamente como esperado.
Consulte os logs.
Procure sinais de:
- conclusão;
- falha;
- rollback;
- operações pendentes.
O que é estado pendente?
Algumas alterações dependem de uma fase posterior, frequentemente relacionada à reinicialização.
Se o sistema permanece com operações pendentes, novas verificações podem produzir resultados que precisam ser interpretados dentro desse contexto.
Não apague arquivos pending.xml
Tutoriais antigos podem recomendar alterações manuais em estruturas de servicing para resolver estados pendentes.
Evite esse tipo de intervenção sem diagnóstico preciso.
Mexer manualmente em estruturas de servicing pode transformar um problema de atualização em corrupção maior.
Uma reinicialização normal continua sendo o primeiro teste
Se existe indicação de reinicialização pendente:
reinicie.
Depois:
winver
e:
Verificar se há atualizações.
Não tente “limpar o estado pendente” manualmente antes disso.
A build corresponde à atualização, mas a KB continua voltando
Esse é um cenário muito interessante.
Agora sabemos:
- a atualização aparentemente avançou a build;
- o Windows iniciou normalmente;
- a KB reaparece.
Precisamos olhar com mais atenção para:
- detecção;
- conteúdo aplicável;
- cache;
- pacote;
- possível comportamento específico daquela atualização.
Consulte a documentação oficial da KB
Verifique:
- build resultante;
- data;
- versão do Windows;
- problemas conhecidos;
- notas relevantes.
A documentação é especialmente importante quando apenas uma KB apresenta comportamento estranho.
Não use informações de outra versão do Windows 11
Uma mesma pesquisa pode retornar resultados de:
- Windows 10;
- Windows 11 22H2;
- 23H2;
- 24H2;
- outra versão.
Confirme o ambiente real com:
winver
antes de aplicar qualquer conclusão.
E se a build não corresponde?
Agora precisamos investigar se a instalação realmente foi concluída.
Volte ao CBS.log.
Procure:
- pacote;
- erros;
- falha;
- rollback;
- conclusão.
O Histórico de Atualizações não deve ser nossa única evidência.
Pode existir rollback silencioso para o usuário?
Uma falha durante a conclusão pode fazer o Windows retornar a um estado anterior.
Em alguns casos, o usuário percebe mensagens durante o boot.
Em outros, pode apenas notar que a build não avançou como esperava.
Por isso, compare:
antes e depois.
A mesma KB reaparece porque a primeira tentativa não foi realmente concluída
Esse é um cenário diferente de:
“Windows reinstala uma atualização já instalada”.
Aqui a atualização continua sendo necessária porque a primeira operação não chegou ao estado final esperado.
O nome exibido pode ser igual, mas o contexto mudou
Não interprete a interface de forma excessivamente literal.
Uma referência igual na tela não significa que todos os detalhes internos da segunda tentativa sejam idênticos aos da primeira.
Por isso os logs são necessários.
O Windows Update oferece novamente depois de limpar SoftwareDistribution
Se o cache foi reconstruído e a KB continua sendo oferecida, isso pode indicar que o mecanismo fez uma nova avaliação e ainda considerou o conteúdo aplicável.
Nesse caso, repetir a limpeza não acrescenta muito.
Isso enfraquece a hipótese de cache?
Sim, especialmente se:
- a reconstrução foi feita corretamente;
- nova detecção ocorreu;
- o comportamento permaneceu exatamente igual.
Não elimina absolutamente todas as possibilidades relacionadas ao Windows Update, mas muda a prioridade.
Verifique o Component Store
Execute:
DISM /Online /Cleanup-Image /CheckHealth
Depois, quando necessário:
DISM /Online /Cleanup-Image /ScanHealth
Se saudável, registre.
Não execute RestoreHealth como se ScanHealth tivesse encontrado corrupção.
Se houver corrupção
Agora:
DISM /Online /Cleanup-Image /RestoreHealth
Depois:
DISM /Online /Cleanup-Image /ScanHealth
E:
sfc /scannow
quando apropriado.
Reinicie.
Faça nova verificação do Windows Update.
O comportamento mudou?
Essa é sempre a pergunta.
Antes
KB reaparecia.
Depois
KB não reaparece.
Temos uma alteração relevante.
Depois
KB reaparece igual.
Continue investigando.
Uma atualização posterior resolve a repetição
Esse cenário pode acontecer.
Uma cumulativa posterior aplicável pode substituir conteúdo anterior e alterar o estado que estava provocando a oferta repetida.
Mas não use isso como desculpa para ignorar qualquer falha.
Precisamos confirmar:
- nova atualização instalada;
- build avançou;
- Windows Update não oferece mais a anterior;
- sistema permanece saudável.
Não force uma KB antiga depois disso
Se o sistema já avançou para uma atualização cumulativa posterior aplicável, insistir na instalação manual da antiga pode ser desnecessário.
Consulte sempre o estado atual.
Get-HotFix pode não mostrar tudo que você espera
Get-HotFix
é útil em determinados contextos.
Mas não trate sua ausência como prova absoluta de que determinada atualização não existe no sistema.
Combine informações.
DISM /Get-Packages também não deve ser usado isoladamente
O mesmo vale para DISM.
Precisamos correlacionar:
- Histórico;
- build;
- pacotes;
- CBS;
- WindowsUpdate.log;
- documentação da KB.
Diagnóstico confiável surge da convergência dessas evidências.
Quando a repetição é realmente suspeita?
Um cenário forte seria:
- mesma KB;
- mesma versão;
- mesmo conteúdo aplicável;
- instalação registrada;
- build adequada;
- reinicialização concluída;
- nova detecção oferece novamente;
- comportamento se repete.
Agora temos uma repetição que merece investigação profunda.
Quando pode ser apenas uma interpretação errada?
Por exemplo:
- número de KB aparece em mais de um contexto;
- atualização posterior mudou o estado;
- usuário confundiu tentativa anterior com instalação concluída;
- build nunca avançou;
- reinicialização não terminou;
- atualização foi revertida.
Esses cenários parecem iguais olhando apenas a interface.
Tecnicamente são diferentes.
Por que esse diagnóstico é melhor do que esconder a atualização?
Porque esconder ou bloquear a oferta não explica:
por que ela continua sendo considerada necessária.
Se existe um problema de servicing, simplesmente impedir a atualização pode deixar a causa intacta.
Não desative o Windows Update
Desativar permanentemente:
wuauserv
não corrige o estado do sistema.
Apenas impede que o mecanismo funcione normalmente.
Não bloqueie a KB antes de entender a causa
Em situações específicas pode existir motivo operacional para adiar determinada atualização.
Mas isso é diferente de usar bloqueio como substituto para diagnóstico.
Não remova pacotes para “zerar” o Windows Update
Evite comandos de remoção baseados apenas na ideia:
“se eu apagar tudo relacionado à KB, ela instala do zero”.
O servicing possui dependências e relacionamentos.
A intervenção pode piorar o problema.
Nosso diagnóstico agora está mais refinado
Temos:
KB reaparece
↓
é realmente a mesma KB?
↓
build mudou?
↓
instalação concluiu?
↓
reinicialização concluiu?
↓
qual é o estado do pacote?
↓
existe atualização posterior que substitui a anterior?
↓
WindowsUpdate.log considera o conteúdo aplicável?
↓
CBS.log mostra falha na instalação anterior?
↓
cache foi testado?
↓
Component Store está saudável?
Essa árvore elimina boa parte das falsas interpretações.
A mesma KB continua reaparecendo: como aprofundar o diagnóstico
Chegamos a um cenário muito específico.
O usuário instalou:
KBxxxxxxx
Reiniciou.
A atualização aparece no Histórico.
A build foi conferida.
Mesmo assim, uma nova verificação oferece novamente uma atualização associada à mesma KB.
Talvez SoftwareDistribution já tenha sido reconstruída.
Talvez DISM e SFC não encontrem corrupção.
Nesse ponto, repetir os mesmos comandos deixa de ser diagnóstico.
Precisamos separar três possibilidades:
1. A atualização não terminou no estado que imaginamos.
2. O Windows Update continua detectando conteúdo aplicável.
3. A repetição é apenas aparente e existe uma diferença entre as operações.
Refaça a linha do tempo antes de continuar
Registre:
KB: KBxxxxxxx
Build antes: XXXXX.XXXX
Build depois: XXXXX.XXXX
Primeira instalação: horário
Reinicialização: horário
Nova detecção: horário
Depois anote:
SoftwareDistribution recriada: sim/não
DISM ScanHealth: resultado
SFC: resultado
Essa ficha evita repetir procedimentos.
Confirme novamente a build
Execute:
winver
Não confie apenas na memória.
Registre a build atual.
Se a atualização deveria alterar a revisão do sistema, compare o resultado com a documentação correspondente àquela atualização e versão do Windows.
A build está correta
Esse resultado muda o diagnóstico.
Se:
- a KB aparece instalada;
- a build corresponde ao estado esperado;
- o Windows funciona normalmente;
a hipótese de que a atualização simplesmente nunca foi aplicada perde força.
Agora precisamos investigar a nova detecção.
A build continua antiga
Nesse caso, a instalação anterior merece atenção.
Volte para:
CBS.log
e investigue o horário da tentativa anterior.
Pode ter ocorrido uma falha durante:
- aplicação;
- configuração;
- reinicialização;
- conclusão.
Procure rollback
Uma atualização pode iniciar normalmente e posteriormente não permanecer aplicada.
Quando isso ocorre, a atualização continua necessária.
Por isso, a mesma KB pode reaparecer.
Esse cenário não é uma verdadeira:
“reinstalação infinita de uma atualização já aplicada”.
É uma atualização que não permaneceu no estado final esperado.
Consulte o Monitor de Confiabilidade
Pressione:
Windows + R
Digite:
perfmon /rel
Observe o período da atualização.
O Monitor de Confiabilidade pode ajudar a correlacionar:
- falhas;
- atualizações;
- travamentos;
- reinicializações.
Ele não substitui CBS.log, mas fornece outra visão cronológica.
Consulte o Visualizador de Eventos
Abra:
Visualizador de Eventos
Concentre-se no horário da instalação e da reinicialização.
Evite pesquisar milhares de eventos aleatoriamente.
Use a linha do tempo.
O horário continua sendo nosso principal filtro
Se a instalação aconteceu às:
21:40
e o computador reiniciou às:
21:48
não precisamos começar analisando eventos das 10 horas da manhã.
Diagnóstico melhora muito quando existe uma janela temporal precisa.
Verifique os serviços envolvidos
Abra o Terminal como administrador.
Execute:
sc query wuauserv
Depois:
sc query bits
E, quando relevante:
sc query cryptsvc
Esses comandos mostram o estado dos serviços.
Serviço parado significa defeito?
Não necessariamente.
Alguns serviços podem não permanecer executando continuamente.
O estado precisa ser interpretado dentro da operação que estamos investigando.
Não use:
STOPPED = quebrado
como regra.
Teste durante uma verificação do Windows Update
Abra:
Configurações → Windows Update
Clique:
Verificar se há atualizações
Observe o comportamento.
Se necessário, consulte novamente os serviços durante a operação.
O contexto importa.
BITS merece atenção quando existe problema de transferência
BITS participa de transferências em segundo plano utilizadas por diferentes componentes.
Mas, se o pacote já foi obtido e a questão está na aplicabilidade depois da instalação, BITS pode não ser nossa principal hipótese.
Não registre DLLs aleatoriamente
Tutoriais antigos sobre Windows Update frequentemente apresentam enormes sequências de:
regsvr32
para registrar bibliotecas.
Esse tipo de abordagem não deve ser nossa primeira escolha.
Precisamos saber qual componente está realmente falhando.
Não execute um “reset total” antes de terminar o diagnóstico
Scripts de reset podem alterar:
- serviços;
- cache;
- catálogos;
- configurações;
- componentes relacionados.
Se fizermos tudo ao mesmo tempo e a KB desaparecer, perdemos a capacidade de saber qual condição era relevante.
SoftwareDistribution já foi recriada
Se você executou corretamente:
net stop wuauserv
net stop bits
renomeou SoftwareDistribution e iniciou os serviços novamente, depois fez uma nova detecção e a KB voltou:
não repita indefinidamente.
Registre:
cache reconstruído → problema permaneceu.
Isso é uma informação diagnóstica.
Quando catroot2 entra?
Agora podemos considerar essa estrutura se houver contexto relacionado à validação ou infraestrutura correspondente.
O caminho é:
C:\Windows\System32\catroot2
Não confunda com:
catroot
Redefinição controlada de catroot2
Quando houver justificativa:
net stop cryptsvc
Depois:
ren C:\Windows\System32\catroot2 catroot2.old
Em seguida:
net start cryptsvc
Faça uma nova verificação.
Teste imediatamente
Antes:
KBxxxxxxx reaparece
Depois:
Verificar se há atualizações
Observe.
Se a KB não reaparece, a intervenção mudou o comportamento.
Se reaparece exatamente igual, continue.
Não redefina catroot2 cinco vezes
Assim como SoftwareDistribution, repetir a mesma intervenção sem mudança de resultado não melhora o diagnóstico.
Pacote manual como teste
Quando existe um pacote apropriado disponível para a atualização, podemos utilizar a instalação manual como ferramenta de diagnóstico.
Consulte o pacote correto para:
- versão;
- arquitetura;
- atualização.
Por que testar manualmente se a KB já aparece instalada?
Porque queremos descobrir como o instalador interpreta o estado atual.
Dependendo do pacote e do sistema, ele pode indicar que:
- a atualização não é aplicável;
- já existe estado equivalente;
- instalação é necessária;
- ocorreu outro erro.
Cada resultado fornece uma pista.
Não force o pacote
Se o instalador informa que a atualização não se aplica ao computador, não tente contornar a verificação apenas para “provar” que consegue instalar.
Primeiro descubra por que ela não se aplica.
Talvez o computador já esteja em um estado posterior.
Verifique se existe atualização cumulativa mais nova
Essa etapa é fundamental.
Imagine:
KB-A
está causando confusão.
Mas já existe:
KB-B
mais recente e aplicável ao mesmo sistema.
Se KB-B substitui o conteúdo anterior dentro do modelo cumulativo, instalar a atualização mais nova pode levar o Windows a um estado posterior sem necessidade de insistir em KB-A.
Não use atualização mais nova apenas para esconder o problema
Depois da atualização posterior, confirme:
winver
Depois:
DISM /Online /Cleanup-Image /ScanHealth
quando houver motivo.
Faça nova verificação do Windows Update.
Queremos confirmar:
- build atualizada;
- KB antiga não reaparece;
- sistema saudável.
A atualização posterior instalou e a antiga desapareceu
Isso pode indicar que o sistema avançou para um estado em que a oferta anterior deixou de ser aplicável.
Nesse cenário, insistir na KB anterior não seria necessário.
A atualização posterior também falha
Agora temos uma pista diferente.
O problema talvez não esteja restrito à primeira KB.
Amplie para:
- servicing;
- Component Store;
- integridade;
- logs.
Execute ScanHealth novamente se houver nova evidência
Use:
DISM /Online /Cleanup-Image /ScanHealth
Se o resultado indicar corrupção reparável:
DISM /Online /Cleanup-Image /RestoreHealth
Depois confirme:
DISM /Online /Cleanup-Image /ScanHealth
Execute SFC quando apropriado
sfc /scannow
Se houver reparação, reinicie.
Depois faça nova verificação.
O Component Store está saudável e a KB continua voltando
Esse é o cenário mais interessante deste artigo.
Temos:
- build correta;
- pacote aparentemente aplicado;
- Component Store saudável;
- SFC saudável;
- SoftwareDistribution reconstruída;
- KB ainda oferecida.
Agora precisamos concentrar a investigação em:
detecção e aplicabilidade.
Compare duas detecções no WindowsUpdate.log
Gere novamente:
Get-WindowsUpdateLog
Localize:
Detecção 1
antes da instalação.
Detecção 2
depois da instalação.
Compare.
Queremos descobrir por que o conteúdo ainda aparece como aplicável na segunda avaliação.
Não compare apenas o nome exibido
Observe o contexto associado.
O mesmo título amigável pode esconder diferenças que a interface não apresenta claramente.
Existe uma diferença de revisão?
Esse é exatamente o tipo de detalhe que precisa ser verificado na documentação e nos registros.
Não assuma que duas linhas visualmente iguais representam objetos internamente idênticos.
Consulte CBS.log da segunda instalação
Se o usuário deixa a KB instalar novamente, registre o horário.
Depois abra:
C:\Windows\Logs\CBS\CBS.log
Compare:
primeira instalação
com:
segunda instalação.
O servicing processa exatamente as mesmas operações?
Se não, a repetição pode ser apenas aparente.
Se sim, e o estado continua voltando, temos uma condição mais persistente.
A KB instala sempre e a build não muda mais
Agora temos uma evidência interessante.
O sistema pode estar processando conteúdo sem produzir uma mudança de build visível.
Isso exige análise da atualização específica.
Nem toda atualização precisa ser interpretada apenas pelo último número do winver.
Por isso, combine a build com os pacotes e a documentação.
A KB reaparece depois de cada reinicialização
Esse padrão sugere investigar se algum estado está sendo revertido ou reconstruído durante o boot.
Compare:
antes do reboot
e:
depois do reboot.
Execute DISM /Get-Packages antes e depois
Salve:
DISM /Online /Get-Packages > "%userprofile%\Desktop\pacotes-antes.txt"
Depois da instalação e reinicialização:
DISM /Online /Get-Packages > "%userprofile%\Desktop\pacotes-depois.txt"
Agora temos duas fotografias do estado.
Comparar estados é melhor do que confiar na memória
A diferença entre:
pacotes-antes.txt
e:
pacotes-depois.txt
pode ajudar a entender se houve mudança relevante no servicing.
Não remova o pacote para testar
Ainda não.
Comparação é uma intervenção de baixo risco.
Remoção altera o estado.
Sempre prefira observar antes de modificar.
E se o estado voltar depois do reboot?
Isso merece atenção especial.
Pode existir:
- falha de conclusão;
- rollback;
- inconsistência de servicing;
- outro mecanismo interferindo.
Volte aos logs do período de reinicialização.
Armazenamento entra na investigação?
Somente se existirem evidências adicionais.
Por exemplo:
- corrupção recorrente;
- erros de arquivos;
- eventos de armazenamento;
- falhas variadas;
- Component Store que volta a corromper.
Uma KB repetida sozinha não diagnostica SSD.
CHKDSK quando houver justificativa
Podemos utilizar:
chkdsk C: /scan
para verificar o sistema de arquivos em cenários apropriados.
Mas isso não é um teste completo de saúde física do SSD.
Investigue SMART quando houver sintomas
Se a corrupção reaparece, analise também informações de saúde do dispositivo e, quando possível, ferramentas do fabricante.
O objetivo é descobrir se existe uma causa recorrente.
RAM também não deve ser culpada automaticamente
Memória instável pode contribuir para comportamento imprevisível.
Mas uma atualização repetida, isoladamente, não é diagnóstico de RAM.
Procure outras evidências de instabilidade.
Softwares de otimização podem interferir?
Scripts e ferramentas que alteram:
- Windows Update;
- serviços;
- políticas;
- componentes;
- tarefas;
merecem investigação quando existe relação temporal clara com o início do problema.
Não culpe qualquer programa instalado
Ter antivírus, utilitário ou programa de manutenção no computador não significa que ele seja responsável.
Precisamos de evidência.
Políticas do Windows Update
Em computadores gerenciados, políticas podem influenciar o comportamento de atualização.
Isso é especialmente importante em:
- empresas;
- computadores ingressados em ambientes administrados;
- máquinas modificadas por scripts;
- sistemas que já utilizaram ferramentas para bloquear atualizações.
Verifique se o computador é gerenciado
A própria interface do Windows pode indicar quando algumas configurações são controladas por uma organização.
Se isso ocorre, investigue as políticas aplicáveis antes de redefinir componentes.
Não apague políticas sem saber sua origem
Em ambiente empresarial, elas podem ser intencionais.
Em computador doméstico, podem ter sido deixadas por alguma ferramenta.
Os dois cenários exigem abordagens diferentes.
Reparação in-place
Se chegamos a um ponto em que:
- o servicing não mantém estado coerente;
- atualizações repetem ou falham;
- logs apontam problemas persistentes;
- reparações normais não resolvem;
uma reparação in-place pode ser considerada antes da instalação limpa.
O objetivo da reparação in-place
Reinstalar componentes do Windows preservando, quando o Setup compatível oferece essa opção:
- arquivos pessoais;
- aplicativos;
- configurações.
Ela pode reconstruir estruturas que reparações pontuais não resolveram.
Faça backup antes
Mesmo quando a opção de preservação está disponível, faça backup dos dados importantes.
Uma intervenção profunda no sistema sempre merece preparação.
Depois da reparação
Não declare sucesso apenas porque o Windows iniciou.
Confirme:
winver
Depois faça:
Verificar se há atualizações
A mesma KB continua voltando?
Se não voltar
Ótimo.
Continue verificando se atualizações posteriores são instaladas normalmente.
Se voltar mesmo depois da reparação
Agora precisamos verificar com atenção:
- atualização específica;
- políticas;
- software externo;
- hardware/estabilidade quando existirem sintomas;
- comportamento documentado para aquela KB.
Formatar automaticamente ainda não explica a causa.
Instalação limpa é a última etapa?
Em muitos casos, ela fica perto do final da árvore.
Mas a decisão depende do estado geral do computador.
Se todo o sistema está comprometido, reconstruir pode fazer sentido.
Se apenas uma KB específica apresenta um comportamento conhecido, formatar pode ser completamente desproporcional.
O diagnóstico da Parte 3
Chegamos a esta sequência:
KB reaparece
↓
confirmar build
↓
verificar se houve rollback
↓
analisar horários
↓
serviços quando relevantes
↓
SoftwareDistribution já testada?
↓
catroot2 somente quando justificado
↓
pacote manual
↓
verificar cumulativa posterior
↓
WindowsUpdate.log
↓
CBS.log
↓
comparar pacotes antes/depois
↓
Component Store
↓
corrupção recorrente?
↓
políticas e software externo
↓
reparação in-place
↓
instalação limpa somente quando necessária.
Chegamos ao ponto principal deste artigo.
O Windows Update mostra:
KBxxxxxxx
A atualização instala.
O computador reinicia.
Ela aparece no Histórico de Atualizações.
Depois, aparentemente a mesma:
KBxxxxxxx
volta.
Antes de concluir que existe um loop do Windows Update, precisamos provar que realmente estamos diante da mesma operação.
A investigação deve responder:
A build mudou?
A primeira instalação realmente terminou?
Houve rollback?
O pacote permanece no estado esperado?
Existe uma atualização cumulativa posterior?
O Windows Update continua considerando conteúdo aplicável?
A segunda instalação processa exatamente o mesmo pacote?
Somente depois dessas respostas conseguimos separar uma repetição verdadeira de uma repetição apenas aparente.
Árvore definitiva de diagnóstico
Comece anotando:
KBxxxxxxx
Depois execute:
winver
Registre:
- versão do Windows;
- build;
- data;
- horário.
Abra:
Configurações → Windows Update → Histórico de atualizações
Confirme a entrada correspondente.
Agora siga a sequência.
Etapa 1 — Confirme se é realmente a mesma KB
Compare:
- número;
- título;
- categoria;
- data;
- horário.
Não confie apenas na lembrança.
Se possível, registre as duas ocorrências.
Etapa 2 — Compare a build
Antes da instalação:
winver
Depois da instalação e reinicialização:
winver
Se a atualização deveria alterar a revisão do Windows, essa comparação pode fornecer uma evidência importante.
Etapa 3 — A build avançou?
Sim
A atualização provavelmente produziu alguma mudança relevante no estado do Windows.
Se a KB reaparece, investigue:
- aplicabilidade;
- detecção;
- pacotes;
- cache;
- possível diferença entre as duas ofertas.
Não
Investigue se a instalação realmente chegou ao estado final esperado.
Dê atenção a:
- CBS.log;
- reinicialização;
- rollback;
- erros durante servicing.
Etapa 4 — Reinicie normalmente
Se o Windows ainda solicita reinicialização, conclua essa etapa antes de continuar.
Depois:
winver
e:
Verificar se há atualizações
Se a KB reaparecer, registre o horário.
Etapa 5 — Gere WindowsUpdate.log
No PowerShell:
Get-WindowsUpdateLog
Procure:
KBxxxxxxx
Concentre-se no horário da nova detecção.
A pergunta é:
por que o Windows voltou a considerar a atualização aplicável?
Etapa 6 — Consulte CBS.log
Abra:
C:\Windows\Logs\CBS\CBS.log
Use o horário da primeira instalação.
Procure:
- pacote;
- falha;
- erro;
- conclusão;
- rollback;
- operação pendente.
Depois compare com a segunda tentativa.
Etapa 7 — Consulte os pacotes
Execute:
DISM /Online /Get-Packages
Se quiser facilitar a comparação:
DISM /Online /Get-Packages > "%userprofile%\Desktop\pacotes.txt"
Procure informações relacionadas ao pacote investigado.
Não remova nada.
Etapa 8 — Verifique se existe uma cumulativa posterior
Antes de insistir em uma KB anterior, verifique se o Windows já possui ou pode receber uma atualização cumulativa mais nova aplicável.
Uma cumulativa posterior pode substituir conteúdo anterior.
Nesse cenário, insistir na instalação manual da KB antiga pode não fazer sentido.
Etapa 9 — Verifique o Component Store
Execute:
DISM /Online /Cleanup-Image /CheckHealth
Quando necessário:
DISM /Online /Cleanup-Image /ScanHealth
Se houver corrupção reparável:
DISM /Online /Cleanup-Image /RestoreHealth
Depois confirme novamente:
DISM /Online /Cleanup-Image /ScanHealth
Etapa 10 — Execute SFC quando apropriado
Use:
sfc /scannow
Se o SFC reparar arquivos, reinicie quando necessário.
Depois teste novamente o Windows Update.
Etapa 11 — O comportamento sugere cache?
Quando a evidência aponta para estado local inconsistente do Windows Update, podemos reconstruir SoftwareDistribution.
Pare os serviços:
net stop wuauserv
net stop bits
Renomeie:
ren C:\Windows\SoftwareDistribution SoftwareDistribution.old
Inicie:
net start bits
net start wuauserv
Faça uma nova verificação.
Etapa 12 — A KB continua voltando?
Se sim, não recrie SoftwareDistribution repetidamente.
Agora sabemos que aquela intervenção não resolveu o comportamento.
Avance.
Etapa 13 — catroot2 somente quando justificado
Quando o contexto indicar que essa camada merece investigação:
net stop cryptsvc
Depois:
ren C:\Windows\System32\catroot2 catroot2.old
E:
net start cryptsvc
Teste novamente.
Não confunda catroot2 com catroot.
Etapa 14 — Instalação manual como diagnóstico
Quando houver pacote apropriado, a instalação manual pode ajudar a descobrir como o Windows interpreta o estado atual.
O resultado pode indicar:
- pacote aplicável;
- pacote não aplicável;
- erro;
- outro estado.
Registre a mensagem exata.
Etapa 15 — Compare antes e depois
Salve uma lista antes:
DISM /Online /Get-Packages > "%userprofile%\Desktop\pacotes-antes.txt"
Depois da instalação e reinicialização:
DISM /Online /Get-Packages > "%userprofile%\Desktop\pacotes-depois.txt"
Agora podemos comparar o estado.
Etapa 16 — Procure corrupção recorrente
Se DISM ou SFC encontram problemas repetidamente, a pergunta muda.
Não queremos apenas reparar novamente.
Queremos descobrir:
por que a integridade está sendo perdida?
Nesse cenário, armazenamento, memória, estabilidade e software de baixo nível podem merecer investigação conforme as demais evidências.
Etapa 17 — Verifique políticas quando aplicável
Em computadores gerenciados ou modificados por ferramentas de otimização, verifique se existem políticas influenciando o Windows Update.
Não remova políticas empresariais sem autorização e sem conhecer sua finalidade.
Etapa 18 — Reparação in-place
Se o servicing permanece incoerente e as reparações convencionais não resolvem, uma reparação in-place pode ser considerada antes de uma instalação limpa.
Faça backup antes.
Use mídia compatível.
Confira cuidadosamente a opção de preservação de arquivos e aplicativos apresentada pelo Setup.
Repetição real versus repetição aparente
Essa distinção resume todo o artigo.
Repetição aparentemente real
Temos evidências como:
- mesma KB;
- mesma condição;
- instalação concluída;
- build esperada;
- reinicialização concluída;
- pacote presente;
- nova detecção;
- nova instalação;
- comportamento repetido.
Agora existe um padrão consistente que merece investigação profunda.
Repetição aparente
O usuário vê a mesma KB, mas descobrimos que:
- a primeira instalação falhou;
- houve rollback;
- a build não avançou;
- existia reinicialização pendente;
- o contexto da segunda oferta era diferente;
- uma atualização posterior mudou a aplicabilidade;
- a interface não mostrava todos os detalhes internos.
Nesse caso, dizer simplesmente:
“o Windows instalou a mesma atualização duas vezes”
seria uma simplificação.
Tabela — Sintoma × primeira área de investigação
| Sintoma | Área inicial |
|---|---|
| KB aparece instalada e volta imediatamente | detecção e aplicabilidade |
| KB volta depois do reboot | conclusão, CBS e rollback |
| Build não muda | confirmar instalação |
| Build muda e KB volta | detecção, pacote e aplicabilidade |
| SoftwareDistribution resolve | estado local/cache ganha relevância |
| SoftwareDistribution não resolve | investigar outra camada |
| DISM encontra corrupção | Component Store |
| SFC encontra arquivos corrompidos | integridade dos arquivos protegidos |
| Cumulativa posterior instala | verificar novo estado e supersedence |
| Pacote manual não é aplicável | conferir build, versão e pacote |
| Pacote manual também falha | servicing e logs |
| Várias atualizações começam a falhar | problema mais amplo |
| Corrupção reaparece | investigar causa recorrente |
| Repetição começou após ferramenta de otimização | revisar alterações e políticas |
| CBS mostra rollback | investigar motivo do rollback |
A tabela indica por onde começar.
Não substitui o diagnóstico.
Comandos principais deste diagnóstico
Verificar edição
DISM /Online /Get-CurrentEdition
Consultar pacotes
DISM /Online /Get-Packages
Gerar WindowsUpdate.log
Get-WindowsUpdateLog
Verificação rápida do Component Store
DISM /Online /Cleanup-Image /CheckHealth
Análise do Component Store
DISM /Online /Cleanup-Image /ScanHealth
Reparação quando necessária
DISM /Online /Cleanup-Image /RestoreHealth
Arquivos protegidos
sfc /scannow
Windows Update
sc query wuauserv
BITS
sc query bits
Cryptographic Services
sc query cryptsvc
Sistema de arquivos quando houver justificativa
chkdsk C: /scan
Esses comandos não formam um script para executar de cima a baixo.
Cada um responde a uma pergunta diferente.
O que não fazer quando a mesma KB reaparece
Não desative permanentemente o Windows Update
Impedir o serviço de funcionar não explica por que a atualização continua sendo considerada necessária.
Não remova a KB imediatamente
Antes de remover qualquer atualização, descubra o estado real do sistema.
Não remova pacotes aleatoriamente com DISM
Uma identidade encontrada em CBS.log não é autorização para removê-la.
Não apague WinSxS
Nunca trate:
C:\Windows\WinSxS
como uma pasta de cache comum.
Não apague arquivos de servicing manualmente
Evite modificar manualmente estruturas protegidas para tentar “zerar” o estado de uma atualização.
Não execute scripts desconhecidos de reset
Um arquivo BAT que altera dezenas de componentes pode esconder a causa original e criar novos problemas.
Não limpe SoftwareDistribution indefinidamente
Se já foi reconstruída corretamente e o comportamento permaneceu igual, registre o resultado e avance.
Não redefina catroot2 automaticamente
Utilize essa intervenção quando houver contexto técnico.
Não force uma KB antiga
Se o computador já possui uma atualização cumulativa posterior aplicável, insistir no pacote antigo pode ser desnecessário.
Não conclua que o SSD está defeituoso
Uma atualização repetida isoladamente não diagnostica armazenamento.
Não conclua que a RAM está ruim
Também precisamos de outras evidências antes de investigar memória como causa provável.
Não formate como primeiro teste
Uma instalação limpa pode eliminar os logs e o estado que permitiriam descobrir o que realmente aconteceu.
Como saber se o problema foi realmente resolvido?
Suponha que antes tivéssemos:
KBxxxxxxx
instala.
↓
reinicia.
↓
reaparece.
Depois da correção, faça uma nova verificação.
A KB não deve continuar entrando no mesmo ciclo problemático.
Confira o Histórico de Atualizações
Abra:
Configurações → Windows Update → Histórico de atualizações
Confirme o resultado.
Confira a build
Execute:
winver
Registre a revisão final.
Faça nova busca por atualizações
Clique:
Verificar se há atualizações
Observe se a KB volta.
Reinicie novamente quando necessário
Se o problema acontecia somente depois do reboot, precisamos reproduzir exatamente essa condição.
Reinicie.
Depois faça nova busca.
Não declare sucesso antes de reproduzir o teste original
Se o problema era:
“a KB volta depois de reiniciar”
então:
“instalou sem erro”
ainda não é confirmação suficiente.
Precisamos reiniciar e verificar novamente.
FAQ — Windows Update instala a mesma KB várias vezes
Por que o Windows Update instala a mesma atualização novamente?
Existem diferentes possibilidades.
A instalação anterior pode não ter sido concluída, pode ter ocorrido rollback ou o mecanismo pode continuar encontrando conteúdo aplicável.
Também precisamos confirmar se as duas ocorrências realmente representam o mesmo estado interno.
Se a KB aparece no Histórico, significa que foi totalmente instalada?
O Histórico é uma fonte importante, mas não deve ser a única evidência em um diagnóstico avançado.
Compare também build, pacotes e logs.
Como verificar se a atualização mudou o Windows?
Use:
winver
e compare a build antes e depois quando a atualização investigada altera a revisão do sistema.
A mesma KB pode aparecer mais de uma vez?
Pode existir mais de uma ocorrência associada à mesma referência em determinados contextos.
Por isso, compare data, resultado, build, pacote e logs antes de concluir que houve reinstalação idêntica.
O que é aplicabilidade?
É o processo pelo qual o mecanismo determina se determinado conteúdo de atualização é necessário para o estado atual do dispositivo.
O que é supersedence?
É a relação em que conteúdo de atualização mais novo substitui conteúdo anterior.
Esse conceito é particularmente importante ao analisar atualizações cumulativas.
Preciso instalar todas as cumulativas antigas?
Em geral, o modelo cumulativo permite que uma atualização posterior aplicável incorpore correções anteriores, embora a aplicabilidade dependa do estado e dos requisitos do sistema.
Como saber qual pacote está instalado?
Use:
DISM /Online /Get-Packages
e correlacione a saída com os registros e a atualização investigada.
Get-HotFix mostra todas as atualizações?
Não use Get-HotFix como fonte única para determinar todo o estado de servicing do Windows.
Ele pode ser uma informação complementar.
Devo limpar SoftwareDistribution?
Somente quando o comportamento e as evidências justificarem testar a camada de cache/estado local do Windows Update.
Posso apagar SoftwareDistribution?
Neste diagnóstico, é preferível interromper os serviços necessários e renomear a pasta de maneira controlada em vez de começar eliminando evidências.
Devo limpar catroot2?
Não automaticamente.
Ela pode entrar em determinados diagnósticos, mas uma KB repetida não prova problema nessa estrutura.
Posso apagar catroot?
Não confunda catroot com catroot2.
Não modifique estruturas protegidas apenas por semelhança de nomes.
DISM pode corrigir uma atualização que fica voltando?
Pode ajudar quando existe problema de integridade no Component Store.
Se o Component Store está saudável, repetir RestoreHealth indefinidamente não é uma estratégia útil.
SFC pode resolver?
SFC verifica arquivos protegidos do Windows e pode ser útil quando existe corrupção nessa camada.
Ele não é uma solução universal para problemas de detecção do Windows Update.
O que é CBS.log?
É um registro importante do Component-Based Servicing.
Ele pode ajudar a investigar o que ocorreu durante a aplicação de componentes e pacotes.
Onde fica CBS.log?
Normalmente:
C:\Windows\Logs\CBS\CBS.log
Como gerar WindowsUpdate.log?
No PowerShell:
Get-WindowsUpdateLog
Qual log é mais importante?
Depende da pergunta.
Para nova detecção e fluxo do Windows Update, WindowsUpdate.log pode ser útil.
Para servicing e aplicação de componentes, CBS.log ganha importância.
Posso instalar a KB manualmente?
Quando existe pacote adequado disponível, a instalação manual pode ser utilizada como ferramenta de diagnóstico.
Confira versão e arquitetura.
E se o pacote disser que não se aplica ao computador?
Não tente forçar imediatamente.
Confirme:
- versão;
- build;
- arquitetura;
- existência de atualização posterior;
- aplicabilidade.
Uma atualização cumulativa nova pode resolver?
Uma atualização cumulativa posterior aplicável pode levar o sistema a um estado mais recente e substituir conteúdo anterior.
Depois, confirme build e comportamento do Windows Update.
A KB volta porque o Windows Update está corrompido?
Não necessariamente.
Precisamos descobrir se existe:
- falha de conclusão;
- rollback;
- problema de integridade;
- cache inconsistente;
- detecção;
- diferença de aplicabilidade.
Uma atualização repetida significa SSD defeituoso?
Não.
Só investigue armazenamento como hipótese prioritária quando existirem outras evidências.
Pode ser memória RAM?
Uma atualização repetida isoladamente também não diagnostica RAM.
Instabilidade geral e corrupção recorrente seriam pistas adicionais.
Ferramentas de debloat podem interferir?
Ferramentas que alteram serviços, políticas e componentes do Windows Update merecem investigação quando existe relação temporal entre as modificações e o início do problema.
Preciso formatar o Windows?
Não necessariamente.
Antes disso, podemos investigar logs, pacotes, integridade, aplicabilidade e, quando apropriado, realizar uma reparação in-place.
O que é reparação in-place?
É uma reinstalação de reparo do Windows iniciada sobre a instalação existente.
Quando a mídia e o sistema são compatíveis, o Setup pode oferecer preservação de arquivos pessoais e aplicativos.
Como confirmar definitivamente que o loop acabou?
Reproduza o cenário original.
Se a KB reaparecia depois de instalar e reiniciar:
- instale a atualização;
- reinicie;
- confira
winver; - consulte o Histórico;
- execute nova verificação do Windows Update;
- confirme que a mesma situação não volta a ocorrer.
Conclusão: talvez o Windows não esteja instalando exatamente a mesma atualização duas vezes
Quando o Windows Update mostra a mesma KB repetidamente, é tentador concluir:
“o Windows esqueceu que já instalou”.
Essa explicação pode ser simples demais.
O Windows Update trabalha com:
- detecção;
- aplicabilidade;
- pacotes;
- componentes;
- servicing;
- estados;
- atualizações cumulativas;
- reinicializações;
- substituição de conteúdo.
Por isso, precisamos descobrir o que realmente ocorreu entre uma oferta e outra.
Comece com:
winver
Identifique:
KBxxxxxxx
Registre o horário.
Consulte:
WindowsUpdate.log
Depois:
CBS.log
Verifique os pacotes com:
DISM /Online /Get-Packages
Analise a integridade com DISM quando houver motivo.
Use SFC quando apropriado.
Reconstrua SoftwareDistribution apenas quando a hipótese justificar.
Investigue catroot2 somente quando existir contexto.
E sempre verifique se uma atualização cumulativa posterior já mudou o estado do sistema.
A pergunta mais importante não é:
“como impedir essa KB de aparecer?”
É:
“por que o Windows ainda considera esse conteúdo aplicável?”
Quando encontramos essa resposta, deixamos de esconder o sintoma e começamos a corrigir a causa.
VMIA — Diagnóstico de Windows Update em São Paulo
Quando o Windows 11 instala uma atualização e ela continua reaparecendo, a VMIA – Manutenção e Configuração pode realizar um diagnóstico técnico do Windows Update.
A análise pode incluir:
- Histórico de Atualizações;
- identificação da KB;
- versão e build do Windows;
- WindowsUpdate.log;
- CBS.log;
- pacotes do Windows;
- DISM;
- SFC;
- Component Store;
- SoftwareDistribution;
- serviços do Windows Update;
- problemas de reinicialização;
- rollback;
- integridade do sistema;
- armazenamento quando houver evidências.
O objetivo é descobrir por que a atualização continua sendo oferecida antes de recorrer a procedimentos mais invasivos.
VMIA – Manutenção e Configuração
Rua Prof. Sud Menucci, 291
Vila Mariana – São Paulo – SP
CEP 04017-080
Telefone/WhatsApp: (11) 99779-7772
E-mail: suporte@vmia.com.br
Site: https://vmia.site
Blog: https://vmia.com.br
Atendimento mediante agendamento, com possibilidade de suporte presencial ou remoto conforme o problema.
Antes de bloquear uma atualização ou formatar o computador, descubra se a mesma KB realmente está sendo reinstalada ou se o Windows continua encontrando conteúdo aplicável por causa do estado do sistema.
Faça um comentário