O Windows Update encontra uma atualização cumulativa para o Windows 11.
O download chega a 100%.
A instalação também parece avançar normalmente.
Então o Windows solicita uma reinicialização.
Até aqui, tudo parece normal.
Durante a inicialização aparecem mensagens indicando que as atualizações estão sendo processadas. O computador pode reiniciar mais de uma vez e continuar trabalhando durante alguns minutos.
De repente, aparece uma mensagem informando que alguma coisa não ocorreu como esperado.
O Windows começa a desfazer as alterações.
Depois de mais uma reinicialização, o computador volta à Área de Trabalho aparentemente exatamente como estava antes.
Você abre novamente o Windows Update e encontra a atualização marcada como falha.
O que aconteceu?
O Windows conseguiu baixar o pacote.
Conseguiu iniciar sua instalação.
Talvez tenha conseguido completar boa parte do processo.
Mas alguma etapa necessária para confirmar a atualização falhou.
Para evitar deixar o sistema em um estado inconsistente, o mecanismo de servicing tentou retornar ao estado anterior.
Esse processo é conhecido como rollback.
O problema é que a mensagem apresentada na tela normalmente não explica qual componente provocou a reversão.
É justamente isso que vamos investigar neste guia.
O que significa rollback no Windows 11?
Em informática, rollback significa retornar de um estado novo para um estado anterior considerado válido.
No contexto do Windows Update, podemos pensar em uma sequência simplificada:
Estado A
Windows funcionando antes da atualização.
↓
O Windows começa a instalar novos componentes.
↓
Estado B
Sistema parcialmente atualizado.
↓
Uma operação crítica falha.
↓
O Windows não consegue confirmar o novo estado.
↓
Rollback
O sistema tenta desfazer as alterações.
↓
Retorno ao:
Estado A
Essa capacidade é extremamente importante.
Sem um mecanismo de reversão, uma falha durante uma atualização poderia deixar o computador em um estado intermediário no qual parte dos componentes pertence à versão antiga e outra parte à nova.
Rollback não significa simplesmente “desinstalar a atualização”
Existe uma diferença importante.
Quando você remove manualmente uma atualização já instalada, o Windows está executando uma operação de desinstalação sobre um pacote que anteriormente conseguiu concluir seu processo de instalação.
No rollback, a situação pode ser diferente.
A atualização pode nunca ter atingido um estado final válido.
O Windows estava tentando instalá-la, encontrou uma condição que impediu a conclusão e começou a reverter as operações já realizadas.
Portanto:
rollback não é necessariamente igual a desinstalação.
Por que a atualização parece instalar antes de ser desfeita?
Porque Windows Update não é uma única operação.
Quando vemos uma barra de progresso, estamos observando apenas uma representação simplificada de várias etapas internas.
Uma atualização pode envolver:
- detecção;
- download;
- validação;
- preparação;
- staging;
- servicing;
- substituição de componentes;
- configuração;
- operações offline;
- reinicialização;
- confirmação do novo estado.
Uma falha em qualquer etapa crítica pode impedir a conclusão.
Isso explica um comportamento aparentemente contraditório:
“Chegou a 100%, mas depois voltou atrás.”
O percentual que apareceu anteriormente não significa necessariamente que todas as etapas posteriores já terminaram.
Download concluído não significa atualização instalada
Esse é um dos erros de interpretação mais comuns.
Imagine:
Download: 100%
Isso pode significar apenas que o pacote necessário foi transferido.
Ainda falta aplicar seu conteúdo ao Windows.
Depois podemos ter:
Instalação: 100%
Mesmo assim, determinadas operações ainda podem precisar ser concluídas durante a reinicialização.
Portanto, existem pelo menos três conceitos diferentes:
baixado
preparado/aplicado
confirmado
Uma atualização só deve ser considerada realmente concluída depois que o Windows consegue finalizar todo o processo necessário.
Por que algumas alterações precisam acontecer durante a reinicialização?
O Windows utiliza constantemente arquivos e componentes importantes.
Enquanto o sistema está funcionando, determinados elementos não podem simplesmente ser substituídos.
Por isso, algumas operações são preparadas enquanto você ainda está usando o computador e concluídas posteriormente durante a reinicialização.
É nesse momento que o Windows pode trabalhar com componentes que normalmente estariam em uso.
Isso explica por que algumas atualizações:
- pedem reinicialização;
- mostram porcentagem antes do login;
- reiniciam mais de uma vez;
- demoram mais durante a inicialização.
Essa fase também pode revelar problemas que não apareceram durante o download.
A atualização falhou antes ou depois da reinicialização?
Essa é uma das primeiras perguntas que devemos fazer.
Considere dois computadores.
Computador A
Windows Update baixa a atualização.
A instalação chega a determinada porcentagem.
O erro aparece ainda dentro das Configurações.
Nenhuma reinicialização ocorre.
Computador B
Windows Update baixa a atualização.
A instalação avança.
O Windows solicita reinicialização.
Durante o boot, alguma coisa falha.
As alterações são desfeitas.
Os dois computadores possuem:
“problema no Windows Update”.
Mas os pontos de falha são diferentes.
No segundo caso, precisamos dar atenção especial às operações realizadas durante a transição e aos registros criados nesse período.
Anote exatamente o que aparece na tela
Se o problema acontece repetidamente, registre a mensagem.
Ela pode ser semelhante a:
Desfazendo alterações feitas no computador
ou outra mensagem de falha durante o processamento das atualizações.
Não dependa apenas da memória.
Se for possível fazer isso com segurança, anote:
- texto da mensagem;
- porcentagem aproximada;
- horário;
- número de reinicializações;
- tempo gasto antes da reversão.
Esses detalhes ajudam posteriormente a correlacionar o comportamento com os logs.
Descubra qual KB está provocando o rollback
Depois que o Windows conseguir iniciar novamente, abra:
Configurações → Windows Update → Histórico de atualizações
Procure as atualizações recentes.
Identifique a atualização que falhou.
Normalmente teremos um identificador semelhante a:
KBxxxxxxx
Anote o número completo.
Esse é um dos dados mais importantes de todo o diagnóstico.
Pare de diagnosticar “o Windows Update”
Depois que identificamos a KB, podemos formular uma pergunta muito melhor.
Em vez de:
“Por que o Windows Update não funciona?”
podemos perguntar:
“Por que a KBxxxxxxx é revertida durante a reinicialização neste computador?”
A segunda pergunta é muito mais específica.
Ela permite comparar:
- histórico;
- logs;
- requisitos;
- componentes;
- momento da falha.
Esse é o começo de um diagnóstico real.
Verifique se somente aquela KB falha
Depois do rollback, observe o comportamento das outras atualizações.
O Windows consegue instalar:
- atualização do Microsoft Defender?
- drivers?
- outras atualizações?
- atualizações de componentes?
Se várias categorias continuam funcionando e somente uma atualização cumulativa falha, isso é uma pista importante.
Não estamos necessariamente diante de um Windows Update completamente quebrado.
Podemos estar diante de uma falha específica durante o servicing daquela atualização.
E se todas as atualizações estiverem falhando?
Agora o cenário muda.
Quando diversas atualizações diferentes falham, podemos ampliar a investigação para:
- integridade do sistema;
- Component Store;
- serviços;
- cache;
- operações pendentes;
- políticas;
- armazenamento;
- problemas gerais de servicing.
A quantidade e o tipo das atualizações afetadas ajudam a determinar a abrangência do problema.
Identifique a versão atual do Windows
Pressione:
Windows + R
Digite:
winver
Anote:
- versão;
- compilação do sistema operacional.
Depois abra o Terminal como administrador e execute:
DISM /Online /Get-CurrentEdition
Isso identifica a edição instalada.
Esses dados ajudam a entender exatamente qual Windows estamos analisando.
O histórico mostra falha, mas qual foi o código?
O Histórico de Atualizações pode mostrar que a instalação falhou.
Dependendo do cenário, também podemos encontrar um código.
Por exemplo:
0x........
Anote o código completo.
Não pesquise apenas:
“Windows Update desfez alterações”.
Pesquise o comportamento junto ao código e à KB.
Isso reduz enormemente o universo de possibilidades.
O código final nem sempre conta toda a história
Imagine esta sequência:
- atualização começa;
- determinado componente falha;
- Windows tenta continuar;
- outra operação detecta estado inválido;
- rollback começa;
- interface apresenta um código final.
O código exibido pode representar o resultado final da sequência, mas a causa original pode ter sido registrada anteriormente.
Por isso, precisamos consultar logs.
Quais logs são importantes em um rollback?
Dependendo da etapa em que a atualização falhou, vários registros podem ajudar.
Neste artigo vamos trabalhar principalmente com:
CBS.log
C:\Windows\Logs\CBS\CBS.log
DISM.log
C:\Windows\Logs\DISM\dism.log
quando executarmos operações do DISM.
WindowsUpdate.log
que pode ser gerado através do PowerShell com:
Get-WindowsUpdateLog
Além disso, o Windows mantém outros registros relacionados a instalação, setup e servicing que podem se tornar relevantes conforme descobrirmos em qual fase ocorreu a reversão.
Por que o CBS.log é importante?
CBS significa:
Component-Based Servicing.
Atualizações cumulativas precisam trabalhar com os componentes existentes no Windows.
O CBS.log registra grande quantidade de informações relacionadas a essas operações.
Quando uma atualização é revertida, podemos encontrar pistas sobre:
- pacotes;
- componentes;
- operações;
- estados;
- erros;
- falhas anteriores ao rollback.
O arquivo pode parecer assustador porque contém muitas linhas.
A solução é não tentar lê-lo inteiro.
Use o horário para navegar no CBS.log
Imagine que o computador começou a atualizar às:
19:10
A falha apareceu aproximadamente:
19:18
O Windows voltou à Área de Trabalho:
19:25
Agora temos uma janela temporal.
Abra:
C:\Windows\Logs\CBS\CBS.log
e concentre a análise nos registros próximos daquele período.
Isso é muito mais eficiente do que procurar aleatoriamente pela palavra:
error
em milhares de linhas.
Procure também pelo código
Se o Windows mostrou um código específico, pesquise esse código no log.
Depois examine algumas linhas anteriores e posteriores.
Procure referências a:
- falha;
- pacote;
- componente;
- servicing;
- corrupção;
- operação pendente.
Mas não interprete automaticamente qualquer linha contendo “error” como causa.
Logs podem registrar falhas secundárias.
Nosso objetivo é reconstruir a sequência.
Gere o WindowsUpdate.log
Abra o PowerShell.
Execute:
Get-WindowsUpdateLog
O Windows processará os rastreamentos disponíveis e produzirá um arquivo legível chamado:
WindowsUpdate.log
Agora podemos procurar:
- número da KB;
- código;
- horário;
- falhas próximas ao momento da instalação.
Esse log ajuda a observar a atualização por outra perspectiva.
WindowsUpdate.log e CBS.log não são concorrentes
Não precisamos escolher apenas um.
Eles podem complementar um ao outro.
Podemos pensar de maneira simplificada:
WindowsUpdate.log
ajuda a entender o fluxo do Windows Update.
CBS.log
ajuda a entender operações do servicing baseado em componentes.
Quando uma atualização passa pelo Windows Update e posteriormente falha durante a aplicação de componentes, correlacionar os dois registros pode revelar muito mais do que analisar somente a interface.
O Visualizador de Eventos também pode ajudar
Abra:
Visualizador de Eventos
Existem registros relacionados ao sistema e ao Windows Update que podem ajudar a estabelecer:
- horário da falha;
- reinicializações;
- erros de serviço;
- eventos relacionados à instalação.
Não use um único evento isolado como prova absoluta da causa.
Procure correlação.
Se CBS.log, WindowsUpdate.log e eventos apontam para o mesmo período e para a mesma operação, a evidência fica muito mais forte.
A porcentagem onde o rollback começa importa?
Pode ajudar, mas não deve ser interpretada literalmente.
Se o computador sempre falha aproximadamente no mesmo ponto, existe um padrão.
Por exemplo:
tentativa 1 → falha próxima do mesmo estágio;
tentativa 2 → falha novamente;
tentativa 3 → comportamento praticamente idêntico.
Isso sugere uma falha reproduzível.
Mas não conclua:
“Falha em 75%, portanto o componente X está quebrado.”
A porcentagem apresentada ao usuário não fornece esse nível de precisão.
Crie um registro simples das tentativas
Uma pequena tabela pode ajudar muito:
| Tentativa | KB | Momento | Resultado |
|---|---|---|---|
| 1 | KBxxxxxxx | Após reiniciar | Rollback |
| 2 | KBxxxxxxx | Após reiniciar | Rollback |
| 3 | KBxxxxxxx | Após reparação | A verificar |
Acrescente também códigos quando existirem.
Essa abordagem evita executar o mesmo procedimento repetidamente sem perceber.
Não limpe SoftwareDistribution imediatamente
Quando uma atualização falha, um dos procedimentos mais populares da Internet é apagar ou renomear:
C:\Windows\SoftwareDistribution
Esse procedimento pode ser útil em determinados problemas do cache do Windows Update.
Mas pense no cenário deste artigo.
A atualização:
- foi encontrada;
- foi baixada;
- começou a instalar;
- chegou à reinicialização;
- somente então foi revertida.
Isso já nos mostra que o processo avançou bastante.
Não podemos presumir que o cache de download seja a causa.
Baixar novamente pode produzir exatamente o mesmo rollback
Se o pacote está correto, mas o Windows não consegue integrá-lo por causa de um problema no sistema, baixar outra cópia do mesmo pacote não corrige a causa.
A sequência será:
download novo;
instalação;
mesma etapa problemática;
mesma falha;
novo rollback.
Por isso, limpar o cache sem evidência pode apenas fazer o computador baixar novamente vários arquivos.
Também não execute DISM automaticamente
DISM é extremamente útil.
Mas primeiro precisamos descobrir se existe indicação de problema no armazenamento de componentes.
Comece com:
DISM /Online /Cleanup-Image /CheckHealth
Depois, quando necessário:
DISM /Online /Cleanup-Image /ScanHealth
Leia os resultados.
Se existir corrupção reparável, aí:
DISM /Online /Cleanup-Image /RestoreHealth
passa a ter uma justificativa clara.
O que o ScanHealth pode revelar?
O comando:
DISM /Online /Cleanup-Image /ScanHealth
faz uma análise mais profunda da imagem.
Se encontrar problemas, isso cria uma ligação importante entre:
rollback da atualização
e:
integridade do Component Store.
Não significa automaticamente que encontramos toda a causa, mas agora temos evidência concreta de uma camada que precisa ser reparada.
E se o ScanHealth disser que não existe corrupção?
Ótimo.
Esse resultado também é informação.
Agora podemos reduzir a prioridade de determinadas hipóteses e investigar:
- KB específica;
- drivers;
- operações pendentes;
- espaço reservado ao sistema;
- software incompatível;
- falha durante boot;
- serviços;
- registros da atualização.
Diagnóstico também significa eliminar possibilidades.
Execute SFC quando fizer sentido
Podemos verificar arquivos protegidos com:
sfc /scannow
Se o SFC encontrar corrupção e conseguir repará-la, reinicie quando apropriado e teste novamente a atualização.
Se encontrar arquivos que não consegue reparar, consulte as entradas correspondentes no CBS.log.
Mais uma vez:
resultado → interpretação → próxima ação.
Não execute SFC dez vezes esperando um resultado diferente sem investigar por que ele falhou.
Um driver pode provocar rollback?
Dependendo da atualização e do cenário, problemas de compatibilidade ou de inicialização envolvendo drivers podem participar de uma falha.
Por isso, quando o Component Store aparece saudável, vale observar:
- drivers instalados recentemente;
- dispositivos problemáticos;
- erros durante boot;
- eventos relacionados ao hardware.
Mas não comece atualizando todos os drivers indiscriminadamente.
Uma alteração em massa pode criar novas variáveis.
E o espaço em disco?
Atualizações precisam de espaço para:
- download;
- preparação;
- arquivos temporários;
- staging;
- operações de servicing;
- capacidade de reversão.
Um disco extremamente cheio pode causar problemas.
Verifique o espaço livre da unidade do Windows.
Mas novamente:
pouco espaço é uma hipótese que precisa ser confirmada, não uma explicação automática para todo rollback.
Existe também uma partição de sistema
Nem todo espaço necessário está necessariamente relacionado apenas ao espaço livre mostrado em:
C:
Dependendo do tipo de atualização e do que ela precisa modificar, outras estruturas do sistema podem entrar na equação.
Esse detalhe se torna particularmente importante quando determinados códigos de erro aparecem.
Por isso, anotar o código é essencial.
Atualização cumulativa merece atenção especial
As atualizações cumulativas modificam partes importantes do Windows e incorporam correções anteriores.
Quando uma cumulativa específica entra em rollback repetidamente, precisamos investigar:
- KB;
- build atual;
- Component Store;
- logs;
- estado dos pacotes;
- operações pendentes.
É um cenário muito mais específico do que simplesmente:
“Windows Update não funciona”.
O Windows pode tentar a mesma atualização novamente?
Sim.
Se a atualização continua aplicável e a instalação anterior não foi concluída, o Windows Update pode oferecê-la novamente.
O usuário então entra em um ciclo:
baixar;
instalar;
reiniciar;
falhar;
rollback;
Windows inicia;
Windows Update oferece novamente.
Esse ciclo pode continuar até que a causa seja corrigida ou que o estado da atualização mude.
Não esconda a atualização apenas para eliminar o sintoma
Evitar uma atualização problemática pode ser útil temporariamente em determinados cenários, principalmente quando existe um problema conhecido sendo investigado.
Mas esconder permanentemente uma atualização sem entender a situação pode deixar o sistema sem correções importantes.
Primeiro descubra:
por que ela está falhando neste computador?
Rollback é um mecanismo de proteção
É fácil enxergar o rollback como outro problema.
Na verdade, muitas vezes ele é justamente o mecanismo que impede um problema maior.
O Windows detectou que não conseguiu concluir corretamente uma transição e tentou retornar a um estado anterior.
O problema real é aquilo que tornou a transição impossível.
Portanto:
não investigue apenas o rollback.
Investigue o evento que obrigou o Windows a realizá-lo.
Como descobrir o erro que aconteceu antes do rollback do Windows Update
Quando o Windows 11 mostra uma mensagem indicando que está desfazendo alterações, o rollback já começou.
Isso significa que a decisão de abandonar a atualização provavelmente aconteceu antes daquela mensagem aparecer.
Portanto, nosso objetivo não é simplesmente descobrir:
“Por que o Windows está desfazendo alterações?”
A pergunta mais útil é:
“Qual foi a primeira operação importante que falhou antes de o Windows decidir desfazer as alterações?”
Essa mudança de perspectiva transforma completamente o diagnóstico.
Pense no rollback como consequência
Podemos representar o processo assim:
Atualização inicia
↓
Pacotes são preparados
↓
Componentes começam a ser atualizados
↓
Operações pendentes são programadas
↓
Windows reinicia
↓
Alguma etapa crítica falha
↓
Windows determina que não pode concluir a atualização
↓
Rollback começa
↓
“Desfazendo alterações”
Portanto, quando vemos a última mensagem, talvez estejamos olhando para o final da história.
Precisamos voltar algumas páginas.
Primeiro registre uma nova tentativa
Se o problema acontece repetidamente, escolha uma tentativa para diagnóstico.
Antes de clicar em reiniciar, anote:
- data;
- horário;
- KB;
- build atual;
- código de erro conhecido.
Exemplo:
18/09 — 20:12
KBxxxxxxx
Windows 11 build xxxxx
Reinicialização iniciada às 20:15
Depois deixe o Windows completar o processo.
Se ocorrer rollback, anote aproximadamente:
hora em que a falha apareceu
e:
hora em que voltou à Área de Trabalho.
Agora temos uma janela temporal para procurar nos registros.
Comece pelo Histórico de Atualizações
Abra:
Configurações → Windows Update → Histórico de atualizações
Localize a KB.
Observe se aparece:
- instalada;
- falhou;
- aguardando reinicialização;
- outro estado.
Se houver código de erro, registre-o exatamente.
Um único caractere errado pode levar a uma investigação completamente diferente.
Não confie somente no Histórico de Atualizações
A interface foi projetada para usuários, não para análise profunda de servicing.
Ela pode dizer:
Falha na instalação
mas não necessariamente mostrar:
- qual componente falhou;
- qual pacote estava sendo processado;
- qual operação iniciou a reversão;
- qual arquivo estava envolvido.
Para isso precisamos dos registros.
CBS.log: uma das principais fontes para investigar rollback
Abra:
C:\Windows\Logs\CBS\CBS.log
CBS significa:
Component-Based Servicing.
Esse mecanismo participa da manutenção dos componentes do Windows.
Uma atualização cumulativa pode gerar muitas entradas nesse arquivo.
Por isso, não tente lê-lo do início ao fim.
Use o horário da falha.
Como procurar no CBS.log
Comece pela janela de tempo que anotamos.
Depois procure:
- código de erro;
- KB;
error;failed;corrupt;package;rollback.
Mas não considere automaticamente a primeira ocorrência da palavra “error” como causa.
Precisamos observar a sequência.
Procure a primeira falha relevante
Imagine um trecho conceitual:
20:18:31 operação iniciada
20:18:33 pacote processado
20:18:36 componente processado
20:18:38 operação falhou
20:18:39 servicing interrompido
20:18:42 rollback solicitado
Nesse exemplo, a linha das:
20:18:38
merece muito mais atenção do que a linha dizendo:
rollback solicitado
O rollback é consequência.
A falha anterior é a pista.
Cuidado com erros secundários
Quando uma operação principal falha, várias outras podem falhar depois.
Por exemplo:
componente A falha;
pacote não pode ser concluído;
operação dependente B falha;
servicing encerra;
rollback começa.
Se começarmos pela última mensagem, podemos investigar B quando o problema original estava em A.
Por isso, tente reconstruir a ordem cronológica.
O nome de um pacote pode aparecer no CBS.log
Durante a análise, podemos encontrar identificadores relacionados a pacotes.
Eles podem parecer complexos e conter:
- versão;
- arquitetura;
- identificadores;
- informações de linguagem;
- nomes internos.
Não tente modificar o pacote imediatamente.
Primeiro registre o nome.
Depois descubra:
qual função ele possui?
e:
por que estava sendo processado naquele momento?
DISM pode ajudar a consultar pacotes
Abra o Terminal como administrador e execute:
DISM /Online /Get-Packages
O resultado pode ser grande.
Ele mostra pacotes conhecidos pelo sistema e seus respectivos estados.
Isso pode ajudar a relacionar uma referência encontrada no CBS.log com o estado atual do Windows.
Estados de pacote precisam ser interpretados
Durante uma investigação podemos encontrar diferentes estados.
Não conclua que qualquer estado que pareça diferente de “Installed” significa corrupção.
O servicing trabalha com vários estados durante:
- instalação;
- preparação;
- substituição;
- remoção;
- reinicialização.
O contexto é fundamental.
Pacote pendente merece atenção
Atualizações podem preparar operações que somente serão concluídas durante a reinicialização.
Isso significa que determinados componentes podem ficar aguardando uma fase posterior.
Se alguma coisa impede essa conclusão, o Windows pode não conseguir confirmar o novo estado.
É justamente aí que um rollback pode acontecer.
Reinicialização pendente é importante
Antes de iniciar novas reparações, verifique se o Windows ainda possui operações aguardando reinicialização.
Isso pode acontecer depois de:
- Windows Update;
- instalação de drivers;
- recursos opcionais;
- programas;
- servicing.
Se existe uma reinicialização legitimamente pendente, permitir que o Windows a processe pode ser necessário antes de iniciar outra alteração importante.
Não force várias atualizações ao mesmo tempo
Imagine um computador que já possui:
- atualização cumulativa pendente;
- driver aguardando reinicialização;
- recurso opcional sendo modificado;
- programa solicitando reboot.
Adicionar várias intervenções enquanto o sistema está nesse estado aumenta a complexidade do diagnóstico.
Quando possível, estabilize uma operação antes de iniciar outra.
WindowsUpdate.log: observe o processo por outra camada
Abra o PowerShell.
Execute:
Get-WindowsUpdateLog
O Windows processará os rastreamentos e produzirá um:
WindowsUpdate.log
Agora procure:
- KB;
- código;
- horário;
- eventos imediatamente anteriores à falha.
Esse log pode mostrar detalhes relacionados ao fluxo do Windows Update que não aparecem diretamente no CBS.log.
Correlacione WindowsUpdate.log e CBS.log
Suponha que WindowsUpdate.log indique uma falha aproximadamente às:
20:18
Abra CBS.log.
Procure o mesmo intervalo.
Se ambos registram problemas relacionados ao mesmo processo naquele momento, temos uma correlação muito mais útil.
Não estamos mais tentando adivinhar.
Estamos reconstruindo o evento.
Visualizador de Eventos: terceira fonte de evidência
Abra:
Visualizador de Eventos
Podemos começar verificando registros do Windows relacionados ao sistema e ao Windows Update.
O objetivo é localizar eventos no mesmo intervalo temporal.
Procure:
- falhas;
- reinicializações;
- problemas de serviços;
- eventos de atualização;
- erros de inicialização.
Mais uma vez:
um evento isolado não é diagnóstico.
O valor aumenta quando várias fontes apontam para a mesma sequência.
Existe um log específico do Windows Update no Visualizador de Eventos
No Visualizador de Eventos, expanda:
Logs de Aplicativos e Serviços
Depois navegue pelas categorias relacionadas ao Windows.
Podemos encontrar registros específicos do Windows Update.
Esses eventos podem ajudar a confirmar:
- detecção;
- instalação;
- falha;
- código;
- horário.
Eles são especialmente úteis para estabelecer uma linha do tempo.
Crie uma linha do tempo
Depois de reunir os registros, monte algo assim:
20:12 — Windows Update inicia instalação.
20:15 — Windows solicita reinicialização.
20:17 — servicing continua durante boot.
20:18 — primeira falha relevante.
20:19 — instalação é interrompida.
20:20 — rollback começa.
20:27 — Windows inicia novamente.
Essa linha do tempo pode revelar exatamente onde devemos concentrar a investigação.
Falha online e falha offline não são iguais
Parte do processo de atualização ocorre enquanto o Windows está completamente iniciado.
Podemos chamar isso, de forma simplificada, de fase:
online.
Outras operações precisam acontecer durante reinicialização, quando determinados componentes não estão sendo utilizados normalmente.
Podemos pensar nessa etapa como uma fase:
offline.
Se a atualização sempre falha somente depois da reinicialização, isso direciona nossa atenção para operações que dependem dessa fase.
Por que essa distinção importa?
Imagine dois casos.
Caso 1
A atualização falha em Configurações antes de solicitar reinicialização.
Caso 2
A atualização chega ao estado “Reinicialização necessária”, mas falha durante o boot.
No Caso 2, já sabemos que várias etapas anteriores foram concluídas.
Isso reduz o número de hipóteses.
Drivers podem entrar na fase crítica
Determinadas atualizações podem interagir com componentes utilizados durante inicialização.
Se existe um driver incompatível, antigo ou problemático, ele pode contribuir para falhas em determinados cenários.
Procure no Visualizador de Eventos sinais de problemas envolvendo dispositivos ou drivers no mesmo período.
Mas não atualize todos os drivers do computador como primeira reação.
Isso destrói nosso controle sobre as variáveis.
Use o Gerenciador de Dispositivos como pista, não como prova absoluta
Abra:
Gerenciador de Dispositivos
Observe se existem:
- dispositivos desconhecidos;
- alertas;
- hardware com erro.
Um Gerenciador de Dispositivos aparentemente normal não garante que todos os drivers estejam perfeitos.
Mas um dispositivo claramente problemático pode fornecer uma pista.
PnPUtil pode ajudar a identificar drivers instalados
Para uma investigação mais técnica, podemos consultar os pacotes de drivers.
Abra o Terminal como administrador e execute:
pnputil /enum-drivers
O comando lista drivers de terceiros presentes no Driver Store.
Isso pode ajudar a descobrir:
- fornecedor;
- nome publicado;
- versão;
- data;
- classe.
Não remova drivers simplesmente porque são antigos.
Primeiro determine se existe relação com a falha.
Atualização começou a falhar depois de instalar um driver?
Essa informação é valiosa.
Pergunte:
o rollback começou depois de alguma mudança?
Por exemplo:
- novo driver;
- nova placa;
- novo antivírus;
- atualização de BIOS/UEFI;
- software de virtualização;
- ferramenta de segurança;
- utilitário de hardware.
Correlação temporal não prova causalidade, mas ajuda a priorizar hipóteses.
Espaço em C: ainda precisa ser verificado
Abra o Explorador de Arquivos.
Observe o espaço livre da unidade do Windows.
Atualizações precisam de espaço temporário para realizar diversas operações.
Se a unidade está praticamente cheia, libere espaço de maneira segura antes de continuar.
Evite ferramentas agressivas que apagam arquivos do sistema indiscriminadamente.
Mas C: não é a única partição importante
Em instalações modernas do Windows podem existir pequenas partições que o usuário normalmente não vê no Explorador.
Entre elas podem estar estruturas relacionadas a:
- inicialização;
- recuperação;
- sistema EFI.
Dependendo do tipo de atualização e do código apresentado, o espaço disponível em determinadas partições pode ser relevante.
Isso é especialmente importante em alguns erros específicos do Windows Update.
Como visualizar as partições sem alterá-las
Pressione:
Windows + X
Abra:
Gerenciamento de Disco
Observe a estrutura.
Não exclua.
Não formate.
Não redimensione ainda.
Nosso objetivo neste momento é apenas identificar:
- disco;
- partições;
- tamanhos;
- tipo de instalação.
Alterar partições de sistema sem necessidade pode impedir o Windows de iniciar.
PowerShell também pode mostrar partições
Podemos utilizar:
Get-Partition
e:
Get-Volume
Esses comandos ajudam a visualizar a estrutura de armazenamento.
Novamente, estamos apenas coletando informações.
Não altere a partição porque ela parece pequena.
Partições de sistema são naturalmente muito menores que C:.
E a partição EFI?
Em computadores modernos com UEFI, existe normalmente uma EFI System Partition, frequentemente chamada de ESP.
Ela armazena elementos utilizados no processo de inicialização.
Algumas operações do Windows podem precisar modificar estruturas relacionadas ao boot.
Problemas envolvendo espaço ou estrutura dessa partição podem aparecer em determinados cenários de atualização.
Mas:
rollback não significa automaticamente que a EFI está cheia.
Precisamos do código e dos logs.
Erro 0x800f0922 merece atenção especial
Se o rollback vier acompanhado de:
0x800f0922
o diagnóstico merece um artigo próprio.
Esse código pode aparecer em cenários diferentes, e reduzi-lo simplesmente a:
“partição EFI cheia”
é uma simplificação perigosa.
No cluster atual, esse será um excelente artigo futuro.
Verifique o Component Store
Se os registros apontam para servicing, execute:
DISM /Online /Cleanup-Image /CheckHealth
Depois:
DISM /Online /Cleanup-Image /ScanHealth
Leia o resultado.
Se houver corrupção reparável:
DISM /Online /Cleanup-Image /RestoreHealth
Depois:
sfc /scannow
Reinicie quando apropriado e teste novamente a KB.
Se RestoreHealth falhar, o erro mudou?
Anote o código.
Esse detalhe é fundamental.
O Windows Update pode ter apresentado um erro.
DISM pode apresentar outro.
Por exemplo, durante a tentativa de reparação podemos descobrir problemas relacionados a:
- fonte de reparação;
- Component Store;
- componentes específicos.
Agora temos uma nova pista.
Não misture códigos diferentes
Se Windows Update mostra:
Código A
e DISM mostra:
Código B
não escreva em suas anotações apenas:
“erro do Windows Update”.
Registre:
Windows Update → Código A
DISM → Código B
Os dois podem estar relacionados, mas representam operações diferentes.
O CBS.log também registra informações do SFC
Depois de:
sfc /scannow
podemos extrair entradas relacionadas ao SFC:
findstr /c:"[SR]" %windir%\Logs\CBS\CBS.log > "%userprofile%\Desktop\sfcdetails.txt"
Isso cria:
sfcdetails.txt
na Área de Trabalho.
Observe datas e horários porque o arquivo pode conter informações de diferentes execuções.
Encontrou uma DLL? Não baixe da Internet
Esse erro continua aparecendo em diagnósticos domésticos.
O usuário encontra:
arquivo.dll
no CBS.log.
Pesquisa o nome.
Baixa uma DLL de um site qualquer.
Copia para System32.
Esse procedimento pode introduzir:
- versão errada;
- arquitetura errada;
- arquivo malicioso;
- incompatibilidade;
- nova corrupção.
Se existe um problema de componente, utilize mecanismos apropriados de reparação.
O rollback acontece sempre no mesmo ponto
Isso é uma pista forte de reprodutibilidade.
Se três tentativas apresentam praticamente a mesma sequência, compare os logs das três.
Procure algo que apareça repetidamente antes do rollback.
Por exemplo:
Tentativa 1 → componente X → falha
Tentativa 2 → componente X → falha
Tentativa 3 → componente X → falha
Agora temos uma hipótese muito mais forte do que simplesmente:
“Windows Update está com problema”.
O rollback acontece em pontos diferentes
Esse comportamento pode indicar um problema menos determinístico.
Nesse caso, amplie a investigação.
Considere:
- armazenamento;
- memória;
- estabilidade;
- travamentos;
- software de segurança;
- erros de hardware;
- desligamentos inesperados.
Mas não conclua imediatamente que existe defeito físico.
Precisamos de evidências adicionais.
Verifique o Monitor de Confiabilidade
Pressione:
Windows + R
Digite:
perfmon /rel
O Monitor de Confiabilidade apresenta uma linha do tempo bastante útil.
Procure o dia do rollback.
Observe:
- falhas do Windows;
- programas que pararam;
- atualizações;
- eventos críticos.
Ele pode revelar algo que aconteceu no mesmo período.
Por que o Monitor de Confiabilidade é útil?
Porque ele organiza eventos por data de maneira visual.
Isso facilita responder:
“O que mudou no computador pouco antes de o problema começar?”
Talvez encontremos:
- driver instalado;
- programa atualizado;
- falha crítica;
- atualização anterior.
Essa informação pode orientar a análise dos logs mais técnicos.
O rollback começou depois de uma atualização anterior
Não descarte essa possibilidade.
Atualizações são cumulativas e trabalham sobre o estado atual do sistema.
Uma atualização anterior pode ter deixado:
- operação pendente;
- componente inconsistente;
- estado que interfere na atualização seguinte.
Nesse caso, o histórico completo passa a ser relevante.
Consulte pacotes antes de removê-los
Execute:
DISM /Online /Get-Packages
Se identificar um pacote relacionado à investigação, registre:
- nome;
- versão;
- estado.
Não execute comandos de remoção ainda.
Remover um pacote errado pode criar problemas maiores do que o rollback original.
Não transforme diagnóstico em tentativa e erro
A metodologia correta até aqui é:
1. Reproduzir.
2. Registrar horário.
3. Identificar KB.
4. Identificar código.
5. Encontrar a primeira falha relevante.
6. Correlacionar logs.
7. Formular uma hipótese.
8. Executar uma intervenção correspondente.
9. Testar novamente a mesma KB.
Esse processo preserva evidências.
Quando sabemos que encontramos a causa?
Imagine que os logs apontam repetidamente para determinado problema.
Aplicamos uma correção diretamente relacionada.
Depois:
- a KB instala;
- não ocorre rollback;
- Windows inicia normalmente;
- histórico mostra sucesso;
- logs não repetem a falha.
Agora temos uma relação muito mais forte entre diagnóstico e solução.
Isso é diferente de executar quinze comandos e descobrir que “alguma coisa funcionou”.
Ainda não redefina tudo
Até este ponto, podemos já ter informações suficientes para escolher entre caminhos diferentes:
Component Store com corrupção
→ reparar DISM/SFC.
Cache inconsistente
→ avaliar redefinição do Windows Update.
Problema em driver
→ investigar especificamente o driver.
Partição relacionada ao sistema
→ avaliar espaço e estrutura com cautela.
Operação pendente
→ permitir conclusão ou investigar seu estado.
KB específica
→ concentrar a análise nela.
Essa separação é justamente o que torna o diagnóstico eficiente.
Como corrigir o rollback do Windows Update sem executar comandos aleatoriamente
Nas partes anteriores fizemos algo que deveria acontecer antes de qualquer tentativa de reparação:
investigamos.
Identificamos a KB.
Registramos o horário.
Observamos se a falha acontece antes ou depois da reinicialização.
Consultamos CBS.log, WindowsUpdate.log, Visualizador de Eventos e o estado do Component Store.
Agora podemos começar a corrigir.
Mas existe uma regra:
cada procedimento precisa responder a uma hipótese.
Se suspeitamos do cache do Windows Update, trabalhamos no cache.
Se encontramos corrupção no Component Store, trabalhamos no Component Store.
Se os registros apontam para um driver, investigamos o driver.
Se existe problema em uma partição de sistema, analisamos essa partição.
Executar todas essas correções ao mesmo tempo pode até fazer o erro desaparecer, mas elimina nossa capacidade de descobrir qual era a causa.
Cenário 1 — O cache do Windows Update parece inconsistente
A pasta:
C:\Windows\SoftwareDistribution
é utilizada pelo Windows Update para armazenar informações e conteúdo relacionado às atualizações.
Em determinadas situações, recriar essa estrutura pode ajudar.
Mas lembre-se do que vimos anteriormente.
Se a atualização foi:
- baixada;
- preparada;
- enviada para reinicialização;
- processada;
- revertida;
o cache não deve ser automaticamente considerado culpado.
Use essa intervenção quando existirem sinais de problema nessa camada.
Prefira renomear antes de apagar
Em vez de excluir imediatamente:
SoftwareDistribution
podemos renomeá-la.
Primeiro abra o Terminal como administrador.
Pare os serviços necessários ao procedimento:
net stop wuauserv
net stop bits
Depois renomeie a pasta.
Por exemplo:
ren C:\Windows\SoftwareDistribution SoftwareDistribution.old
Depois reinicie os serviços:
net start bits
net start wuauserv
O Windows poderá criar novamente a estrutura necessária.
Por que renomear é melhor para diagnóstico?
Porque preservamos temporariamente o conteúdo anterior.
Se alguma informação precisar ser consultada, ainda temos:
SoftwareDistribution.old
Além disso, a ação é mais controlada do que simplesmente apagar tudo imediatamente.
Depois que o sistema estiver estável e a atualização funcionar, podemos avaliar a remoção do conteúdo antigo.
O Histórico de Atualizações pode parecer diferente
Depois de redefinir determinadas estruturas locais do Windows Update, algumas informações apresentadas pela interface podem mudar.
Não interprete isso automaticamente como:
“as atualizações foram desinstaladas”.
Existe diferença entre:
- histórico exibido;
- pacotes efetivamente instalados;
- estado atual dos componentes.
Podemos consultar pacotes com:
DISM /Online /Get-Packages
quando necessário.
Cenário 2 — Existe suspeita envolvendo Catroot2
Outro diretório frequentemente citado é:
C:\Windows\System32\catroot2
Ele participa de processos importantes relacionados às atualizações.
Quando existem evidências de problemas nessa camada, sua redefinição pode fazer parte do procedimento.
Mas não confunda:
catroot
com:
catroot2
São estruturas diferentes.
Não saia apagando ambas.
Cryptographic Services entra nessa operação
O serviço:
cryptsvc
participa de operações relacionadas a serviços criptográficos utilizados pelo Windows.
Podemos consultar seu estado:
sc query cryptsvc
Quando um procedimento de redefinição realmente exige manipular catroot2, precisamos considerar o serviço que utiliza essa estrutura.
Não tente modificar arquivos em uso à força.
Não use o “reset completo do Windows Update” como primeira opção
Existem scripts que executam dezenas de ações:
- param serviços;
- renomeiam pastas;
- apagam arquivos;
- registram bibliotecas;
- redefinem Winsock;
- modificam componentes;
- reiniciam serviços.
O problema não é apenas o risco.
O problema também é diagnóstico.
Se a atualização funcionar depois, qual era a causa?
Não sabemos.
Talvez apenas uma das vinte ações fosse necessária.
Cenário 3 — DISM encontrou corrupção
Se:
DISM /Online /Cleanup-Image /ScanHealth
indicar corrupção reparável, temos uma hipótese muito mais concreta.
Execute:
DISM /Online /Cleanup-Image /RestoreHealth
Aguarde a conclusão.
Depois execute novamente:
DISM /Online /Cleanup-Image /ScanHealth
O objetivo é confirmar o estado depois da reparação.
Execute SFC depois da reparação quando apropriado
Depois:
sfc /scannow
O SFC verifica arquivos protegidos do Windows.
Se o DISM reparou o Component Store, o SFC pode utilizar um estado mais saudável do sistema durante sua própria verificação.
Leia a mensagem final.
Não considere apenas:
“chegou a 100%”.
Reinicie e teste exatamente a mesma KB
Agora chegamos à etapa que muitos tutoriais esquecem.
Volte ao:
Windows Update
e tente novamente:
KBxxxxxxx
Se anteriormente ela:
- instalava;
- reiniciava;
- falhava;
- entrava em rollback;
precisamos verificar se essa sequência mudou.
Esse é o verdadeiro teste.
DISM falhou durante RestoreHealth
Não execute:
RestoreHealth
dez vezes.
Anote o código.
Abra:
C:\Windows\Logs\DISM\dism.log
e:
C:\Windows\Logs\CBS\CBS.log
Agora nossa investigação mudou.
O problema original era rollback.
Durante o diagnóstico descobrimos que o mecanismo de reparação também apresenta uma falha.
Esse novo código pode explicar por que a atualização não consegue ser concluída.
Quando uma ISO pode ser necessária?
Em alguns cenários, o DISM pode precisar de uma fonte adequada para restaurar componentes.
Uma mídia compatível do Windows 11 pode fornecer esse conteúdo.
Mas:
não use qualquer ISO.
Antes, confirme:
- arquitetura;
- edição;
- idioma;
- versão;
- compatibilidade com o sistema instalado.
Descubra a edição
Execute:
DISM /Online /Get-CurrentEdition
Depois consulte:
winver
Essas informações ajudam a escolher a mídia.
Monte a ISO
Depois de obter uma mídia apropriada, monte-a pelo Windows.
Suponha que apareça como:
D:
Abra:
D:\sources
Procure:
install.wim
ou:
install.esd
Descubra o índice do WIM
Se existir:
install.wim
execute:
DISM /Get-WimInfo /WimFile:D:\sources\install.wim
O comando mostra as imagens presentes no arquivo.
Encontre a edição correspondente.
Não copie o índice de um tutorial.
O índice pode variar conforme a mídia.
Para ESD
Se existir:
install.esd
execute:
DISM /Get-WimInfo /WimFile:D:\sources\install.esd
Novamente, encontre a imagem apropriada.
Utilizando WIM como Source
A estrutura pode ser:
DISM /Online /Cleanup-Image /RestoreHealth /Source:wim:D:\sources\install.wim:ÍNDICE
Substitua:
D:
e:
ÍNDICE
pelos valores correspondentes ao seu computador e à mídia utilizada.
Utilizando ESD
A estrutura pode ser:
DISM /Online /Cleanup-Image /RestoreHealth /Source:esd:D:\sources\install.esd:ÍNDICE
O princípio é o mesmo.
/LimitAccess não é uma opção de “reparo mais forte”
Podemos encontrar:
/LimitAccess
adicionado ao comando.
Esse parâmetro impede que o DISM utilize o Windows Update como fonte durante aquela operação.
Isso pode ser útil quando queremos limitar o reparo à fonte especificada.
Mas não aumenta magicamente a capacidade do DISM.
Se a mídia não possui o conteúdo necessário, limitar as outras fontes pode fazer o procedimento falhar.
Depois do Source, valide novamente
Se o reparo terminar corretamente:
DISM /Online /Cleanup-Image /ScanHealth
Depois:
sfc /scannow
Reinicie.
Então tente novamente:
KBxxxxxxx
Não pule esse último teste.
Cenário 4 — Os logs apontam para um driver
Agora temos um caminho completamente diferente.
Suponha que:
- Component Store esteja saudável;
- SFC não encontre problemas;
- cache não mostre indícios relevantes;
- rollback sempre aconteça durante o boot;
- eventos apontem repetidamente para um driver.
Nesse caso, insistir no DISM pode não resolver.
Precisamos investigar o driver.
Liste drivers de terceiros
Execute:
pnputil /enum-drivers
Observe:
- Published Name;
- Provider Name;
- Class Name;
- Driver Version.
Procure o driver identificado nos registros.
Não remova drivers aleatoriamente
Uma lista de drivers antigos não significa que todos precisam ser removidos.
Alguns dispositivos utilizam drivers antigos perfeitamente funcionais.
Remover indiscriminadamente pode:
- desativar hardware;
- interromper rede;
- afetar armazenamento;
- impedir inicialização;
- criar novos problemas.
Primeiro estabeleça a relação entre driver e rollback.
Procure uma versão apropriada do fabricante
Quando existe evidência de incompatibilidade, verifique o suporte oficial do fabricante do:
- notebook;
- placa-mãe;
- dispositivo;
- adaptador.
Compare:
- versão instalada;
- versão disponível;
- compatibilidade com a versão atual do Windows 11.
Não utilize sites aleatórios de “atualização automática de drivers”.
E se o problema começou depois de atualizar um driver?
Nesse caso, dependendo do dispositivo e da situação, podemos investigar:
- reversão do driver;
- reinstalação;
- versão anterior estável;
- versão mais recente corrigida.
A escolha depende das evidências.
Cenário 5 — Uma única KB continua falhando
Esse cenário merece abordagem própria.
Se:
- Defender atualiza;
- drivers atualizam;
- outras KBs instalam;
- somente uma cumulativa falha;
não trate o Windows Update inteiro como defeituoso.
Concentre-se naquela KB.
Pesquise o número exato da KB
Procure informações oficiais relacionadas a:
KBxxxxxxx
Verifique:
- problemas conhecidos;
- requisitos;
- correções;
- versão do sistema;
- possíveis incompatibilidades documentadas.
Atualizações podem ter problemas conhecidos que afetam determinados ambientes.
Essa informação pode evitar horas tentando reparar um computador que está enfrentando um problema já documentado.
Instalação manual pode ser usada como teste
Dependendo da atualização, pode ser possível obter o pacote apropriado pelo Microsoft Update Catalog.
Uma instalação manual pode ajudar no diagnóstico.
Mas existe uma interpretação importante.
Se a instalação manual também falhar durante servicing, isso sugere que o problema não está simplesmente na capacidade do Windows Update de baixar o pacote.
O problema pode estar em uma etapa posterior.
Instalação manual não contorna todas as camadas
Existe um mito de que:
“Se baixar a KB manualmente, ela instala de outro jeito.”
O método de obtenção do pacote muda.
Mas o Windows ainda precisa integrar a atualização ao sistema.
Se o Component Store ou outro elemento necessário estiver problemático, o pacote manual também pode falhar.
Registre o resultado da instalação manual
Anote:
- código;
- horário;
- mensagem;
- necessidade de reinicialização;
- resultado depois do boot.
Depois compare com os logs.
Se o mesmo erro reaparece, ganhamos uma pista importante.
Cenário 6 — A partição de sistema aparece nos indícios
Não redimensione partições imediatamente.
Primeiro abra:
Gerenciamento de Disco
ou execute:
Get-Partition
e:
Get-Volume
Registre:
- tamanho;
- tipo;
- espaço;
- layout do disco.
Se o código e os registros apontarem para um problema relacionado à partição de sistema, aí podemos planejar uma intervenção específica.
Alterar EFI exige cuidado
Uma partição EFI participa da inicialização.
Uma operação incorreta pode impedir o Windows de iniciar.
Portanto, não:
- formate;
- exclua;
- recrie;
- mova;
- redimensione;
sem uma necessidade técnica claramente identificada e um procedimento adequado.
O fato de ela parecer pequena não significa que esteja errada.
Cenário 7 — Existe software interferindo na atualização
Alguns programas trabalham em camadas profundas do sistema.
Exemplos incluem:
- antivírus de terceiros;
- ferramentas de segurança;
- criptografia;
- virtualização;
- utilitários de baixo nível;
- programas de “otimização”;
- modificadores do Windows.
Se o rollback começou depois da instalação ou atualização de um software desse tipo, registre essa relação temporal.
Não desinstale tudo de uma vez
Se suspeitamos de interferência, altere uma variável por vez.
Por exemplo:
- identifique o software suspeito;
- confirme se possui atualização;
- consulte registros;
- teste uma intervenção controlada;
- tente novamente a mesma KB.
Assim conseguimos saber se a hipótese estava correta.
Inicialização limpa pode ajudar no diagnóstico?
Em alguns cenários, reduzir softwares e serviços de terceiros durante o teste pode ajudar a identificar interferência.
Mas isso precisa ser utilizado como técnica de isolamento.
A pergunta deve ser:
“O rollback continua quando removemos temporariamente determinada variável de terceiros?”
Não:
“Vou desabilitar tudo e ver no que dá.”
Cenário 8 — Corrupção volta depois de cada reparação
Esse cenário muda completamente o diagnóstico.
Imagine:
DISM detecta corrupção.
RestoreHealth repara.
SFC fica saudável.
Atualização instala.
Dias depois:
corrupção novamente.
Agora o problema não é apenas reparar.
Precisamos descobrir:
por que o sistema continua sendo corrompido?
Armazenamento entra na investigação
Procure outros sintomas:
- erros de leitura;
- travamentos;
- arquivos corrompidos;
- erros do sistema de arquivos;
- eventos relacionados ao disco;
- comportamento irregular do SSD.
Informações SMART podem ajudar.
Mas um único 0x80073712 ou rollback não prova defeito do SSD.
Memória também pode ser investigada
Se o computador apresenta simultaneamente:
- telas azuis;
- programas fechando;
- corrupção recorrente;
- instalações falhando;
- erros diferentes a cada tentativa;
uma investigação da RAM pode fazer sentido.
Mais uma vez:
conjunto de sintomas, não um código isolado.
Overclock e instabilidade também importam
Um computador pode parecer estável durante navegação e tarefas leves, mas apresentar erros em operações intensas.
Atualizações podem:
- descompactar grandes quantidades de dados;
- validar arquivos;
- processar componentes;
- realizar muitas operações de armazenamento e memória.
Se existe overclock ou configuração agressiva de hardware e corrupção recorrente, estabilidade deve entrar no diagnóstico.
E se nada resolver?
Existe uma opção importante antes da instalação limpa:
reinstalação de reparo do Windows 11.
Quando compatível, o Setup do Windows pode reinstalar componentes preservando:
- arquivos;
- programas;
- grande parte das configurações.
Essa técnica pode reparar estruturas que DISM e SFC não conseguem reconstruir completamente.
Faça backup antes de uma reparação profunda
Mesmo quando o procedimento oferece preservação de arquivos, mantenha backup.
Copie dados importantes antes de:
- reparação in-place;
- alterações de partição;
- manutenção profunda;
- instalação do Windows.
Backup não é apenas para quando esperamos que algo dê errado.
É parte do procedimento técnico.
Como saber se corrigimos o rollback?
Depois de qualquer intervenção, repita o teste original.
A mesma:
KBxxxxxxx
deve:
- baixar;
- preparar;
- solicitar reinicialização quando necessário;
- continuar durante o boot;
- concluir;
- iniciar o Windows;
- aparecer como instalada.
Além disso, a mensagem:
“Desfazendo alterações”
não deve reaparecer.
Confirme a nova build
Depois de uma atualização cumulativa bem-sucedida, execute:
winver
Compare a compilação com o estado esperado para a atualização instalada.
Também consulte:
Configurações → Windows Update → Histórico de atualizações
Isso fornece evidências adicionais de que o processo realmente terminou.
Não considere sucesso apenas porque o Windows iniciou
Depois de um rollback, o Windows também inicia.
Portanto:
“Entrou na Área de Trabalho”
não é critério suficiente.
Precisamos confirmar:
- KB;
- build;
- histórico;
- ausência do rollback.
O diagnóstico correto termina onde começou
Começamos com:
“KBxxxxxxx instala e depois é desfeita.”
Terminamos quando podemos afirmar tecnicamente:
“KBxxxxxxx foi instalada, o Windows concluiu a reinicialização e a nova build foi aplicada sem rollback.”
Esse é um teste objetivo.
Depois de acompanhar todo o processo, fica claro que a mensagem de rollback não deve ser tratada como um erro isolado.
Quando o Windows 11 mostra que está desfazendo alterações, normalmente estamos vendo uma consequência.
A pergunta correta continua sendo:
qual evento aconteceu antes e fez o Windows abandonar a atualização?
Essa lógica permite montar uma árvore de diagnóstico muito mais eficiente.
Árvore de diagnóstico do rollback do Windows Update
Comece pelo sintoma:
Windows Update instalou a atualização, reiniciou e depois desfez as alterações.
Agora siga a sequência.
Etapa 1 — Identifique a atualização
Abra:
Configurações → Windows Update → Histórico de atualizações
Anote:
KBxxxxxxx
Também registre qualquer código apresentado.
Sem identificar a atualização, o diagnóstico continua genérico demais.
Etapa 2 — Descubra quando a falha acontece
Pergunte:
A atualização falha antes ou depois da reinicialização?
Antes da reinicialização
Investigue principalmente:
- download;
- preparação;
- serviços;
- cache;
- integridade;
- código apresentado.
Depois da reinicialização
Investigue principalmente:
- servicing;
- operações pendentes;
- Component Store;
- drivers;
- boot;
- partições de sistema;
- logs do período offline.
Essa separação economiza bastante tempo.
Etapa 3 — Descubra se uma ou várias atualizações falham
Se somente:
KBxxxxxxx
falha, mas Defender, drivers e outras atualizações funcionam, concentre a investigação na KB.
Se praticamente tudo falha, amplie para:
- Windows Update;
- serviços;
- Component Store;
- integridade;
- políticas;
- sistema operacional.
Etapa 4 — Consulte os registros
Utilize principalmente:
C:\Windows\Logs\CBS\CBS.log
e o log gerado com:
Get-WindowsUpdateLog
Também consulte o Visualizador de Eventos.
Use:
- horário;
- KB;
- código;
como pontos de referência.
O objetivo é encontrar a primeira falha relevante antes do rollback.
Etapa 5 — Verifique a integridade
Comece com:
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:
sfc /scannow
Não execute esses comandos apenas por hábito.
Interprete os resultados.
Etapa 6 — Teste novamente a mesma KB
Depois da intervenção:
- reinicie;
- abra Windows Update;
- tente a mesma atualização;
- observe se o rollback reaparece.
Essa etapa confirma se a intervenção realmente alterou o comportamento.
Tabela rápida: sintoma e camada que merece investigação
| Sintoma | Camada que merece atenção |
|---|---|
| Atualização não baixa | Windows Update, rede, serviços e cache |
| Download para em determinada porcentagem | transferência, cache, serviços e conectividade |
| Baixa 100%, mas instalação falha imediatamente | servicing, pacote e integridade |
| Instala e solicita reinicialização | processo avançou para etapa posterior |
| Falha somente depois do reboot | servicing offline, driver, boot, operações pendentes |
| Mostra “Desfazendo alterações” | procurar a falha anterior ao rollback |
| Uma única KB falha | investigar KB e erro específicos |
| Todas as cumulativas falham | integridade e servicing merecem prioridade |
| DISM encontra corrupção | Component Store precisa ser investigado |
| DISM não consegue reparar | analisar código, logs e fonte de reparação |
| SFC sempre encontra novos problemas | investigar causa da corrupção recorrente |
| Rollback ocorre sempre no mesmo ponto | procurar falha reproduzível |
| Falha acontece em pontos diferentes | considerar instabilidade mais ampla |
| Windows Update manual também falha | problema pode estar além do download |
| Rollback começou após novo driver | investigar compatibilidade do driver |
Essa tabela serve para orientar a investigação.
Ela não substitui os logs.
Download, instalação, servicing e rollback são coisas diferentes
Um dos principais conceitos deste artigo é separar as etapas.
Podemos simplificar:
Windows Update detecta
↓
baixa
↓
prepara
↓
servicing aplica alterações
↓
reinicialização conclui operações
↓
novo estado é confirmado
Se alguma etapa crítica não puder ser concluída:
↓
rollback
Essa visão explica por que apagar o cache pode funcionar em um computador e ser completamente inútil em outro.
SoftwareDistribution resolve qual tipo de problema?
A pasta:
C:\Windows\SoftwareDistribution
está ligada à infraestrutura local utilizada pelo Windows Update.
Sua recriação pode ajudar em determinados problemas relacionados a essa camada.
Mas se a atualização:
- foi baixada;
- foi preparada;
- entrou no processo de instalação;
- reiniciou;
- somente então falhou;
precisamos considerar seriamente outras camadas.
E Catroot2?
catroot2
também participa de processos importantes relacionados às atualizações.
Sua redefinição pode fazer sentido quando o diagnóstico aponta para essa estrutura.
Mas não existe motivo técnico para transformar:
SoftwareDistribution + catroot2
em uma combinação obrigatória para qualquer erro do Windows Update.
Quando DISM faz sentido?
DISM merece prioridade quando existem indícios envolvendo:
- servicing;
- Component Store;
- corrupção;
- pacotes;
- falhas em atualizações cumulativas;
- erros encontrados pelos mecanismos de manutenção.
Comece pela verificação.
Não pela reparação automática.
Quando SFC faz sentido?
SFC verifica arquivos protegidos do sistema.
Pode ser particularmente útil quando:
- existem arquivos do Windows corrompidos;
- DISM já corrigiu a fonte utilizada para reparação;
- logs apontam para problemas de integridade.
DISM e SFC são complementares em muitos cenários, mas não são exatamente a mesma ferramenta.
Comandos essenciais deste diagnóstico
Para identificar edição:
DISM /Online /Get-CurrentEdition
Para verificar rapidamente o Component Store:
DISM /Online /Cleanup-Image /CheckHealth
Para realizar análise:
DISM /Online /Cleanup-Image /ScanHealth
Para tentar reparação:
DISM /Online /Cleanup-Image /RestoreHealth
Para verificar arquivos protegidos:
sfc /scannow
Para consultar pacotes:
DISM /Online /Get-Packages
Para gerar WindowsUpdate.log:
Get-WindowsUpdateLog
Para listar drivers de terceiros:
pnputil /enum-drivers
Para consultar partições:
Get-Partition
Para consultar volumes:
Get-Volume
Não execute todos os comandos ao mesmo tempo
A lista anterior não é um script.
Ela é uma caixa de ferramentas.
Escolha o comando de acordo com a pergunta que deseja responder.
Por exemplo:
“O Component Store apresenta corrupção?”
Use:
ScanHealth
“Qual edição está instalada?”
Use:
Get-CurrentEdition
“Quais drivers de terceiros estão no Driver Store?”
Use:
pnputil /enum-drivers
Essa é a diferença entre diagnóstico e coleção de comandos.
O que não fazer quando o Windows entra em rollback
Alguns procedimentos podem transformar uma falha recuperável em um problema maior.
Não exclua WinSxS
Não apague manualmente:
C:\Windows\WinSxS
A pasta faz parte da infraestrutura de componentes do Windows.
Seu tamanho e funcionamento não podem ser avaliados como se ela fosse uma pasta temporária comum.
Não baixe DLLs aleatórias
Se CBS.log citar uma DLL, não procure uma cópia em um site desconhecido.
O arquivo precisa ser:
- correto;
- compatível;
- íntegro;
- correspondente ao componente apropriado.
Use os mecanismos de servicing do Windows para reparação.
Não altere permissões do sistema sem necessidade
Tutoriais podem sugerir tomar posse de:
- WinSxS;
- System32;
- arquivos de componentes.
Isso pode alterar permissões que o próprio servicing espera encontrar.
Não apague pacotes manualmente
Encontrar o nome de um pacote no CBS.log não significa que ele deva ser excluído.
O pacote pode simplesmente ser a vítima de uma falha originada em outro componente.
Não formate imediatamente
Rollback repetitivo pode ser frustrante.
Mesmo assim, existem várias etapas antes da instalação limpa:
- logs;
- DISM;
- SFC;
- análise da KB;
- driver;
- reparação com fonte;
- reinstalação de reparo.
Formatação deve ser uma decisão técnica, não uma reação automática.
Quando considerar uma reinstalação de reparo?
A reinstalação de reparo, também conhecida em muitos contextos como reparação in-place, pode ser considerada quando:
- servicing continua inconsistente;
- DISM não resolve completamente;
- atualizações continuam falhando;
- componentes do Windows apresentam problemas;
- queremos tentar preservar aplicativos e arquivos.
O procedimento utiliza a instalação do Windows para reconstruir partes importantes do sistema.
Reparação in-place não é formatação
Essa distinção é importante.
Em um cenário compatível, podemos iniciar:
setup.exe
a partir de uma mídia adequada e selecionar a opção de preservação disponível para manter arquivos e aplicativos.
A disponibilidade dessas opções depende da compatibilidade da mídia e do sistema.
Por isso, confira cuidadosamente a tela antes de prosseguir.
Faça backup mesmo quando pretende preservar arquivos
Nenhum procedimento profundo de manutenção deve substituir uma estratégia de backup.
Antes de uma reparação in-place, salve:
- documentos;
- fotos;
- arquivos profissionais;
- dados importantes;
- configurações críticas;
- informações necessárias para recuperar programas e contas.
Backup é prevenção.
Quando começar a suspeitar de hardware?
Um único rollback não prova defeito físico.
Mas a suspeita aumenta quando aparecem simultaneamente:
- corrupção recorrente;
- telas azuis;
- travamentos;
- erros de leitura;
- arquivos corrompidos;
- instalações falhando aleatoriamente;
- erros diferentes em cada tentativa;
- reinicializações inesperadas.
Nesse cenário, investigar armazenamento e memória passa a fazer sentido.
SSD com problema pode afetar atualizações?
Pode.
O Windows Update precisa ler e gravar grande quantidade de dados.
Se o armazenamento apresenta problemas, operações podem falhar.
Mas não use:
“Windows Update falhou”
como diagnóstico de SSD defeituoso.
Procure evidências adicionais.
SMART pode ajudar
Ferramentas que leem informações SMART do SSD ou HDD podem ajudar a verificar determinados indicadores fornecidos pelo dispositivo.
Esses dados devem ser interpretados junto com:
- eventos;
- sintomas;
- testes;
- comportamento do sistema.
Um status simplificado de “bom” também não substitui uma investigação quando existem sintomas graves.
E a memória RAM?
Problemas de memória podem produzir comportamento aparentemente desconexo.
Por exemplo:
- programas fecham;
- arquivos são corrompidos;
- instalações falham;
- erros mudam;
- sistema trava.
Se o computador apresenta esse conjunto de sintomas, testar memória passa a ser justificável.
Novamente:
contexto é fundamental.
FAQ — Windows Update instala e depois desfaz as alterações
Por que o Windows 11 instala uma atualização e depois desfaz?
Porque alguma etapa necessária para concluir a atualização não conseguiu chegar a um estado válido. O Windows pode então iniciar um rollback para retornar ao estado anterior.
“Desfazendo alterações” é o erro verdadeiro?
Nem sempre.
Frequentemente é a consequência de uma falha que aconteceu anteriormente.
Por isso, os logs próximos ao início da reversão são importantes.
Se chegou a 100%, a atualização não deveria estar instalada?
Não necessariamente.
O percentual pode representar uma etapa específica.
Ainda podem existir operações durante a reinicialização antes da confirmação final.
Como descobrir qual atualização falhou?
Abra:
Configurações → Windows Update → Histórico de atualizações
e procure a KB correspondente.
O que significa KB?
KB vem de Knowledge Base.
A Microsoft utiliza identificadores KB para artigos e atualizações relacionados a produtos e correções.
Uma atualização pode ser identificada, por exemplo, como:
KBxxxxxxx
Onde fica o CBS.log?
Normalmente em:
C:\Windows\Logs\CBS\CBS.log
Para que serve o CBS.log?
Ele registra informações relacionadas ao Component-Based Servicing e pode fornecer pistas sobre pacotes, componentes e falhas durante operações de manutenção.
Como gerar o WindowsUpdate.log?
Abra o PowerShell e execute:
Get-WindowsUpdateLog
Posso simplesmente apagar SoftwareDistribution?
Não trate isso como solução universal.
A recriação dessa estrutura pode ajudar em determinados problemas do Windows Update, mas não corrige automaticamente falhas de servicing, drivers, Component Store ou outros problemas que acontecem depois do download.
Preciso apagar Catroot2?
Não automaticamente.
A redefinição de catroot2 deve responder a uma hipótese relacionada a essa camada.
DISM corrige rollback?
DISM pode reparar determinados problemas da imagem do Windows e do Component Store.
Se a causa do rollback estiver relacionada a essa camada, ele pode fazer parte da solução.
Mas não corrige todas as possíveis causas.
Qual comando DISM devo executar primeiro?
Uma abordagem diagnóstica pode começar com:
DISM /Online /Cleanup-Image /CheckHealth
e, quando necessária uma verificação mais profunda:
DISM /Online /Cleanup-Image /ScanHealth
O que RestoreHealth faz?
DISM /Online /Cleanup-Image /RestoreHealth
tenta reparar corrupção detectada na imagem do Windows utilizando fontes apropriadas disponíveis ao mecanismo.
DISM chegou a 100% e apresentou erro. Funcionou?
Não considere apenas a porcentagem.
Leia a mensagem final e registre o código.
Uma operação pode atingir determinado progresso e ainda terminar com falha.
Preciso executar SFC depois do DISM?
Em muitos cenários de corrupção, faz sentido verificar os arquivos protegidos depois que o Component Store foi reparado.
Use:
sfc /scannow
e interprete o resultado final.
O rollback pode ser provocado por driver?
Problemas de compatibilidade ou de inicialização envolvendo drivers podem participar de determinadas falhas.
A relação deve ser investigada por logs, eventos e histórico de alterações.
Antivírus pode causar rollback?
Softwares de segurança podem interagir profundamente com o sistema, mas não atribua automaticamente o problema ao antivírus.
Procure evidências de interferência e relação temporal antes de modificar a instalação.
Pouco espaço em disco pode impedir atualização?
Sim, falta de espaço pode interferir em operações de atualização.
Porém, espaço livre em C: é apenas uma das verificações possíveis.
Posso instalar a KB manualmente?
Dependendo da atualização, o pacote apropriado pode estar disponível no Microsoft Update Catalog.
A instalação manual também pode funcionar como teste diagnóstico.
Se a instalação manual falhar também, o que significa?
Isso pode indicar que o problema não está simplesmente no download feito pelo Windows Update.
A falha pode estar no servicing ou em outra etapa necessária para aplicar a atualização.
Preciso formatar o Windows?
Não necessariamente.
Antes da instalação limpa, podemos avaliar:
- logs;
- integridade;
- Component Store;
- drivers;
- KB específica;
- fonte de reparação;
- reinstalação de reparo.
Reinstalação de reparo apaga meus arquivos?
Em cenários compatíveis, o Setup pode oferecer a preservação de arquivos e aplicativos.
Mesmo assim, faça backup antes do procedimento.
Como saber se o problema foi realmente resolvido?
Não basta o computador voltar à Área de Trabalho.
Confirme:
- KB instalada;
- histórico;
- build;
- ausência de novo rollback.
Execute:
winver
quando precisar verificar a compilação atual.
Conclusão: rollback é a pista, não necessariamente a causa
Quando o Windows Update instala uma atualização, reinicia o computador e depois começa a desfazer alterações, é tentador procurar uma solução rápida.
Limpar SoftwareDistribution.
Redefinir catroot2.
Executar DISM.
Executar SFC.
Reiniciar serviços.
Baixar a KB manualmente.
Se nada funcionar, formatar.
Essa sequência pode transformar diagnóstico em loteria.
Existe uma abordagem melhor.
Primeiro descubra:
qual KB falhou?
Depois:
em qual etapa?
Em seguida:
qual código apareceu?
Depois:
o que CBS.log, WindowsUpdate.log e Visualizador de Eventos registraram antes do rollback?
Só então escolha a correção.
Essa metodologia permite separar problemas de:
- download;
- cache;
- servicing;
- Component Store;
- arquivos do sistema;
- drivers;
- partições;
- software;
- hardware.
O Windows desfazer uma atualização não significa necessariamente que o mecanismo de rollback esteja com defeito.
Muitas vezes ocorre justamente o contrário.
O rollback está tentando proteger o sistema de uma atualização que não conseguiu atingir um estado consistente.
O verdadeiro trabalho técnico é descobrir:
o que impediu o Windows 11 de concluir a atualização?
Quando encontramos essa resposta, deixamos de executar comandos por tentativa e erro e começamos a resolver o problema na camada correta.
Precisa de ajuda com Windows Update em São Paulo?
Se o seu Windows 11 baixa uma atualização, reinicia e depois apresenta mensagens informando que está desfazendo as alterações, a VMIA – Manutenção e Configuração pode ajudar no diagnóstico.
O atendimento pode envolver análise de:
- Windows Update;
- códigos de erro;
- atualizações KB;
- CBS.log;
- DISM.log;
- Component Store;
- SFC e DISM;
- drivers;
- armazenamento;
- integridade do Windows;
- falhas recorrentes após reinicialização.
A VMIA atende usuários domésticos, profissionais, home office e pessoas que preferem um atendimento explicado em linguagem clara.
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
E-mail: suporte@vmia.com.br
Site: https://vmia.site
Blog: https://vmia.com.br
Também existe a possibilidade de atendimento remoto, dependendo do tipo de problema.
Se o Windows Update continua entrando em rollback, evite executar dezenas de procedimentos diferentes sem registrar os resultados.
Diagnosticar primeiro pode evitar uma formatação desnecessária.
Faça um comentário