Erros do Windows Update no Windows 11 com códigos de erro e diagnóstico — Guia completo da VMIA para diagnosticar códigos, causas e falhas do Windows Update no Windows 10 e Windows 11.

62 / 100

Desenvolvido por Rank Math SEO

Pontuação de SEO

O Windows Update falhou.

Na tela aparece algo parecido com:

0x80070002

ou:

0x80070005

ou talvez:

0x80070020

Para muitos usuários, esses códigos parecem apenas uma sequência aleatória de números e letras.

Então começa a busca:

“Como corrigir erro 0x80070002?”

O problema é que um código de erro não deve ser tratado apenas como um número que possui uma receita pronta.

Um erro pode apontar para:

arquivo ausente;
arquivo corrompido;
permissão incorreta;
arquivo bloqueado por outro processo;
problema de download;
falha de servicing;
Component Store;
driver;
serviço;
armazenamento;
rede;
proxy;
política;
assinatura;
atualização incompatível;
operação pendente;
falha durante upgrade.

Por isso, este guia não será apenas uma coleção de códigos acompanhados da instrução:

“execute SFC e DISM”.

A proposta será diferente.

Para cada família de erros vamos entender:

código

↓

significado

↓

camada do Windows

↓

momento da falha

↓

causas possíveis

↓

logs

↓

diagnóstico

↓

solução adequada.

Esse método é muito mais seguro do que executar dezenas de comandos sem saber o que realmente falhou.

Windows Update não é apenas uma tela nas Configurações

Quando abrimos:

Configurações → Windows Update

parece que existe apenas um programa responsável por:

procurar atualização;
baixar;
instalar;
reiniciar.

Internamente, diferentes componentes participam do processo.

Dependendo do tipo de atualização e da etapa, podemos envolver mecanismos relacionados a:

Windows Update Agent;
Update Orchestrator;
BITS;
Delivery Optimization;
Cryptographic Services;
Windows Modules Installer;
TrustedInstaller;
Component Based Servicing;
Component Store;
DISM;
drivers;
Setup do Windows.

Isso ajuda a explicar por que existem tantas famílias de códigos.

Um código de erro não identifica necessariamente a causa raiz

Imagine:

0x80070020

O código está relacionado a uma situação de compartilhamento/acesso em que determinado arquivo necessário está em uso.

Mas ainda falta descobrir:

qual arquivo?

qual processo está usando?

em qual etapa?

por que esse processo está bloqueando o arquivo?

Portanto:

0x80070020

não significa automaticamente:

“faça X e estará resolvido”.

O código fornece uma direção.

O diagnóstico encontra a causa.

O contexto é tão importante quanto o código

Considere dois computadores mostrando:

0x80070002

Computador A pode estar com um arquivo necessário ausente.

Computador B pode ter ficado em estado inconsistente depois de uma atualização anterior.

O código ajuda a classificar o problema, mas precisamos dos logs e do contexto para descobrir o que aconteceu naquele computador.

Regra número 1 deste guia

Sempre registre:

código + KB + horário + etapa + comportamento.

Não registre apenas:

0x80070002

Registre algo como:

KBxxxxxxx — falha durante instalação — 0x80070002 — 14:37.

Agora temos muito mais informação para procurar nos logs.

Descubra qual atualização falhou

Abra:

Configurações → Windows Update → Histórico de atualizações

Procure a falha.

Anote o número da KB quando disponível.

Exemplo:

KBxxxxxxx

Não utilize números inventados de KB durante o diagnóstico.

Copie exatamente o que aparece no computador.

Confirme a versão do Windows

Pressione:

Windows + R

Digite:

winver

Anote:

edição;
versão;
build.

Isso é importante porque uma solução encontrada para outra versão do Windows pode não representar corretamente o seu cenário.

Windows 10 e Windows 11 podem compartilhar códigos

Muitos códigos não pertencem exclusivamente a uma versão específica.

O mesmo código pode aparecer em diferentes versões porque determinados erros vêm de componentes e APIs compartilhados pelo sistema operacional.

Por isso:

código igual não significa ambiente igual.

Onde encontrar informações além da interface do Windows Update?

Um dos primeiros recursos é o log do Windows Update.

No PowerShell:

Get-WindowsUpdateLog

O comando gera uma representação legível dos eventos do Windows Update a partir dos registros correspondentes.

Não procure apenas a palavra “Error”

Imagine encontrar:

0x80070005

O ideal é observar:

horário;
operação anterior;
componente;
pacote;
arquivo;
sequência;
eventos posteriores.

Uma linha isolada pode não explicar a causa.

CBS.log

Outro arquivo extremamente importante está em:

C:\Windows\Logs\CBS\CBS.log

CBS significa:

Component Based Servicing.

Esse log é particularmente importante quando a falha ocorre durante a instalação e manutenção de componentes.

WindowsUpdate.log e CBS.log não fazem exatamente a mesma coisa

De maneira simplificada:

WindowsUpdate.log

pode ajudar a investigar o fluxo do Windows Update.

Enquanto:

CBS.log

pode fornecer informações importantes sobre a instalação e servicing dos componentes.

Em determinados problemas, precisamos correlacionar os dois.

DISM.log

Quando utilizamos DISM, outro arquivo relevante é:

C:\Windows\Logs\DISM\dism.log

Se:

DISM /Online /Cleanup-Image /RestoreHealth

falhar, não adianta simplesmente executar o mesmo comando dez vezes.

Precisamos descobrir:

por que o próprio reparo falhou?

O DISM.log pode ajudar nessa investigação.

Upgrade de versão possui outros logs

Quando o problema acontece durante uma atualização maior de versão do Windows, entram em cena logs relacionados ao Windows Setup.

Nesse cenário podemos precisar analisar arquivos como:

setupact.log

setuperr.log

dependendo da fase e do cenário.

Também existe o SetupDiag para ajudar na análise de falhas de upgrade.

Esse assunto terá uma parte própria neste guia.

As grandes famílias de erros

Ao longo deste guia encontraremos famílias como:

0x800700xx

Erros gerais do sistema operacional que podem aparecer durante Windows Update.

0x80072xxx

Frequentemente associados a comunicação e operações relacionadas à conectividade.

0x8024xxxx

Família diretamente relacionada a diferentes componentes do Windows Update.

0x800Fxxxx

Muitos códigos relacionados a servicing, pacotes e Component Store.

0x800737xx

Erros relacionados a Side-by-Side/Component Store e servicing.

0xC19001xx

Muito importantes durante upgrades do Windows, frequentemente exigindo investigação de drivers e da fase de instalação.

Não use essa divisão como uma regra absoluta para diagnosticar apenas pelos primeiros dígitos.

Ela serve para organizar a investigação.

Parte 1 — Família 0x800700xx

Vamos começar por uma família extremamente comum.

É importante entender uma característica:

0x800700xx não é uma família exclusiva do Windows Update.

São erros gerais do Windows que podem aparecer enquanto o Windows Update executa determinada operação.

Isso muda a maneira de diagnosticar.

Erro 0x80070002

Um dos códigos mais conhecidos:

0x80070002

Está associado a:

ERROR_FILE_NOT_FOUND

Em termos simples:

o sistema não encontrou um arquivo necessário.

Mas isso ainda não explica:

qual arquivo?

O erro 0x80070002 não significa simplesmente “cache corrompido”

Esse é um erro comum em tutoriais.

Muitos dizem:

0x80070002 → apague SoftwareDistribution.

Isso pode não resolver a causa.

A investigação precisa descobrir qual recurso está ausente.

Possíveis contextos do 0x80070002

Dependendo do cenário, podemos encontrar:

arquivo necessário ausente;
atualização anterior incompleta;
referência apontando para recurso inexistente;
inconsistência de servicing;
problema relacionado a pacote;
estado local inconsistente.

Primeiro passo para 0x80070002

Registre:

KB;
horário;
build;
etapa.

Depois gere:

Get-WindowsUpdateLog

E analise:

C:\Windows\Logs\CBS\CBS.log

Procure o erro no contexto

Pesquise:

0x80070002

Mas leia as linhas próximas.

Queremos encontrar pistas como:

nome de arquivo;
caminho;
pacote;
operação;
componente.

Exemplo conceitual

Imagine que o log indique:

arquivo necessário não encontrado.

A pergunta seguinte é:

qual arquivo?

Depois:

por que ele deveria existir?

Só então decidimos se estamos diante de:

arquivo do sistema;
pacote incompleto;
download;
driver;
referência incorreta;
Component Store.

SoftwareDistribution entra quando?

Se as evidências apontarem para estado local/download relacionado ao Windows Update, podemos considerar a reconstrução da estrutura.

Mas não comece por isso apenas porque viu:

0x80070002.

Component Store entra quando?

Se os logs apontarem para componentes ou servicing, investigamos a integridade da imagem.

Uma sequência possível é:

DISM /Online /Cleanup-Image /CheckHealth

Depois, quando necessário:

DISM /Online /Cleanup-Image /ScanHealth

E, se houver justificativa:

DISM /Online /Cleanup-Image /RestoreHealth

SFC também pode participar

Quando existe suspeita de arquivos protegidos do sistema:

sfc /scannow

Mas novamente:

não execute automaticamente apenas porque apareceu 0x80070002.

Erro 0x80070003

Outro código próximo é:

0x80070003

Associado a:

ERROR_PATH_NOT_FOUND

Em termos simples:

o caminho especificado não foi encontrado.

0x80070002 e 0x80070003 são iguais?

Não.

De maneira simplificada:

0x80070002

aponta para arquivo não encontrado.

Enquanto:

0x80070003

indica caminho não encontrado.

Na prática, os logs continuam sendo essenciais para descobrir qual caminho ou recurso provocou a falha.

Onde investigar 0x80070003?

CBS.log é particularmente útil quando o problema ocorre durante servicing.

Abra:

C:\Windows\Logs\CBS\CBS.log

Correlacione com o horário da falha.

Não crie manualmente uma pasta apenas porque o erro diz “path not found”

Primeiro descubra:

qual caminho está faltando e quem esperava encontrá-lo.

Criar diretórios aleatoriamente pode mascarar o problema ou produzir outro estado inconsistente.

Erro 0x80070005

Código:

0x80070005

Associado a:

E_ACCESSDENIED

Em português:

acesso negado.

Esse código merece muita atenção.

“Acesso negado” não significa apenas usuário sem administrador

O Windows Update executa operações utilizando diferentes contextos e serviços.

Uma falha de permissão pode envolver:

TrustedInstaller;
SYSTEM;
diretórios;
Registro;
ferramenta de segurança;
política;
permissões alteradas.

Onde procurar 0x80070005?

Gere:

Get-WindowsUpdateLog

Depois analise:

CBS.log

Procure:

0x80070005

e observe o objeto ao qual o acesso foi negado.

A pergunta correta

Não é:

“como dar permissão total?”

É:

“qual recurso negou acesso e qual identidade deveria ter acesso a ele?”

Essa diferença é fundamental.

Não dê “Controle Total para Todos”

Essa é uma solução perigosa encontrada em alguns tutoriais.

Alterar permissões indiscriminadamente em:

Windows;
WinSxS;
SoftwareDistribution;
Registro;

pode criar problemas de segurança e servicing.

Se o antivírus estiver envolvido?

Ferramentas de segurança de terceiros podem interferir em determinadas operações.

Mas não conclua automaticamente:

“0x80070005 = antivírus”.

Procure evidências nos logs.

Políticas também podem causar acesso negado

Em computadores gerenciados por:

empresa;
escola;
domínio;
MDM;

determinadas políticas podem restringir operações.

Nesse cenário, remover políticas manualmente pode ser incorreto.

Erro 0x8007000D

Código:

0x8007000D

Associado a:

ERROR_INVALID_DATA

Em português:

dados inválidos.

O que significa “dados inválidos”?

Algum conteúdo necessário para a operação não pôde ser interpretado como esperado.

O desafio novamente é descobrir:

qual dado?

Possíveis áreas

Dependendo do contexto:

pacote;
manifesto;
metadados;
arquivo;
Component Store;
conteúdo baixado.

Não traduza 0x8007000D automaticamente como “Windows corrompido”

Pode existir corrupção.

Mas o código sozinho não permite concluir isso.

Precisamos identificar qual operação recebeu os dados inválidos.

Logs primeiro

Analise:

WindowsUpdate.log

CBS.log

Se houver indícios de Component Store:

DISM /Online /Cleanup-Image /CheckHealth

e depois, conforme necessário:

DISM /Online /Cleanup-Image /ScanHealth

Erro 0x80070020

Código:

0x80070020

Associado a:

ERROR_SHARING_VIOLATION

Em termos práticos:

um arquivo necessário está sendo utilizado ou bloqueado durante a operação.

Aqui temos um problema diferente

O arquivo pode existir.

Pode estar íntegro.

Pode ter permissões corretas.

Mas outro processo está interferindo no acesso necessário.

Quem pode estar usando o arquivo?

Precisamos descobrir.

Pode existir interferência de:

antivírus;
antimalware;
backup;
filtro de sistema;
aplicativo;
serviço;
outro processo.

Não escolha o culpado antes de analisar.

CBS.log novamente

Procure:

0x80070020

no período correspondente.

O objetivo é identificar o arquivo envolvido.

Process Monitor pode ajudar

Quando precisamos descobrir qual processo está acessando determinado arquivo, uma ferramenta como Process Monitor pode ser útil.

O diagnóstico fica muito mais preciso:

arquivo bloqueado

↓

qual arquivo?

↓

qual processo está acessando?

↓

por quê?

Reinicialização limpa pode ser útil

Quando existe forte suspeita de interferência de software de terceiros, um ambiente de inicialização controlado pode ajudar a comparar o comportamento.

Mas isso deve ser feito como teste diagnóstico, não como ritual obrigatório para qualquer erro.

Erro 0x80070057

Outro código extremamente conhecido:

0x80070057

Geralmente associado a:

ERROR_INVALID_PARAMETER

Ou seja:

parâmetro incorreto/inválido.

Esse código é amplo

Ele pode aparecer em diferentes componentes do Windows.

Por isso, dizer:

“0x80070057 é sempre Windows Update corrompido”

seria incorreto.

Contexto novamente

Precisamos saber:

qual função falhou;
qual pacote;
qual fase;
qual parâmetro;
qual log registrou.

Erro 0x80070070

Código:

0x80070070

Está relacionado a:

espaço insuficiente no disco.

Esse parece simples.

Mas ainda precisamos descobrir:

qual volume ficou sem espaço?

Nem sempre é apenas C:

Durante determinados processos de atualização ou upgrade, outras partições podem participar.

Portanto, não suponha imediatamente que:

“tenho 50 GB livres em C:, então esse código não faz sentido”.

Verifique volumes

PowerShell:

Get-Volume

Analise:

unidade do Windows;
partições relevantes;
espaço disponível.

Atualizações precisam de espaço de trabalho

O Windows pode precisar de armazenamento para:

download;
extração;
staging;
instalação;
temporários;
recuperação.

Por isso, o tamanho do download não representa necessariamente todo o espaço necessário durante a instalação.

Não existe um número mágico universal

Evite regras como:

“se tiver exatamente 20 GB livres, qualquer atualização funcionará”.

O espaço necessário depende do tipo de atualização e do estado do sistema.

Erro 0x80070570

Código:

0x80070570

Pode aparecer quando:

arquivo ou diretório está corrompido e ilegível.

Esse erro merece uma investigação mais ampla.

Possíveis áreas

Pode haver:

arquivos baixados corrompidos;
arquivos ou manifestos do Component Store com problema;
corrupção do sistema de arquivos;
problema de armazenamento.

Não condene o SSD imediatamente

Um erro de arquivo corrompido não prova sozinho que o SSD está defeituoso.

Precisamos procurar outras evidências.

Primeiro verifique os logs

Analise:

WindowsUpdate.log

CBS.log

SFC pode ajudar a verificar arquivos protegidos

Uma opção de verificação é:

sfc /verifyonly

Para reparação, quando apropriado:

sfc /scannow

E o sistema de arquivos?

Se existirem sinais adicionais de problema no volume, podemos investigar armazenamento.

Por exemplo:

chkdsk C: /scan

Isso realiza uma verificação online do volume.

Mas não execute CHKDSK porque qualquer atualização falhou

Precisamos de indícios relacionados ao armazenamento ou sistema de arquivos.

Erro 0x80070490

Outro código que pode aparecer:

0x80070490

Associado a:

ERROR_NOT_FOUND

Mas novamente precisamos saber:

o que não foi encontrado?

Pode envolver operações de driver

Em determinados cenários documentados de Windows Update, esse erro pode aparecer associado a falhas durante operações com drivers, estados pendentes ou referências ausentes.

Por isso, CBS.log ganha importância.

Investigue o contexto

Abra:

C:\Windows\Logs\CBS\CBS.log

Procure:

0x80070490

Veja as linhas anteriores e posteriores.

Não altere Registro baseado apenas no código

Esse aviso é importante.

Existem soluções para cenários específicos de 0x80070490 que envolvem estruturas muito sensíveis.

Não copie uma alteração de Registro encontrada para outro computador apenas porque o número do erro coincide.

Primeiro confirme que o log apresenta o mesmo cenário.

Erro 0x80071A91

Código:

0x80071A91

Associado a:

ERROR_RM_NOT_ACTIVE

Esse erro pode aparecer quando o mecanismo responsável por determinadas transações de recursos não consegue processar corretamente operações necessárias durante a instalação.

Por que isso importa?

Porque mostra como um erro aparentemente “do Windows Update” pode vir de uma camada muito mais profunda do sistema operacional.

O Windows Update apenas estava executando a operação quando a camada inferior falhou.

Esse conceito vale para todo o guia

Sempre pergunte:

quem gerou o código?

Não apenas:

onde o código apareceu?

Tabela inicial da família 0x800700xx

Código	Significado resumido	Primeira investigação
0x80070002	Arquivo não encontrado	Logs + arquivo/pacote ausente
0x80070003	Caminho não encontrado	CBS.log + caminho envolvido
0x80070005	Acesso negado	Permissões + processo/política
0x8007000D	Dados inválidos	Logs + pacote/componente
0x80070020	Violação de compartilhamento	Arquivo bloqueado/processo
0x80070057	Parâmetro inválido	Contexto da operação
0x80070070	Espaço insuficiente	Volumes e espaço de trabalho
0x80070570	Arquivo/diretório corrompido	Logs + integridade + armazenamento
0x80070490	Item não encontrado	CBS.log + operação responsável

Essa tabela serve para iniciar o diagnóstico.

Não substitui a análise.

Método VMIA para qualquer código do Windows Update

Antes de aplicar uma correção:

Passo 1 — Copie o código completo

Exemplo:

0x80070005

Não escreva apenas:

“erro 005”.

Passo 2 — Identifique a KB

Abra:

Histórico de atualizações

Passo 3 — Registre horário

Isso será extremamente importante para os logs.

Passo 4 — Identifique a etapa

O erro aconteceu durante:

busca?
download?
preparação?
instalação?
reinicialização?
upgrade?

Passo 5 — Confirme a versão

winver

Passo 6 — Gere WindowsUpdate.log

Get-WindowsUpdateLog

Passo 7 — Analise CBS.log quando o problema envolver instalação/servicing

C:\Windows\Logs\CBS\CBS.log

Passo 8 — Correlacione horário

Não procure apenas o código.

Procure a sequência.

Passo 9 — Identifique a camada

Pergunte se o problema parece relacionado a:

download;
arquivo;
permissão;
servicing;
Component Store;
driver;
rede;
armazenamento;
política.

Passo 10 — Só então escolha a ferramenta

Pode ser:

DISM;
SFC;
Process Monitor;
CHKDSK;
PnPUtil;
reconstrução de cache;
análise de rede;
análise de política;
SetupDiag.

Por que não começar com DISM?

Porque DISM não é um botão universal para:

“consertar Windows Update”.

Ele é extremamente útil quando o problema realmente envolve a imagem e o servicing.

Por que não começar com SFC?

Pelo mesmo motivo.

SFC verifica arquivos protegidos do sistema.

Se a causa é:

proxy bloqueando comunicação

SFC não corrige proxy.

Se a causa é:

disco cheio

SFC não cria espaço.

Se a causa é:

arquivo bloqueado por um processo

SFC não identifica necessariamente o processo responsável.

Por que não começar apagando SoftwareDistribution?

Porque você pode eliminar estado local sem corrigir:

Component Store;
permissões;
driver;
armazenamento;
política;
arquivo ausente;
erro de servicing.

Depois o Windows recria o cache e o problema retorna.

Por que não começar renomeando catroot2?

Pelo mesmo princípio.

Faça isso somente quando o diagnóstico realmente apontar para a camada correspondente.

Não transforme troubleshooting em superstição

Um procedimento técnico precisa responder:

por que estou executando este comando?

Se a resposta for:

“porque todos os tutoriais mandam”

a investigação ainda não começou.

A sequência correta

Erro

↓

Código

↓

Horário

↓

Etapa

↓

Log

↓

Componente

↓

Causa provável

↓

Teste

↓

Correção

↓

Validação.

Como validar a solução?

Não basta o comando terminar sem erro.

Depois da correção:

reinicie quando necessário;
abra Windows Update;
procure atualizações;
tente novamente a KB;
confirme o resultado no Histórico;
confirme a build quando aplicável.

Não confunda ausência de mensagem de erro com atualização instalada

A confirmação deve vir do estado final.

Dependendo do tipo de atualização, podemos verificar:

Histórico de atualizações;
build;
pacotes;
estado do Windows Update.

Comando para listar pacotes

Quando necessário:

DISM /Online /Get-Packages

Isso pode ajudar a verificar estados de pacotes.

Mas não utilize:

/Remove-Package

aleatoriamente para tentar corrigir erros.

Um aviso sobre tutoriais de Registro

Ao longo deste guia encontraremos erros cuja resolução em cenários específicos pode envolver Registro.

A regra será:

não alterar Registro somente porque o código coincide.

Primeiro confirmaremos nos logs que estamos diante do mesmo problema.

Um aviso sobre serviços

Também encontraremos instruções envolvendo:

wuauserv;
BITS;
CryptSvc;
TrustedInstaller.

Não configure todos os serviços como:

Automático

apenas porque o Windows Update falhou.

O estado esperado depende do serviço e do momento.

Consultando serviços sem alterá-los

Podemos começar simplesmente observando.

Windows Update:

sc query wuauserv

BITS:

sc query bits

Cryptographic Services:

sc query cryptsvc

TrustedInstaller:

sc query trustedinstaller

Consultar é diferente de modificar.

O objetivo deste guia

Ao final desta série, a ideia é que você consiga olhar para:

0x800F081F

0x80073712

0x80240034

0x80072EE2

0xC1900101

e não pensar:

“qual comando mágico resolve?”

Mas sim:

“qual camada falhou e qual log vai me mostrar a causa?”

Essa mudança de raciocínio transforma completamente o diagnóstico do Windows Update.

rros 0x80072xxx: rede, timeout, proxy, TLS e comunicação do Windows Update

Na Parte 1 começamos pelos erros da família 0x800700xx.

Agora entramos em uma categoria completamente diferente.

Alguns dos erros mais conhecidos são:

0x80072EE2

0x80072EFE

0x80072F8F

Em muitos computadores, esses códigos aparecem acompanhados de uma situação aparentemente contraditória:

o Windows Update não consegue atualizar, mas a internet está funcionando normalmente.

O usuário abre o navegador.

Google funciona.

YouTube funciona.

E-mail funciona.

Um teste de velocidade funciona.

Mesmo assim:

Windows Update falha.

Isso acontece porque:

“ter internet”

não significa necessariamente:

“todas as comunicações necessárias ao Windows Update estão funcionando corretamente”.

Essa diferença será a base desta parte.

Antes de qualquer coisa: não troque o DNS imediatamente

Quando aparece um erro relacionado a comunicação, muita gente começa executando:

ipconfig /flushdns

depois troca para outro DNS.

Depois reinicia o roteador.

Depois desativa IPv6.

Depois desativa firewall.

Depois remove antivírus.

Depois reseta toda a pilha TCP/IP.

O problema dessa estratégia é simples:

muitas variáveis são alteradas antes de sabermos onde está a falha.

O método correto é:

identificar a camada primeiro.

O Windows Update precisa conversar com serviços externos

Durante diferentes operações, o Windows pode precisar:

localizar serviços;
consultar metadados;
verificar atualizações;
obter informações sobre aplicabilidade;
baixar conteúdo;
validar informações;
estabelecer conexões HTTPS;
comunicar-se com uma fonte corporativa de atualização.

Dependendo do ambiente, essa fonte pode ser:

infraestrutura pública da Microsoft;
WSUS;
Configuration Manager;
outra infraestrutura gerenciada.

Portanto, o diagnóstico muda conforme o computador.

Primeiro descubra de onde o computador recebe atualizações

Em um computador doméstico comum, provavelmente estamos lidando diretamente com os serviços públicos da Microsoft.

Em um computador empresarial, isso pode ser diferente.

Antes de alterar qualquer coisa, descubra:

esse computador é gerenciado?

Verifique políticas

Execute:

gpresult /r

Isso pode ajudar a identificar políticas aplicadas ao computador.

Para gerar um relatório:

gpresult /h "%userprofile%\Desktop\gpresult.html"

Abra o arquivo gerado.

Não remova políticas corporativas

Se o computador pertence a:

empresa;
escola;
organização;

não remova políticas apenas para tentar fazer Windows Update funcionar.

A configuração pode ser intencional.

Nesse cenário, o diagnóstico precisa considerar a infraestrutura responsável.

Erro 0x80072EE2

Código:

0x80072EE2

Esse erro está associado a:

WININET_E_TIMEOUT

Em termos simples:

a operação atingiu o tempo limite.

Mas isso ainda não responde:

por quê?

O que timeout realmente significa?

Imagine:

Windows Update envia uma solicitação.

Espera.

A resposta necessária não chega dentro do tempo esperado.

A operação termina com timeout.

Isso não prova automaticamente que:

“a internet está lenta”.

0x80072EE2 pode aparecer mesmo com internet rápida

Você pode possuir:

fibra óptica;
baixa latência;
excelente teste de velocidade;

e ainda receber:

0x80072EE2.

Por quê?

Porque o problema pode estar no caminho específico utilizado pelo Windows Update.

Possíveis áreas para investigar

Entre elas:

conectividade;
firewall;
proxy;
filtragem;
VPN;
política;
fonte corporativa;
indisponibilidade específica;
caminho de rede.

Não conclua qual delas é responsável apenas pelo código.

Primeiro: registre o horário

Exemplo:

Windows Update falhou às 15:42 com 0x80072EE2.

Agora gere:

Get-WindowsUpdateLog

Procure:

80072EE2

e analise o período.

Não olhe apenas a linha do erro

Observe o que aconteceu imediatamente antes.

Procure pistas sobre:

requisição;
servidor;
serviço;
tentativa;
repetição;
fallback;
download.

O erro acontece na busca ou no download?

Essa diferença é extremamente importante.

Falha durante busca

Pode existir dificuldade para alcançar a fonte de atualização ou consultar os serviços necessários.

Falha durante download

A detecção pode ter funcionado, mas a obtenção do conteúdo falhou.

São cenários diferentes.

Teste a conectividade básica

Antes de investigar coisas complexas, confirme:

computador possui endereço IP;
gateway está acessível;
DNS está funcionando;
navegação básica funciona.

Execute:

ipconfig /all

Observe:

IPv4;
gateway;
servidores DNS;
adaptador utilizado.

Não altere nada ainda

ipconfig /all

é diagnóstico.

Não é reparação.

Teste DNS

Você pode utilizar:

nslookup

para testar a resolução de um nome específico envolvido no diagnóstico.

Mas lembre:

resolver o nome não prova que a comunicação HTTPS completa funciona.

Ping também não prova que Windows Update funciona

Esse é outro erro comum.

Você executa:

ping

e recebe resposta.

Conclusão:

“rede está perfeita”.

Não necessariamente.

Ping testa ICMP.

Windows Update depende de outras comunicações.

E se o ping não responder?

Também não conclua imediatamente que o serviço está fora do ar.

Um servidor ou infraestrutura pode não responder a ICMP e ainda oferecer normalmente outros serviços.

Portanto:

ping é apenas uma peça do diagnóstico.

Verifique proxy WinHTTP

Execute:

netsh winhttp show proxy

O resultado pode mostrar se existe configuração de proxy para WinHTTP.

Proxy pode ser invisível para o usuário

É possível o navegador funcionar enquanto outro componente encontra uma configuração diferente ou uma política específica.

Por isso, o fato de:

Edge abrir sites

não elimina automaticamente proxy da investigação.

Não execute reset de proxy por impulso

Você encontrará comandos como:

netsh winhttp reset proxy

Não execute apenas porque apareceu 0x80072EE2.

Primeiro descubra se o proxy existe intencionalmente.

Em ambiente empresarial, removê-lo pode causar outros problemas.

VPN

Se uma VPN estiver ativa, ela pode alterar:

rota;
DNS;
proxy;
filtragem;
inspeção;
caminho até os serviços.

Isso não significa:

VPN = culpada.

Significa que temos uma variável para testar.

Faça comparação controlada

Se for um computador pessoal e for seguro fazê-lo:

registre o erro;
teste Windows Update com a configuração atual;
desconecte temporariamente a VPN;
teste novamente;
compare.

Se o comportamento mudar, temos uma pista.

Não desinstale a VPN imediatamente

Primeiro faça o teste comparativo.

Firewall

Firewall também pode participar.

Mas evite a estratégia:

“desative todo o firewall e tente”.

Antes disso, procure:

regras;
logs;
políticas;
produto responsável;
endereço/serviço afetado.

Segurança não deve ser removida como primeiro diagnóstico

Desativar indiscriminadamente:

firewall;
antivírus;
proteção de rede;

pode aumentar o risco e ainda não revelar a causa.

Faça testes controlados quando houver evidência.

Teste em outra rede

Em um notebook pessoal, uma comparação extremamente útil pode ser testar em outra rede confiável.

Por exemplo:

Rede A → Windows Update falha

Rede B → Windows Update funciona

Isso muda bastante o diagnóstico.

O que essa comparação sugere?

A máquina é a mesma.

O Windows é o mesmo.

A atualização é a mesma.

Mudou:

o caminho de rede.

Agora podemos investigar:

roteador;
DNS;
proxy;
firewall;
operadora;
filtragem.

Mas não pare no resultado

Se outra rede funciona, ainda precisamos descobrir:

o que existe de diferente entre as redes?

Erro 0x80072EFE

Código:

0x80072EFE

Está associado a:

WININET_E_CONNECTION_ABORTED

Em termos simplificados:

a conexão foi encerrada de maneira anormal.

Isso é diferente de timeout

Compare:

0x80072EE2

A operação esperou e atingiu timeout.

0x80072EFE

Uma conexão existente foi encerrada de forma anormal.

Essa diferença pode ajudar a direcionar a investigação.

O que investigar no 0x80072EFE?

Dependendo do contexto:

instabilidade de conexão;
proxy;
filtragem;
TLS;
BITS;
falha ao transferir determinado conteúdo;
infraestrutura de rede.

WindowsUpdate.log é fundamental

Execute:

Get-WindowsUpdateLog

Procure:

80072EFE

Observe se aparecem:

tentativas repetidas;
download;
URL/serviço;
HTTP;
proxy;
falha de conexão.

Repetição é uma pista

Imagine:

tentativa 1 → 0x80072EFE

tentativa 2 → 0x80072EFE

tentativa 3 → 0x80072EFE

Isso sugere uma falha consistente naquele caminho.

Agora precisamos descobrir onde a comunicação está sendo interrompida.

BITS

BITS significa:

Background Intelligent Transfer Service.

Ele participa de transferências utilizadas por diferentes componentes do Windows.

Consulte o estado:

sc query bits

STOPPED significa que BITS está quebrado?

Não.

Esse é outro erro de interpretação.

Um serviço pode estar parado naquele momento e iniciar quando necessário.

Não altere automaticamente o tipo de inicialização.

Consulte antes de modificar

Essa regra vale para:

BITS

wuauserv

CryptSvc

TrustedInstaller

Primeiro:

observe.

Depois:

interprete.

Só então:

modifique quando necessário.

Download específico falha?

Se os logs mostram que determinada transferência falha repetidamente, isso é mais útil do que simplesmente saber:

“BITS deu erro”.

Queremos identificar:

qual conteúdo;
qual origem;
qual erro HTTP;
em qual horário.

0x80072EFE também pode envolver TLS

Esse ponto merece atenção.

Em determinados cenários, configurações relacionadas a TLS e conjuntos de criptografia podem impedir a comunicação segura necessária.

Isso é especialmente importante em:

sistemas com políticas alteradas;
ambientes corporativos;
configurações endurecidas;
máquinas antigas;
alterações manuais de segurança.

Não altere cipher suites aleatoriamente

Conjuntos de criptografia são parte da segurança da comunicação.

Não copie uma lista encontrada na internet e substitua a configuração do computador sem confirmar que esse é realmente o problema.

Política de criptografia

Em ambientes gerenciados, determinadas configurações podem ser impostas por política.

Se o log mostra falha de conexão segura e existem configurações específicas de cipher suites, isso merece investigação.

Mas não altere o Registro antes de confirmar o cenário.

Erro 0x80072F8F

Código:

0x80072F8F

Esse erro merece atenção especial porque pode aparecer em contextos envolvendo comunicação segura.

Dependendo do cenário, podemos encontrar problemas relacionados a:

TLS;
decodificação;
certificados;
relógio;
negociação SSL.

Primeiro verifique data e hora

Parece simples demais.

Mas comunicação segura depende de tempo correto.

Abra:

Configurações → Hora e idioma → Data e hora

Confirme:

data;
hora;
fuso horário.

Um relógio muito errado pode quebrar validações

Certificados possuem períodos de validade.

Se o computador acredita estar em uma data completamente diferente, a validação pode falhar.

Verifique pelo comando

Execute:

w32tm /query /status

Isso pode ajudar a analisar o estado do serviço de tempo e sincronização.

Não force servidores de horário aleatórios

Se o computador pertence a um domínio, a hierarquia de tempo pode ser controlada pelo ambiente.

Não substitua essa configuração sem entender a infraestrutura.

Certificados

Em ambientes corporativos, proxy com inspeção HTTPS ou infraestrutura interna pode utilizar cadeias de certificados específicas.

Se o cliente não confia na cadeia necessária, a comunicação pode falhar.

Isso não significa instalar qualquer certificado

Nunca baixe certificados aleatórios para tentar corrigir Windows Update.

Primeiro identifique:

qual certificado;
qual cadeia;
qual origem;
qual política;
qual servidor.

TLS

TLS é utilizado para proteger comunicações.

Configurações incompatíveis podem impedir que cliente e servidor estabeleçam corretamente uma sessão segura.

Sistemas modernos versus ambientes antigos

Esse ponto é importante para um guia que cobre Windows 10 e Windows 11.

Uma solução criada para um sistema operacional antigo não deve ser copiada automaticamente para uma instalação moderna.

Os padrões de TLS, componentes e atualizações disponíveis mudam.

Não habilite protocolos antigos apenas para “fazer funcionar”

Isso pode reduzir a segurança.

Se existe problema de TLS, investigue:

versão do Windows;
atualizações instaladas;
políticas;
Schannel;
proxy;
cipher suites;
certificados.

Schannel

O Windows registra determinados eventos relacionados à comunicação TLS através do Schannel.

Abra:

Visualizador de Eventos

e investigue eventos relevantes quando o problema aponta para negociação segura.

Não use todo evento Schannel como prova

Eventos antigos ou não relacionados podem existir.

Correlacione:

horário do Windows Update

com:

horário do evento.

Esse princípio aparece novamente

Sempre:

tempo + código + operação.

O navegador funciona, mas Windows Update não

Agora podemos explicar melhor esse cenário.

O navegador pode:

utilizar seu próprio contexto;
utilizar configurações diferentes;
alcançar destinos diferentes;
negociar comunicação de forma diferente.

Enquanto o Windows Update pode estar:

acessando outro endpoint;
utilizando WinHTTP;
seguindo política;
usando outra fonte;
enfrentando filtragem específica.

Por isso:

“Chrome funciona”

não encerra o diagnóstico.

DNS entra onde?

DNS pode ser relevante se o computador não consegue resolver os nomes necessários.

Teste:

nslookup nome-do-host

Mas utilize o host identificado durante o diagnóstico.

Não invente um endereço aleatório.

Flush DNS resolve?

ipconfig /flushdns

limpa o cache do resolvedor DNS.

Pode ser útil quando existe evidência de cache incorreto ou desatualizado.

Não é um reparo universal para:

0x80072xxx.

Trocar para Google DNS ou Cloudflare resolve?

Pode alterar o comportamento quando o problema realmente está relacionado ao resolvedor utilizado.

Mas não é correto assumir que:

erro de Windows Update = trocar DNS.

Primeiro teste resolução.

IPv6

Outra solução frequente encontrada na internet é:

“desative IPv6”.

Não faça isso como procedimento padrão.

Se existe suspeita de problema específico com IPv6, teste e diagnostique.

Não elimine o protocolo apenas para ver se “talvez funcione”.

MTU

Problemas de MTU podem produzir comportamentos estranhos de conectividade em alguns cenários.

Mas novamente:

0x80072EE2

não significa automaticamente:

MTU incorreto.

Procure evidências antes.

Proxy: navegador e WinHTTP podem diferir

Por isso o comando:

netsh winhttp show proxy

é importante.

Você pode encontrar:

Direct access (no proxy server)

ou uma configuração de proxy.

Registre o resultado.

Não use reset completo de rede como primeira tentativa

Comandos que resetam:

Winsock;
TCP/IP;
proxy;
DNS;

podem alterar várias camadas ao mesmo tempo.

Se funcionar, você talvez nem saiba qual era a causa.

Se não funcionar, terá criado novas variáveis.

Melhor sequência para 0x80072xxx

1. Registre o código

Exemplo:

0x80072EE2

2. Registre horário

Exemplo:

17:28

3. Identifique a etapa

Busca?

Download?

Instalação?

4. Gere WindowsUpdate.log

Get-WindowsUpdateLog

5. Identifique a origem da atualização

Microsoft?

WSUS?

Ambiente gerenciado?

6. Verifique configuração IP

ipconfig /all

7. Verifique proxy

netsh winhttp show proxy

8. Teste resolução

nslookup

quando houver host relevante.

9. Compare outra rede confiável quando apropriado

10. Verifique VPN

Faça comparação controlada.

11. Investigue firewall

Sem desativar indiscriminadamente.

12. Verifique horário

w32tm /query /status

13. Se houver sinais de TLS, investigue Schannel, certificados e políticas

14. Teste novamente

Tabela da família 0x80072xxx

Código	Significado resumido	Primeira investigação
0x80072EE2	Timeout	WindowsUpdate.log + caminho de rede
0x80072EFE	Conexão encerrada anormalmente	Rede/BITS/proxy/TLS
0x80072F8F	Falha ligada à comunicação segura/decodificação	TLS, relógio, certificados e logs
0x80072EFD	Não foi possível estabelecer conexão	Rede, proxy, firewall e origem

A tabela orienta.

Não substitui o diagnóstico.

Erro 0x80072EFD

Outro código importante:

0x80072EFD

Está associado a uma falha ao estabelecer conexão com o servidor.

Novamente, isso não significa automaticamente:

internet desconectada.

Compare EE2, EFE e EFD

De maneira simplificada:

0x80072EE2

A comunicação atingiu timeout.

0x80072EFE

A conexão foi encerrada anormalmente.

0x80072EFD

A conexão não pôde ser estabelecida.

Essas diferenças ajudam a entender em qual ponto a comunicação falhou.

E se todos os computadores da casa falharem?

Agora temos uma pista diferente.

Se:

PC 1 falha

PC 2 falha

notebook falha

na mesma rede, mas funcionam em outra rede, a investigação muda para infraestrutura compartilhada.

E se apenas um computador falhar?

Agora suspeitamos mais de:

configuração local;
política;
proxy;
firewall local;
VPN;
TLS;
certificados;
componentes do Windows.

Essa comparação é poderosa

Em troubleshooting, mudar apenas uma variável por vez é extremamente útil.

Matriz de comparação

Um PC falha em todas as redes

Investigue o próprio computador.

Vários PCs falham somente em uma rede

Investigue a rede compartilhada.

Um PC falha somente com VPN

Investigue VPN/caminho/política.

Navegador funciona, Windows Update falha

Investigue caminho específico do Update.

Busca funciona, download falha

Investigue transferência/conteúdo.

Falha HTTPS com horário incorreto

Corrija primeiro tempo e sincronização.

E o roteador?

Pode participar.

Mas não faça reset de fábrica imediatamente.

Primeiro determine se:

outros dispositivos apresentam o mesmo comportamento;
outra rede resolve;
existe filtragem;
DNS muda o resultado;
há proxy/VPN;
existe problema de rota.

Reiniciar roteador é diagnóstico?

Pode ser um teste simples, mas não deve substituir a investigação.

Se reiniciar resolve temporariamente e o problema retorna, isso também é uma pista.

Operadora pode interferir?

Problemas de rota ou conectividade externa podem ocorrer.

Mas precisamos de evidência.

Teste:

outra rede;
outro caminho;
horário diferente;
outros dispositivos.

Não transforme um erro de rede em reparação do Windows

Esse é um erro frequente.

Usuário recebe:

0x80072EE2

e executa:

DISM /RestoreHealth

SFC /scannow

Isso pode não ter relação com o problema.

Se o erro é timeout de comunicação, precisamos investigar comunicação.

DISM entra quando?

Quando existem evidências de corrupção ou servicing problemático.

Não porque qualquer código começou com:

0x800.

SFC entra quando?

Quando existe motivo para verificar arquivos protegidos do sistema.

Não como primeiro teste de conectividade.

SoftwareDistribution entra quando?

Se existe evidência de estado local/cache/download inconsistente.

Não porque o servidor demorou para responder.

Catroot2 entra quando?

Quando a investigação aponta para a camada correspondente.

Não como ritual obrigatório.

O erro acontece apenas em determinada KB?

Isso é muito importante.

Se:

Windows Update procura normalmente

outras atualizações baixam

somente uma KB falha

talvez não estejamos diante de uma falha geral de internet.

Investigue aquela transferência e o contexto específico.

O erro acontece antes de listar qualquer atualização?

Agora um problema de comunicação com a fonte de atualização se torna mais relevante.

Windows Update empresarial

Em computadores corporativos, podem existir:

WSUS;
Configuration Manager;
políticas;
proxy;
certificados internos;
inspeção TLS.

Nesse cenário, um tutorial doméstico pode ser completamente inadequado.

Não force o computador a usar os servidores públicos da Microsoft

Se ele pertence a uma organização, a fonte configurada pode fazer parte da política de gerenciamento.

Checklist 0x80072xxx

Antes de alterar o sistema, responda:

Qual é o código exato?

Em qual horário aconteceu?

Busca ou download?

Qual KB?

A máquina é gerenciada?

Existe proxy?

Existe VPN?

Outra rede funciona?

Outros computadores apresentam o mesmo problema?

Data e hora estão corretas?

Existe evento TLS relevante?

WindowsUpdate.log mostra qual destino/operação falhou?

Essas respostas valem mais do que executar dez comandos aleatórios.

O que não fazer com erros 0x80072xxx

Não:

desligue firewall permanentemente;
desinstale antivírus por impulso;
desative IPv6 sem diagnóstico;
altere MTU aleatoriamente;
troque DNS sem testar resolução;
remova proxy corporativo;
altere cipher suites sem evidência;
instale certificados desconhecidos;
habilite protocolos antigos apenas para testar;
resete toda a rede como primeira ação;
apague SoftwareDistribution automaticamente;
execute DISM e SFC como solução universal.

Fluxo resumido

0x80072xxx

↓

Qual código?

↓

Qual etapa?

↓

WindowsUpdate.log

↓

Qual destino/operação falhou?

↓

Proxy?

↓

VPN?

↓

DNS?

↓

Outra rede?

↓

Firewall/filtragem?

↓

Relógio?

↓

TLS/certificado?

↓

Política/WSUS?

↓

Corrigir somente a camada identificada

↓

Testar Windows Update novamente.

Erros 0x8024xxxx: Windows Update Agent, detecção, download e instalação

Nas partes anteriores analisamos duas famílias importantes:

0x800700xx

0x80072xxx

Agora chegamos a uma família particularmente importante para este guia:

0x8024xxxx

Aqui encontramos muitos códigos associados diretamente ao ecossistema do Windows Update.

Isso significa que, quando encontramos um erro começando por:

0x8024

temos uma indicação muito mais específica de que o problema está relacionado a alguma operação executada pelo Windows Update Agent ou por componentes ligados ao processo de atualização.

Mas ainda existe uma regra fundamental:

o código não deve ser interpretado isoladamente.

Precisamos saber:

qual atualização;
qual etapa;
qual horário;
qual componente;
qual operação;
qual log;
qual estado do sistema.

O que é Windows Update Agent?

O Windows Update Agent, frequentemente chamado de WUA, participa do mecanismo utilizado pelo Windows para localizar, avaliar e processar atualizações.

Em termos simplificados, o sistema precisa executar etapas como:

detectar

↓

avaliar aplicabilidade

↓

obter metadados

↓

baixar

↓

preparar

↓

instalar

↓

confirmar

↓

reiniciar quando necessário.

Uma falha pode acontecer em qualquer uma dessas etapas.

Por que a família 0x8024xxxx é tão importante?

Porque existem códigos que indicam situações bastante diferentes.

Por exemplo:

uma atualização pode não ser aplicável.

Outra pode exigir reinicialização.

Outra pode estar bloqueada porque existe uma instalação em andamento.

Outra pode ter falhado durante download.

Outra pode apresentar problema de metadados.

Outra pode estar relacionada ao próprio serviço.

Portanto:

0x8024xxxx não representa um único tipo de defeito.

É uma família.

Comece sempre pelo Histórico de Atualizações

Abra:

Configurações → Windows Update → Histórico de atualizações

Procure:

KB;
data;
resultado;
código.

Anote tudo.

Registre também a build

Execute:

winver

Isso será especialmente importante quando investigarmos erros de aplicabilidade.

Gere WindowsUpdate.log

Abra PowerShell e execute:

Get-WindowsUpdateLog

Depois procure o código.

Mas lembre-se:

não leia apenas a linha onde aparece o erro.

Leia o contexto.

0x8024000B — WU_E_CALL_CANCELLED

Código:

0x8024000B

Significado:

WU_E_CALL_CANCELLED

Em termos simples:

uma operação foi cancelada.

“Cancelada” não explica quem cancelou

Precisamos descobrir:

usuário?
serviço?
processo?
mudança de estado?
outra operação?
reinicialização?

Portanto, procure no WindowsUpdate.log o que aconteceu imediatamente antes.

Não tente reparar componentes apenas porque uma operação foi cancelada

Primeiro descubra:

por que ocorreu o cancelamento.

Uma operação cancelada não significa automaticamente corrupção.

0x8024000C — WU_E_NOOP

Código:

0x8024000C

Significado:

WU_E_NOOP

De maneira simplificada, a operação solicitada não exigiu nenhuma ação.

Isso é muito diferente de:

“Windows Update está destruído”.

Estado pode ser mais importante que reparação

Alguns códigos representam estados ou resultados de operações.

Nem todo código significa:

corrupção que precisa ser reparada.

Essa distinção será muito importante ao longo da família 0x8024xxxx.

0x8024000D — WU_E_XML_MISSINGDATA

Código:

0x8024000D

Está relacionado a dados necessários ausentes em informações XML processadas pelo Windows Update.

Aqui começamos a entrar em problemas ligados a:

metadados;
informações de atualização;
conteúdo necessário para processamento.

O que fazer?

Não comece apagando pastas.

Primeiro:

Get-WindowsUpdateLog

Procure:

8024000D

Identifique qual operação estava processando dados quando ocorreu a falha.

0x8024000E — WU_E_XML_INVALID

Código:

0x8024000E

Relaciona-se a informações XML inválidas.

Compare:

0x8024000D

Informações necessárias estão ausentes.

0x8024000E

A informação processada não está válida no formato esperado.

Essa diferença pode parecer pequena, mas tecnicamente importa.

Metadados também podem falhar

Muitos usuários associam Windows Update apenas a arquivos grandes .cab ou .msu.

Mas antes de instalar uma atualização, o Windows precisa processar informações que descrevem:

atualização;
aplicabilidade;
dependências;
conteúdo;
regras.

Se esses dados não puderem ser processados corretamente, a atualização pode falhar antes mesmo da instalação real.

0x8024000F — WU_E_CYCLE_DETECTED

Código:

0x8024000F

Está associado à detecção de uma relação circular nos metadados de atualização.

É um bom exemplo de erro que não deve ser tratado simplesmente com:

sfc /scannow

O problema apontado pelo código está em outra camada.

0x80240010 — WU_E_TOO_DEEP_RELATION

Código:

0x80240010

Indica que relações entre atualizações excederam o nível permitido durante avaliação.

Novamente estamos lidando com:

metadados e relações entre atualizações.

0x80240012 — WU_E_REG_VALUE_INVALID

Código:

0x80240012

Indica que um valor de Registro necessário não possui formato válido.

Agora a investigação muda.

Não abra Regedit e comece a apagar valores

Primeiro descubra:

qual chave;
qual valor;
qual componente;
qual política.

Uma alteração incorreta no Registro pode produzir problemas muito maiores do que o erro original.

0x80240013 — WU_E_DUPLICATE_ITEM

Código:

0x80240013

Indica uma tentativa de adicionar um item duplicado a uma coleção.

É outro exemplo de estado interno que precisa ser interpretado no contexto da operação.

0x80240016 — WU_E_INSTALL_NOT_ALLOWED

Este é um dos códigos importantes.

Código:

0x80240016

Significado:

WU_E_INSTALL_NOT_ALLOWED

A instalação não pode ser executada naquele momento.

Por que uma instalação pode não ser permitida?

Uma possibilidade importante é existir:

outra instalação em andamento;
operação conflitante;
estado do sistema que impede a instalação naquele momento.

Não confunda com permissão

Apesar da palavra:

“not allowed”

não estamos necessariamente falando de:

0x80070005 — Access Denied.

São situações diferentes.

Verifique se outra operação está acontecendo

Observe Windows Update.

Verifique se existe:

atualização sendo instalada;
reinicialização pendente;
outro instalador;
manutenção do Windows em andamento.

Reinicialização pode ser relevante

Se existe uma operação anterior aguardando reinicialização, conclua corretamente esse ciclo antes de iniciar uma série de reparos.

Mas não reinicie indefinidamente

Se depois de várias reinicializações o sistema continua no mesmo estado, precisamos investigar por que a condição persiste.

Esse cenário já merece análise de servicing, pacotes e operações pendentes.

0x80240017 — WU_E_NOT_APPLICABLE

Este é um dos códigos mais importantes do guia.

Código:

0x80240017

Significado:

WU_E_NOT_APPLICABLE

Ou seja:

a operação não foi executada porque a atualização não se aplica ao computador.

Isso não significa necessariamente defeito

Essa é uma diferença enorme.

O Windows pode estar funcionando corretamente.

A atualização simplesmente:

não se aplica ao sistema naquele estado.

Por que uma atualização pode não ser aplicável?

Precisamos comparar requisitos.

Entre os fatores possíveis:

versão do Windows;
build;
arquitetura;
edição;
componente instalado;
atualização substituída;
pré-requisito;
estado do pacote.

Primeiro execute winver

winver

Registre:

versão;
build.

Verifique arquitetura

Em PowerShell:

Get-ComputerInfo | Select-Object WindowsProductName, WindowsVersion, OsBuildNumber, OsArchitecture

Agora temos um retrato melhor do sistema.

Compare com os requisitos da KB

A pergunta correta é:

essa atualização foi criada para este sistema?

Não:

“como forçar a instalação?”

Nunca force uma KB não aplicável

Se uma atualização não se aplica, forçar pacotes ou manipular servicing para instalá-la pode criar inconsistências.

Primeiro entenda por que o Windows considera o pacote não aplicável.

Atualização substituída

Uma atualização pode ter sido substituída por outra mais recente.

Nesse cenário, instalar manualmente uma KB antiga pode não fazer sentido.

0x80240018 — WU_E_NO_USERTOKEN

Código:

0x80240018

Está relacionado à ausência de um token de usuário necessário para determinada operação.

É um erro muito diferente de:

download;
corrupção;
Component Store.

Isso mostra novamente a diversidade dentro de 0x8024xxxx.

0x8024001A — WU_E_POLICY_NOT_SET

Código:

0x8024001A

Está relacionado a uma política necessária não configurada para determinada operação.

Em computadores gerenciados, isso merece atenção especial.

Política não deve ser modificada às cegas

Execute:

gpresult /r

Ou gere:

gpresult /h "%userprofile%\Desktop\gpresult.html"

Antes de alterar políticas, descubra:

computador é gerenciado?
política vem de domínio?
MDM?
configuração local?

0x8024001D — WU_E_INVALID_UPDATE

Código:

0x8024001D

Indica que determinada atualização contém metadados inválidos.

Novamente:

não conclua imediatamente que Windows está corrompido.

O problema pode estar relacionado às informações da própria atualização ou ao estado local usado para processá-las.

0x8024001E — WU_E_SERVICE_STOP

Outro código muito importante:

0x8024001E

Significado:

WU_E_SERVICE_STOP

A operação não foi concluída porque um serviço ou sistema estava sendo encerrado.

Primeiro descubra qual evento ocorreu

Pergunte:

computador estava desligando?
reiniciando?
serviço foi parado?
algum software interrompeu a operação?

Consulte Windows Update Service

sc query wuauserv

Consulte BITS:

sc query bits

Serviço parado não prova defeito

Repito porque esse erro aparece muito em troubleshooting:

STOPPED não significa necessariamente quebrado.

Alguns serviços são iniciados sob demanda.

Precisamos analisar:

tipo de inicialização;
gatilhos;
erro de inicialização;
eventos.

0x8024001F — WU_E_NO_CONNECTION

Código:

0x8024001F

Indica que a operação não pôde ser concluída porque a conexão de rede não estava disponível.

Aqui existe ligação clara com a Parte 2.

Não repita todos os reparos

Primeiro volte ao diagnóstico de rede:

ipconfig /all

netsh winhttp show proxy

Get-WindowsUpdateLog

0x80240020 — WU_E_NO_INTERACTIVE_USER

Código:

0x80240020

Relaciona-se a uma operação que exige um usuário interativo conectado.

Isso pode aparecer em determinados fluxos onde a operação precisa de interação que não está disponível.

0x80240021 — WU_E_TIME_OUT

Código:

0x80240021

Indica que a operação do Windows Update excedeu o tempo limite.

Observe que isso não é exatamente o mesmo código de timeout analisado na família WinINet.

Novamente:

mesmo conceito geral pode aparecer em camadas diferentes.

Descubra qual operação expirou

Pode ter ocorrido durante:

busca;
avaliação;
download;
instalação.

O WindowsUpdate.log será fundamental.

0x80240022 — WU_E_ALL_UPDATES_FAILED

Código:

0x80240022

Significado:

WU_E_ALL_UPDATES_FAILED

Em termos simples:

todas as atualizações envolvidas naquela operação falharam.

Esse código pode ser apenas o resumo

Esse é um conceito extremamente importante.

Imagine três atualizações:

KB A → erro X

KB B → erro Y

KB C → erro Z

No final, o Windows Update pode apresentar um resultado geral indicando que todas falharam.

Portanto:

0x80240022

pode não ser a causa raiz.

Procure os erros anteriores

No WindowsUpdate.log, volte algumas linhas.

Queremos encontrar:

o primeiro erro relevante.

Não apenas o resultado final.

Regra importante para logs

O último erro nem sempre é o mais importante.

Às vezes ele apenas diz:

“a operação falhou”.

Precisamos encontrar:

“por que começou a falhar?”

0x80240023 — WU_E_EULAS_DECLINED

Código:

0x80240023

Relaciona-se a termos de licença não aceitos para determinada atualização.

Não confunda com:

rede;
Component Store;
arquivo corrompido.

É um problema de outra natureza.

0x80240024 — WU_E_NO_UPDATE

Código:

0x80240024

Indica que:

não existem atualizações disponíveis para determinada operação.

Isso novamente pode representar um estado, e não uma corrupção.

Nem todo código é uma falha catastrófica

Essa é uma das lições mais importantes desta família.

Existem códigos que indicam:

estado;
condição;
resultado;
não aplicabilidade;
ausência de atualização;
cancelamento.

Não trate todos como:

“Windows Update quebrado”.

0x80240025 — WU_E_USER_ACCESS_DISABLED

Código:

0x80240025

Está associado a uma política que impede acesso do usuário ao Windows Update.

Aqui políticas entram novamente.

Verifique gerenciamento

Antes de modificar qualquer política:

gpresult /r

Em computador corporativo, essa restrição pode ser intencional.

0x8024002B — WU_E_LEGACYSERVER

Esse código está relacionado a uma incompatibilidade envolvendo versão do Windows Update Agent e servidor de atualização.

É particularmente relevante quando existe infraestrutura gerenciada.

Ambiente doméstico ou empresarial?

Essa pergunta muda completamente o diagnóstico.

Em ambiente empresarial, investigue:

WSUS;
políticas;
servidor configurado;
compatibilidade;
gerenciamento.

0x8024002C — WU_E_BIN_SOURCE_ABSENT

Esse código indica ausência de informações necessárias sobre a origem de determinado conteúdo binário.

Estamos novamente diante de metadados/conteúdo.

Não de um simples:

“reinicie o roteador”.

0x8024002D — WU_E_SOURCE_ABSENT

Relaciona-se à ausência de informações necessárias sobre a origem do conteúdo.

Logs e metadados ganham importância.

0x80240032 — WU_E_INVALID_CRITERIA

Código:

0x80240032

Indica critérios de pesquisa inválidos.

Esse erro pode aparecer quando uma chamada ou mecanismo de busca utiliza critérios que o Windows Update não consegue processar.

0x80240033 — WU_E_EULA_UNAVAILABLE

Código:

0x80240033

Indica que os termos de licença necessários não puderam ser obtidos.

Nesse cenário precisamos investigar o contexto de metadados e comunicação.

0x80240034 — WU_E_DOWNLOAD_FAILED

Este é um dos códigos mais conhecidos:

0x80240034

Significado:

WU_E_DOWNLOAD_FAILED

Em termos simples:

o download da atualização falhou.

Mas novamente:

por quê?

0x80240034 é resultado, não diagnóstico completo

O download pode falhar por:

comunicação;
proxy;
conteúdo;
interrupção;
estado local;
cache;
serviço;
política.

Portanto, não transforme:

0x80240034

em sinônimo de:

“SoftwareDistribution corrompida”.

Primeiro determine qual download falhou

No:

WindowsUpdate.log

procure:

80240034

e identifique:

atualização;
conteúdo;
tentativas;
erro anterior.

Procure o código anterior

Muitas vezes existe algo mais específico antes do:

0x80240034.

Por exemplo:

um erro de comunicação pode ter provocado a falha de download.

Então:

0x80240034

é consequência.

BITS e Delivery Optimization

Dependendo do cenário e da versão do Windows, mecanismos de transferência podem participar da obtenção do conteúdo.

Consulte:

sc query bits

Mas não pare por aí.

Delivery Optimization

No Windows moderno, Delivery Optimization também participa de cenários de distribuição de conteúdo.

Abra:

Configurações → Windows Update → Opções avançadas → Otimização de Entrega

Observe a configuração.

Não desative Delivery Optimization automaticamente

Se existe problema de download, precisamos descobrir:

qual mecanismo falhou.

Não simplesmente desligar componentes.

SoftwareDistribution

Agora sim essa pasta pode se tornar relevante.

Caminho:

C:\Windows\SoftwareDistribution

Ela participa do estado local utilizado pelo Windows Update.

Quando reconstruir SoftwareDistribution?

Quando existem evidências de:

cache inconsistente;
download local problemático;
estado de atualização preso;
metadados locais inconsistentes.

Não apenas porque:

0x80240034

apareceu.

Reconstrução controlada

Quando o diagnóstico justificar, podemos parar os serviços necessários e renomear a pasta para permitir sua reconstrução.

Por exemplo:

net stop wuauserv

net stop bits

Depois:

ren C:\Windows\SoftwareDistribution SoftwareDistribution.old

Em seguida:

net start bits

net start wuauserv

Depois:

reinicie quando apropriado;
abra Windows Update;
procure atualizações novamente;
verifique se o erro retorna.

Por que renomear em vez de simplesmente apagar?

Renomear preserva temporariamente o conteúdo anterior.

Isso facilita:

comparação;
reversão;
investigação.

É uma abordagem mais controlada.

Não transforme esse procedimento em primeira etapa

Se o problema for:

proxy;
política;
espaço;
Component Store;
driver;

reconstruir SoftwareDistribution não corrige a causa.

0x80240035 — WU_E_UPDATE_NOT_PROCESSED

Esse código indica que determinada atualização não foi processada.

Precisamos descobrir por que ela ficou fora do processamento esperado.

Novamente, contexto e logs.

0x80240036 — WU_E_INVALID_OPERATION

Código:

0x80240036

Indica que a operação solicitada não é válida para o estado atual do objeto.

Isso reforça outro conceito:

estado interno importa.

0x80240037 — WU_E_NOT_SUPPORTED

Código:

0x80240037

Indica que determinada funcionalidade ou operação não é suportada.

Antes de tentar reparar:

confirme versão;
arquitetura;
produto;
origem da atualização;
contexto.

Não confunda NOT_SUPPORTED com NOT_APPLICABLE

Temos:

0x80240017

WU_E_NOT_APPLICABLE

0x80240037

WU_E_NOT_SUPPORTED

Os conceitos não são idênticos.

0x80240040 — WU_E_NO_SERVER_CORE_SUPPORT

Esse código representa uma operação não suportada em uma instalação Server Core.

É um ótimo exemplo de como o ambiente define o significado prático do erro.

0x80240041 — WU_E_SYSPREP_IN_PROGRESS

Código:

0x80240041

Indica que a operação não pode ser executada enquanto Sysprep está em andamento.

Nesse caso, executar DISM, limpar cache ou trocar DNS seria atacar completamente a camada errada.

0x80240042 — WU_E_UNKNOWN_SERVICE

Código:

0x80240042

Indica que determinado serviço de atualização não está registrado no sistema.

Agora temos uma pista específica sobre registro/configuração do serviço.

0x80240044 — WU_E_PER_MACHINE_UPDATE_ACCESS_DENIED

Esse código indica acesso negado para determinada operação de atualização por máquina.

Aqui contexto de segurança, identidade e política pode ser importante.

Tabela prática da família 0x8024xxxx

Código	Significado resumido	Primeira investigação
0x8024000B	Operação cancelada	Evento anterior no log
0x8024000C	Nenhuma ação necessária	Estado da operação
0x8024000D	Dados XML ausentes	Metadados/log
0x8024000E	XML inválido	Metadados
0x8024000F	Relação circular	Metadados
0x80240010	Relações excessivamente profundas	Metadados
0x80240012	Registro inválido	Chave/valor envolvido
0x80240016	Instalação não permitida agora	Operação concorrente/reinicialização
0x80240017	Atualização não aplicável	Build/arquitetura/requisitos
0x8024001A	Política não definida	Política/gerenciamento
0x8024001D	Atualização inválida	Metadados
0x8024001E	Serviço/operação interrompida	Serviços/desligamento
0x8024001F	Sem conexão	Rede/proxy
0x80240020	Usuário interativo ausente	Contexto da operação
0x80240021	Timeout	Operação que excedeu o limite
0x80240022	Todas as atualizações falharam	Procurar erros anteriores
0x80240023	Termos de licença recusados	EULA
0x80240024	Nenhuma atualização	Estado/detecção
0x80240025	Acesso ao Update bloqueado	Política
0x80240034	Download falhou	Erro anterior/rede/cache
0x80240035	Atualização não processada	Estado/log
0x80240036	Operação inválida	Estado atual
0x80240037	Não suportado	Produto/versão/operação
0x80240041	Sysprep em andamento	Estado do sistema
0x80240042	Serviço desconhecido	Registro/configuração
0x80240044	Acesso por máquina negado	Segurança/política

Como saber se 0x80240034 é rede ou cache?

Essa é uma pergunta prática importante.

Comece observando o padrão.

Cenário A

Todas as atualizações falham no download.

Investigue primeiro:

conectividade;
proxy;
política;
serviço;
origem.

Cenário B

Somente uma atualização falha.

Investigue:

conteúdo específico;
KB;
erro anterior;
cache daquele download.

Cenário C

Download sempre falha exatamente no mesmo ponto.

Procure:

código anterior;
transferência;
armazenamento;
conteúdo.

Cenário D

Outra rede resolve imediatamente.

Investigue:

rede;
proxy;
firewall;
rota;
filtragem.

Como saber se uma KB realmente não se aplica?

Se aparecer:

0x80240017

não tente imediatamente instalar manualmente.

Verifique:

winver

Depois:

Get-ComputerInfo | Select-Object WindowsProductName,WindowsVersion,OsBuildNumber,OsArchitecture

Compare com:

produto;
arquitetura;
versão;
requisitos da atualização.

Atualização já substituída

O modelo cumulativo do Windows também significa que uma atualização mais recente pode incorporar correções anteriores.

Por isso:

“não consigo instalar uma KB antiga”

nem sempre representa um problema.

O sistema pode já estar em um estado mais novo.

Verifique pacotes

Quando necessário:

DISM /Online /Get-Packages

Procure o estado relacionado ao pacote.

Mas não remova pacotes simplesmente para tentar fazer uma KB antiga entrar.

Estados de pacote importam

Durante servicing, podemos encontrar estados diferentes.

O sistema pode possuir operações:

instaladas;
pendentes;
substituídas;
em processamento.

É por isso que simplesmente olhar a lista visual do Windows Update pode não contar toda a história.

Reinicialização pendente

Alguns erros da família podem ser consequência de outra operação aguardando conclusão.

Pergunte:

o Windows está realmente pronto para iniciar outra instalação?

Não apague pending.xml

Alguns tutoriais antigos sugerem manipular arquivos internos relacionados a operações pendentes.

Isso pode ser extremamente arriscado.

Não faça isso como solução genérica.

Se servicing está preso, investigue primeiro:

CBS.log

CBS.log volta a aparecer

Mesmo estando na família Windows Update Agent, em determinado momento o agente entrega a atualização para o mecanismo de servicing.

A partir daí, CBS.log pode se tornar mais importante do que WindowsUpdate.log.

Onde está a fronteira?

De maneira simplificada:

Windows Update encontrou e baixou

↓

servicing começou a instalar

↓

CBS passou a registrar detalhes importantes da instalação.

Por isso precisamos saber:

em qual etapa ocorreu o erro.

WindowsUpdate.log não substitui CBS.log

E CBS.log não substitui WindowsUpdate.log.

Cada um responde perguntas diferentes.

DISM.log também pode entrar

Se durante o diagnóstico executarmos:

DISM /Online /Cleanup-Image /ScanHealth

ou:

DISM /Online /Cleanup-Image /RestoreHealth

analise também:

C:\Windows\Logs\DISM\dism.log

quando houver falha.

Não execute RestoreHealth dez vezes

Se:

DISM /RestoreHealth

falhar, pare.

Anote:

código;
horário;
mensagem.

Depois investigue DISM.log e CBS.log.

O código secundário pode ser mais útil

Imagine:

Windows Update:

0x80240022

CBS:

0x800F081F

Agora temos uma pista muito mais específica.

O primeiro código diz:

as atualizações falharam.

O segundo pode apontar para:

arquivos de origem necessários não encontrados.

É assim que os logs começam a se complementar.

Outro exemplo

Windows Update:

0x80240034

E anteriormente:

0x80072EE2

Agora podemos interpretar:

download falhou

porque:

a comunicação atingiu timeout.

Nesse cenário, limpar Component Store seria uma direção pouco provável para começar.

Pense em cadeia de erros

Muitas falhas seguem:

causa

↓

erro intermediário

↓

resultado final.

Nosso objetivo é chegar o mais próximo possível da:

causa.

Não pesquise apenas o último código mostrado na tela

Esse talvez seja um dos maiores erros em troubleshooting de Windows Update.

A interface pode mostrar:

0x80240022

Mas o log pode revelar uma sequência muito mais informativa.

Método para encontrar a causa

registre o horário;
procure o erro final;
volte no log;
identifique a operação;
encontre o primeiro erro relevante;
veja se ele pertence a outra família;
investigue essa família.

Isso conecta todo este guia

Por exemplo:

0x80240034

pode levar a:

0x80072EFE

Então voltamos à:

Parte 2 — comunicação.

Outro erro 0x8024 pode levar a:

0x80070005

Então voltamos à:

Parte 1 — acesso negado.

Mais adiante um erro poderá levar a:

0x800F081F

Então entraremos na:

família 0x800Fxxxx.

É por isso que organizar o guia por famílias faz sentido.

Checklist para 0x8024xxxx

Antes de reparar qualquer coisa:

copie o código;
registre a KB;
registre horário;
execute winver;
identifique busca/download/instalação;
gere WindowsUpdate.log;
procure o código;
volte algumas linhas;
procure erro anterior;
identifique a camada;
consulte CBS.log se servicing já começou;
consulte DISM.log se DISM participou;
verifique política se a máquina for gerenciada;
verifique rede quando houver falha de conexão/download;
verifique aplicabilidade quando houver 0x80240017;
verifique operações concorrentes quando houver 0x80240016;
valide novamente depois da correção.

O que não fazer

Não:

limpe SoftwareDistribution para qualquer 0x8024;
renomeie catroot2 automaticamente;
desative firewall permanentemente;
force KB não aplicável;
remova pacotes aleatoriamente;
altere políticas corporativas;
configure todos os serviços como Automático;
apague arquivos de servicing;
altere permissões de WinSxS;
execute scripts de “reset total” sem saber o que modificam.

Scripts de reset do Windows Update

Existem muitos scripts na internet que:

param serviços;
removem caches;
alteram Registro;
registram DLLs;
resetam Winsock;
alteram proxy;
renomeiam pastas;
modificam políticas.

Alguns podem funcionar em determinados casos.

O problema é usar um script desse tipo antes de saber qual camada está falhando.

Um script pode apagar a evidência

Se você limpa:

cache;
estado;
logs;

antes de investigar, pode perder pistas importantes.

Portanto:

diagnostique antes de limpar.

Diagnóstico técnico não precisa ser complicado

O princípio continua simples:

Qual operação falhou?

Qual componente executava essa operação?

Qual foi o primeiro erro relevante?

Qual evidência confirma a hipótese?

Fluxo da família 0x8024xxxx

Erro 0x8024xxxx

↓

Registrar KB + horário

↓

WindowsUpdate.log

↓

Encontrar operação

↓

Encontrar primeiro erro relevante

↓

É rede?

→ voltar para 0x80072xxx

É arquivo/permissão?

→ investigar 0x800700xx

É servicing?

→ CBS.log

É Component Store?

→ família 0x800Fxxxx / 0x800737xx

É aplicabilidade?

→ versão/build/arquitetura/requisitos

É política?

→ gerenciamento/GPResult

É estado do agente?

→ investigar Windows Update Agent

↓

corrigir a causa

↓

testar novamente

↓

validar Histórico + build.

Erros 0x800Fxxxx e 0x800737xx: CBS, Component Store, WinSxS, DISM e falhas de servicing

Até aqui analisamos três grandes grupos:

0x800700xx

0x80072xxx

0x8024xxxx

Agora chegamos a uma área fundamental para compreender os erros mais difíceis do Windows Update:

o servicing do Windows.

É aqui que aparecem muitos erros começando por:

0x800F

0x800737

Para entender esses códigos corretamente, precisamos abandonar uma ideia muito comum:

“se a atualização falhou, então o download está corrompido”.

Nem sempre.

O download pode ter terminado perfeitamente.

O problema pode começar somente quando o Windows tenta incorporar os componentes da atualização ao sistema.

Download e instalação são etapas diferentes

Imagine:

Windows Update encontra a KB

↓

baixa os arquivos

↓

valida o conteúdo

↓

prepara o pacote

↓

servicing começa

↓

CBS processa componentes

↓

Component Store participa

↓

arquivos e componentes são atualizados

↓

reinicialização

↓

operações restantes são concluídas.

Uma falha nas últimas etapas não significa necessariamente problema de internet.

O que é servicing?

Servicing é o conjunto de mecanismos utilizados pelo Windows para manter componentes do próprio sistema.

Isso envolve operações como:

instalar atualizações;
adicionar componentes;
remover componentes;
processar pacotes;
manter versões de componentes;
reparar a imagem;
aplicar alterações.

Um componente central desse processo é:

CBS — Component Based Servicing.

O que é CBS?

CBS significa:

Component Based Servicing.

Quando uma atualização começa a modificar componentes do Windows, CBS pode registrar informações extremamente importantes sobre a operação.

Seu principal log fica em:

C:\Windows\Logs\CBS\CBS.log

CBS.log é um dos arquivos mais importantes deste guia

Se o Windows Update:

encontra;
baixa;
começa a instalar;

e depois falha, CBS.log pode ser muito mais útil do que simplesmente limpar SoftwareDistribution.

Como abrir CBS.log?

O arquivo pode ser grande.

Uma opção é copiá-lo para a Área de Trabalho antes de analisá-lo.

Em Prompt de Comando elevado:

copy C:\Windows\Logs\CBS\CBS.log "%userprofile%\Desktop\CBS.txt"

Dependendo do estado do arquivo, pode ser necessário analisar também os logs rotacionados existentes no diretório.

Não procure somente “Error”

Procure:

código;
KB;
pacote;
horário;
Failed;
componente envolvido.

Depois leia o contexto.

O que é Component Store?

O Windows mantém um armazenamento de componentes.

Ele fica associado ao diretório:

C:\Windows\WinSxS

Mas WinSxS não deve ser entendido simplesmente como:

“pasta de arquivos antigos”.

Ele é parte fundamental da arquitetura de manutenção do Windows.

Por que Component Store existe?

Entre outras funções, ele permite ao Windows:

manter componentes;
instalar atualizações;
ativar recursos;
reparar arquivos;
gerenciar versões;
realizar servicing.

Por isso, WinSxS não é uma pasta que devemos limpar manualmente.

Nunca apague WinSxS manualmente

Não:

assuma propriedade;
dê Controle Total;
exclua subpastas;
utilize scripts que apagam arquivos arbitrariamente.

Você pode economizar espaço momentaneamente e quebrar:

Windows Update;
DISM;
recursos opcionais;
servicing;
futuras atualizações.

DISM entra justamente aqui

DISM significa:

Deployment Image Servicing and Management.

É uma ferramenta essencial para trabalhar com imagens do Windows e operações de servicing.

No sistema atualmente em execução usamos:

/Online

CheckHealth

Comando:

DISM /Online /Cleanup-Image /CheckHealth

Esse comando verifica se a imagem já está marcada como corrompida e se o problema é considerado reparável.

É uma verificação rápida.

ScanHealth

Comando:

DISM /Online /Cleanup-Image /ScanHealth

Executa uma análise mais completa do Component Store.

Pode levar mais tempo.

RestoreHealth

Comando:

DISM /Online /Cleanup-Image /RestoreHealth

Tenta reparar a imagem.

Mas existe uma diferença importante:

RestoreHealth precisa obter os arquivos necessários ao reparo.

E é justamente aí que alguns erros 0x800F aparecem.

Erro 0x800F081F

Um dos códigos mais conhecidos:

0x800F081F

Associado a:

CBS_E_SOURCE_MISSING

Em termos simples:

os arquivos de origem necessários não puderam ser encontrados.

O que isso não significa

Não significa simplesmente:

“Windows está corrompido”.

Também não significa:

“formate o computador”.

Significa que determinada operação precisava de conteúdo que não estava disponível na origem utilizada.

Exemplo conceitual

Imagine que DISM detectou um componente que precisa ser reparado.

Ele sabe:

qual componente precisa ser corrigido.

Mas não possui uma cópia válida necessária para realizar o reparo.

Resultado possível:

0x800F081F

Windows Update pode funcionar como fonte de reparo

Em determinados cenários, DISM pode utilizar o Windows Update para obter conteúdo necessário.

Mas isso cria uma situação interessante.

Se o próprio Windows Update está com problema, a fonte automática de reparo também pode não funcionar.

É aqui que /Source se torna importante

Podemos especificar uma fonte de reparo compatível.

Exemplo conceitual:

DISM /Online /Cleanup-Image /RestoreHealth /Source:CAMINHO_DA_FONTE /LimitAccess

Mas existe um detalhe crítico:

a fonte precisa ser compatível.

Não use qualquer ISO

Esse é um dos maiores erros em tutoriais.

Baixar uma ISO aleatória do Windows 11 e apontar DISM para ela não garante reparação.

Precisamos considerar:

edição;
arquitetura;
versão;
build;
idioma;
conteúdo disponível;
nível de atualização.

Descubra sua versão

Execute:

winver

Depois:

DISM /Online /Get-CurrentEdition

Get-ComputerInfo | Select-Object WindowsProductName,WindowsVersion,OsBuildNumber,OsArchitecture

install.wim ou install.esd

Uma mídia do Windows pode conter:

sources\install.wim

ou:

sources\install.esd

Esses arquivos podem conter múltiplas edições.

Portanto, precisamos descobrir o índice correto.

Ver índices de install.wim

Exemplo:

DISM /Get-WimInfo /WimFile:D:\sources\install.wim

Se a mídia utilizar ESD:

DISM /Get-WimInfo /WimFile:D:\sources\install.esd

Não escolha índice pelo número

Não suponha:

índice 6 sempre é Windows Pro.

Consulte a mídia.

Exemplo de fonte WIM

Depois de identificar o índice adequado, uma sintaxe pode seguir o formato:

DISM /Online /Cleanup-Image /RestoreHealth /Source:wim:D:\sources\install.wim:INDICE /LimitAccess

Para ESD:

DISM /Online /Cleanup-Image /RestoreHealth /Source:esd:D:\sources\install.esd:INDICE /LimitAccess

Substitua:

INDICE

pelo índice correto da mídia.

O que /LimitAccess faz?

/LimitAccess

impede que DISM tente utilizar Windows Update como fonte online durante aquela operação.

Isso é útil quando queremos controlar explicitamente a origem.

Mas não use /LimitAccess sempre

Se a fonte local não possui tudo que o reparo precisa, impedir acesso a fontes online pode fazer a operação falhar.

Novamente:

comando depende do cenário.

CBS.log no 0x800F081F

Quando aparece:

0x800F081F

procure no CBS.log o componente ou pacote que não encontrou a origem necessária.

Isso pode fornecer informações muito mais úteis do que repetir RestoreHealth.

Erro 0x800F0831

Outro código extremamente importante:

0x800F0831

Está relacionado a uma situação em que CBS não consegue resolver corretamente um pacote necessário, frequentemente por dependência/manifests ausentes no contexto de servicing.

O que significa na prática?

Uma atualização pode depender de componentes ou informações que o sistema espera encontrar.

Se essa cadeia está incompleta, a instalação pode falhar.

Não trate 0x800F0831 como simples download quebrado

Se o Windows Update já baixou a KB e CBS começa a reclamar de dependências, estamos em outra camada.

Procure no:

CBS.log

Procure referências a pacotes

Queremos identificar:

pacote;
dependência;
manifesto;
atualização relacionada.

Atualizações cumulativas e dependências

O modelo moderno de atualização reduziu muitos problemas antigos de fragmentação, mas servicing ainda depende de um estado coerente do Component Store.

Por isso, uma máquina que passou por:

atualizações interrompidas;
limpeza agressiva;
modificações;
ferramentas de terceiros;

pode apresentar problemas difíceis de diagnosticar.

Erro 0x800F0900

Código:

0x800F0900

Associado a:

CBS_E_XML_PARSER_FAILURE

Isso indica falha ao processar dados XML utilizados pelo servicing.

Aqui novamente metadados/manifests importam

Se CBS não consegue interpretar corretamente as informações necessárias, a instalação pode parar.

Não é necessariamente:

DNS;
roteador;
velocidade da internet.

Primeiro passo

Abra:

C:\Windows\Logs\CBS\CBS.log

Procure:

800F0900

Analise o contexto.

DISM pode ajudar?

Sim, se a falha estiver relacionada à integridade do Component Store.

Comece com:

DISM /Online /Cleanup-Image /CheckHealth

Depois:

DISM /Online /Cleanup-Image /ScanHealth

RestoreHealth somente quando fizer sentido

Se ScanHealth detectar corrupção reparável:

DISM /Online /Cleanup-Image /RestoreHealth

Se RestoreHealth falhar, investigue:

DISM.log

CBS.log

Erro 0x800F0906

Código:

0x800F0906

Está relacionado à impossibilidade de obter os arquivos necessários para completar determinada operação.

Esse código pode aparecer durante reparação ou instalação de componentes.

Compare 0x800F081F e 0x800F0906

Ambos podem envolver dificuldade de obter conteúdo necessário.

Mas não trate os dois códigos como sinônimos perfeitos.

Analise:

operação;
fonte;
política;
conectividade;
CBS.log;
DISM.log.

Política pode controlar fontes de reparo

Em ambientes corporativos, a obtenção de conteúdo para recursos opcionais e reparo pode ser controlada por política.

Isso significa que uma máquina pode ter internet funcionando e mesmo assim não poder obter conteúdo diretamente da fonte que você espera.

Não remova política empresarial

Primeiro:

gpresult /r

Se a máquina é gerenciada, investigue a configuração prevista pelo administrador.

Erro 0x800F0922

Este é um código muito conhecido:

0x800F0922

Mas ele exige cuidado.

Muitos tutoriais associam esse código automaticamente a:

“partição EFI sem espaço”.

Isso pode acontecer em determinados cenários.

Mas o código não deve ser reduzido a uma única causa.

0x800F0922 pode ter diferentes contextos

Precisamos descobrir:

atualização;
fase;
CBS.log;
partições;
operação que falhou.

Quando investigar partições?

Se os logs e o contexto apontam para uma operação relacionada à partição de sistema ou boot, aí sim examinamos a estrutura.

Execute:

diskmgmt.msc

Ou em PowerShell:

Get-Partition

Get-Volume

Não redimensione a EFI por impulso

Alterar partições de sistema é uma operação sensível.

Não faça isso simplesmente porque:

0x800F0922

apareceu.

Primeiro confirme que o espaço ou estrutura da partição realmente é a causa.

VPN e conectividade podem aparecer em alguns cenários

Dependendo da operação e do ambiente, conectividade também pode participar.

Por isso, novamente:

CBS.log + contexto

antes de alterar partições.

Erro 0x800F0988

Código:

0x800F0988

É outro erro encontrado durante servicing de determinadas atualizações.

Ele pode envolver problemas ao processar componentes/pacotes durante a instalação.

Não existe uma solução universal segura baseada apenas no código.

CBS.log é obrigatório no diagnóstico técnico

Procure:

800F0988

Depois observe:

pacote;
componente;
operação;
mensagens anteriores.

Não remova pacotes aleatoriamente

Alguns tutoriais sugerem listar pacotes e começar a remover itens.

Isso é perigoso.

Você pode criar:

dependências quebradas;
rollback impossível;
falhas futuras;
Component Store inconsistente.

DISM /Get-Packages é diagnóstico

Execute:

DISM /Online /Get-Packages

Esse comando pode ajudar a visualizar pacotes e estados.

Mas:

Get-Packages

é muito diferente de:

Remove-Package.

Consultar é uma coisa.

Remover é outra.

Erro 0x800F0991 e outros códigos recentes

Novos códigos podem aparecer conforme o servicing evolui.

Por isso, este guia precisa ensinar algo mais duradouro do que simplesmente decorar uma lista.

Quando encontrar um código 0x800F que não esteja listado aqui:

registre o código completo;
registre KB;
registre horário;
abra CBS.log;
identifique operação;
identifique pacote/componente;
procure a definição oficial do código;
só então escolha a reparação.

Agora entramos na família 0x800737xx

Essa família também é extremamente importante para Component Store e servicing.

Um dos códigos mais conhecidos é:

0x80073712

Erro 0x80073712

Código:

0x80073712

Associado a:

ERROR_SXS_COMPONENT_STORE_CORRUPT

Em termos simples:

o Component Store apresenta corrupção/inconsistência que impede determinada operação.

Esse código é mais específico

Compare:

0x80240022

todas as atualizações falharam

com:

0x80073712

problema relacionado ao Component Store.

O segundo direciona muito melhor a investigação.

Primeiro passo para 0x80073712

Execute:

DISM /Online /Cleanup-Image /CheckHealth

Depois:

DISM /Online /Cleanup-Image /ScanHealth

Se corrupção for reparável

Use:

DISM /Online /Cleanup-Image /RestoreHealth

Depois, quando o DISM terminar corretamente:

sfc /scannow

Por que DISM antes de SFC em determinados cenários?

SFC verifica e repara arquivos protegidos do Windows.

Mas a fonte utilizada para determinados reparos depende do estado do sistema.

Se o Component Store está corrompido, reparar primeiro a imagem pode ser uma sequência lógica.

Isso significa sempre DISM antes de SFC?

Não transforme isso em outra regra cega.

A sequência depende do problema.

Mas em um cenário explicitamente relacionado ao Component Store, faz sentido verificar primeiro a integridade da imagem.

Erro 0x80073701

Código:

0x80073701

Associado a:

ERROR_SXS_ASSEMBLY_MISSING

Em termos simplificados:

um assembly necessário não foi encontrado.

O que é assembly nesse contexto?

Sem entrar excessivamente na arquitetura interna, podemos pensar em conjuntos/componentes que o servicing espera encontrar para completar determinada operação.

Se algo necessário está ausente, a instalação pode falhar.

CBS.log novamente

Procure:

80073701

O objetivo é descobrir:

qual assembly ou componente está ausente?

Não baixe DLL individual da internet

Essa recomendação é fundamental.

Se CBS indica componente ausente, não procure o nome da DLL em sites aleatórios e copie para:

System32

ou:

WinSxS.

Isso pode:

introduzir versão incorreta;
quebrar assinatura;
criar incompatibilidade;
comprometer segurança.

Repare pelo mecanismo de servicing

Quando o Component Store está envolvido, use mecanismos suportados:

DISM;
fonte compatível;
Windows Update;
mídia correta;
reparação in-place quando necessária.

Erro 0x8007370A

Código:

0x8007370A

Está associado a um erro de identidade inválida em contexto Side-by-Side.

Novamente estamos em uma camada muito diferente de rede.

Erro 0x8007370B

Outro código relacionado a identidade Side-by-Side.

Esses códigos reforçam por que:

família do erro importa.

Erro 0x8007370D

Pode indicar identidade malformada no contexto Side-by-Side.

A análise deve se concentrar em:

CBS;
Component Store;
manifests;
identidade de componentes.

Erro 0x8007371B

Código:

0x8007371B

Está relacionado a uma transação SxS que não possui todos os membros necessários.

Isso novamente aponta para consistência do servicing.

Erro 0x8007371C

Também pertence à família de erros Side-by-Side e deve ser analisado dentro do contexto de componentes e transações.

Tabela 0x800Fxxxx

Código	Significado resumido	Primeira investigação
0x800F081F	Origem necessária ausente	CBS.log + fonte de reparo
0x800F0831	Dependência/pacote necessário ausente	CBS.log + pacotes
0x800F0900	Falha de processamento XML	CBS.log + Component Store
0x800F0906	Arquivos necessários não puderam ser obtidos	Fonte/política/rede
0x800F0922	Falha de servicing com múltiplos cenários possíveis	CBS.log + contexto + partições quando indicado
0x800F0988	Falha ao processar componentes/pacotes	CBS.log

Tabela 0x800737xx

Código	Significado resumido	Primeira investigação
0x80073701	Assembly necessário ausente	CBS.log
0x8007370A	Identidade SxS inválida	CBS/Component Store
0x8007370B	Problema de identidade SxS	CBS/Component Store
0x8007370D	Identidade SxS malformada	CBS/manifests
0x80073712	Component Store corrompido	DISM + CBS.log
0x8007371B	Transação SxS incompleta	CBS.log
0x8007371C	Problema de transação SxS	CBS.log

Como analisar Component Store corretamente

Comece:

DISM /Online /Cleanup-Image /AnalyzeComponentStore

Esse comando fornece informações sobre o armazenamento de componentes.

Mas atenção:

tamanho grande não significa corrupção.

WinSxS grande não significa problema

O tamanho exibido pelo Explorador pode ser enganoso por causa da forma como o Windows utiliza hard links.

Portanto, não use:

Propriedades da pasta WinSxS

como diagnóstico definitivo de espaço consumido.

AnalyzeComponentStore não é ScanHealth

São comandos diferentes.

AnalyzeComponentStore

analisa características do armazenamento, inclusive limpeza recomendada.

ScanHealth

procura corrupção na imagem.

Não confunda.

StartComponentCleanup

Existe também:

DISM /Online /Cleanup-Image /StartComponentCleanup

Esse comando realiza limpeza suportada de componentes substituídos quando apropriado.

Mas:

limpeza não é a mesma coisa que reparação.

Essa distinção é fundamental

StartComponentCleanup

→ manutenção/limpeza.

ScanHealth

→ diagnóstico de integridade.

RestoreHealth

→ reparação.

Não utilize um esperando o resultado do outro.

ResetBase

Existe um parâmetro mais agressivo relacionado à limpeza de componentes substituídos.

Mas ele pode alterar a possibilidade de desinstalar determinadas atualizações existentes.

Portanto, não deve ser tratado como:

“modo turbo de limpeza”.

Para troubleshooting comum, evite utilizá-lo sem uma razão clara e entendimento das consequências.

E se RestoreHealth chegar a 100% e falhar?

O percentual não significa:

reparo concluído com sucesso.

A mensagem final importa.

Anote:

código;
mensagem;
horário.

Depois consulte:

C:\Windows\Logs\DISM\dism.log

C:\Windows\Logs\CBS\CBS.log

DISM falhou com 0x800F081F

Agora temos uma sequência:

Windows Update falha

↓

ScanHealth detecta problema

↓

RestoreHealth tenta reparar

↓

0x800F081F

Nesse momento, repetir RestoreHealth não cria magicamente a fonte ausente.

Precisamos fornecer ou restaurar acesso a uma fonte válida.

Fonte local incompatível também pode falhar

Imagine:

Windows instalado:

edição A, arquitetura x64, determinado idioma e estado de servicing.

Mídia utilizada:

outra edição/versão/conteúdo incompatível.

DISM pode não conseguir usar essa origem como esperado.

Não procure apenas “mesma versão do Windows 11”

Precisamos verificar mais detalhes.

Reparação in-place

Quando:

Component Store está seriamente comprometido;
DISM não consegue reparar;
fonte adequada não resolve;
servicing permanece quebrado;

uma reparação in-place pode se tornar uma alternativa.

O que é reparação in-place?

É uma reinstalação do Windows sobre a instalação existente utilizando procedimento suportado, com opção de preservar aplicativos e arquivos quando o cenário permite.

Ela pode reconstruir componentes do sistema sem exigir imediatamente uma instalação limpa.

Reparação in-place não é formatação

Essa diferença é importante.

Instalação limpa:

normalmente substitui o ambiente anterior.

Reparação in-place:

procura reparar o sistema mantendo o ambiente quando a opção é suportada.

Faça backup antes

Mesmo procedimentos projetados para preservar dados envolvem alterações importantes no sistema operacional.

Faça backup dos dados importantes antes.

Não pule diretamente para in-place repair

Primeiro:

identifique código;
analise CBS.log;
verifique Component Store;
tente reparação suportada;
verifique fonte;
valide resultado.

A reparação in-place entra quando métodos menos invasivos não resolvem ou quando o estado do sistema justifica.

Quando Windows Update baixa 100% e depois falha

Esse cenário agora começa a fazer sentido.

Se:

download = 100%

instalação = falha

não continue focando apenas em:

DNS;
Wi-Fi;
velocidade;
roteador.

Olhe para:

CBS;
Component Store;
pacote;
servicing;
espaço;
operações pendentes.

Quando falha durante reinicialização

A investigação pode envolver outra fase.

Algumas alterações só podem ser aplicadas fora da sessão normal do Windows.

Nesse caso, logs de servicing e Setup podem ganhar importância.

Mais adiante entraremos nos erros de upgrade e fases como:

SAFE_OS;
FIRST_BOOT;
SECOND_BOOT.

Como correlacionar WindowsUpdate.log com CBS.log

Imagine:

WindowsUpdate.log:

14:32 — instalação iniciada

Depois:

14:34 — instalação falhou

Agora vá ao CBS.log.

Procure:

14:32–14:34

Esse método é muito melhor do que pesquisar aleatoriamente milhares de linhas.

Procure o primeiro erro significativo

Pode existir uma sequência:

Warning

↓

Failed to resolve package

↓

CBS_E_SOURCE_MISSING

↓

0x800F081F

↓

Windows Update reports failure

O primeiro erro técnico relevante pode explicar todos os demais.

Não limpe os logs antes do diagnóstico

Se você apagar logs para:

“começar do zero”

pode eliminar justamente a evidência necessária.

Preserve-os primeiro.

Faça cópia dos logs

Crie uma pasta:

C:\DiagnosticoWU

Depois copie arquivos relevantes para análise.

Por exemplo:

mkdir C:\DiagnosticoWU

copy C:\Windows\Logs\CBS\CBS.log C:\DiagnosticoWU\CBS.txt

copy C:\Windows\Logs\DISM\dism.log C:\DiagnosticoWU\DISM.txt

Gere WindowsUpdate.log também

PowerShell:

Get-WindowsUpdateLog -LogPath C:\DiagnosticoWU\WindowsUpdate.log

Agora temos uma base para correlacionar os eventos.

Método VMIA para erros de servicing

Passo 1

Anote:

KB + código + horário.

Passo 2

Confirme:

winver

Passo 3

Determine se o download terminou.

Passo 4

Analise:

WindowsUpdate.log

Passo 5

Se a falha entrou em servicing:

CBS.log

Passo 6

Verifique Component Store:

DISM /Online /Cleanup-Image /CheckHealth

Passo 7

Quando necessário:

DISM /Online /Cleanup-Image /ScanHealth

Passo 8

Se houver corrupção reparável:

DISM /Online /Cleanup-Image /RestoreHealth

Passo 9

Se RestoreHealth falhar:

pare e investigue o código.

Passo 10

Analise:

DISM.log

CBS.log.

Passo 11

Se a origem estiver ausente, investigue uma fonte compatível.

Passo 12

Depois do reparo:

sfc /scannow

quando apropriado.

Passo 13

Reinicie.

Passo 14

Teste Windows Update.

Passo 15

Confirme Histórico e build.

O que não fazer com 0x800Fxxxx e 0x800737xx

Não:

apague WinSxS;
altere permissões de WinSxS;
baixe DLLs de sites desconhecidos;
copie manifests aleatoriamente;
remova pacotes sem entender dependências;
execute Remove-Package por tentativa;
utilize ISO incompatível;
escolha índice WIM por suposição;
execute RestoreHealth repetidamente sem analisar a falha;
apague CBS.log antes do diagnóstico;
use ResetBase sem entender as consequências;
force atualização que não se aplica.

Fluxo de diagnóstico desta família

Windows Update baixou?

↓

Sim

↓

Falhou ao instalar?

↓

Registrar código e horário

↓

CBS.log

↓

Código 0x800F/0x800737?

↓

Identificar pacote/componente

↓

CheckHealth

↓

ScanHealth

↓

Corrupção?

Não

Investigue pacote/KB/operação específica.

Sim

↓

RestoreHealth

↓

Funcionou?

Sim

↓

SFC quando apropriado

↓

reiniciar

↓

Windows Update

↓

validar

Não

↓

Qual código DISM retornou?

↓

CBS.log + DISM.log

↓

fonte ausente?

↓

fonte compatível

↓

reparar

↓

testar novamente

↓

se servicing continuar irrecuperável → avaliar reparação in-place.

Erros 0xC1900101: drivers, rollback, SAFE_OS, FIRST_BOOT, SECOND_BOOT e SetupDiag

Até agora analisamos principalmente erros encontrados durante:

detecção;
comunicação;
download;
instalação de atualizações;
servicing;
Component Store.

Agora entramos em uma categoria diferente:

falhas durante upgrade do Windows.

É o cenário em que o computador tenta instalar uma nova versão ou atualização de recursos, reinicia várias vezes e, em algum momento, algo dá errado.

Depois aparece uma mensagem parecida com:

Não foi possível instalar o Windows.

Ou o computador retorna para a versão anterior.

Entre os códigos mais conhecidos está:

0xC1900101

Mas esse número sozinho raramente conta toda a história.

O que significa 0xC1900101?

De maneira prática, 0xC1900101 é um código genérico de rollback frequentemente associado a problemas de driver durante o processo de upgrade.

A palavra mais importante aqui é:

genérico.

O código aponta uma direção.

Ele não informa necessariamente:

qual driver provocou a falha.

Não conclua “driver de vídeo”

Quando alguém vê:

0xC1900101

é comum encontrar recomendações para:

atualizar driver de vídeo;
remover driver de vídeo;
instalar outro driver de vídeo.

Mas o driver responsável pode pertencer a outra categoria.

Por exemplo:

armazenamento;
chipset;
rede;
áudio;
USB;
Bluetooth;
controladores;
filtros de software;
dispositivos virtuais.

Portanto:

0xC1900101 ≠ driver de vídeo especificamente.

A segunda parte do código é extremamente importante

Você pode encontrar algo como:

0xC1900101 - 0x20017

ou:

0xC1900101 - 0x30018

ou:

0xC1900101 - 0x40017

Agora temos muito mais informação.

A primeira parte indica a classe geral da falha.

A segunda ajuda a identificar:

em qual fase/operação o Setup encontrou o problema.

Windows Setup trabalha em fases

Um upgrade não acontece como uma única operação contínua.

O processo atravessa diferentes fases.

Entre os nomes que podem aparecer nos logs estão:

DOWNLEVEL;
SAFE_OS;
FIRST_BOOT;
SECOND_BOOT.

Compreender essas fases ajuda muito.

DOWNLEVEL

É uma fase executada enquanto o sistema operacional anterior ainda está funcionando.

Durante esse período, o Setup pode:

preparar arquivos;
analisar compatibilidade;
obter conteúdo;
preparar migração;
organizar o upgrade.

Se o processo falha aqui, ainda estamos antes das principais reinicializações do novo ambiente.

SAFE_OS

Depois o Setup entra em uma fase conhecida como:

SAFE_OS

É um ambiente utilizado para realizar determinadas operações necessárias ao upgrade antes que o novo Windows seja iniciado normalmente.

Problemas nessa fase podem envolver diferentes componentes.

FIRST_BOOT

Depois temos:

FIRST_BOOT

O Windows atualizado começa a inicializar e processar operações necessárias ao novo ambiente.

Drivers tornam-se particularmente importantes.

SECOND_BOOT

Mais adiante temos:

SECOND_BOOT

Nessa fase o sistema continua configurando componentes e concluindo etapas do upgrade.

Fase e operação não são exatamente a mesma coisa

Além da fase, o erro pode indicar uma operação.

Exemplos:

BOOT;
INSTALL_DRIVERS;
MIGRATE_DATA;
SYSPREP;
PREPARE_ROLLBACK.

Portanto, um diagnóstico completo tenta responder:

em qual fase?

durante qual operação?

Exemplo: 0xC1900101 – 0x20017

Esse tipo de combinação pode aparecer quando o upgrade falha durante:

SAFE_OS

em uma operação relacionada ao boot.

Isso já é muito mais útil do que simplesmente:

0xC1900101.

O que investigar?

Agora começamos a considerar:

drivers de armazenamento;
controladores;
BIOS/UEFI;
dispositivos;
software de baixo nível;
filtros;
configuração de boot;
hardware.

Mas ainda precisamos dos logs.

Exemplo: 0xC1900101 – 0x30018

Essa combinação costuma direcionar a investigação para uma falha durante:

FIRST_BOOT

em uma operação relacionada a drivers/dispositivos.

Nesse cenário, drivers merecem atenção especial.

Não atualize todos os drivers de uma vez

Esse é um erro de diagnóstico.

Se você troca:

chipset;
vídeo;
áudio;
rede;
Bluetooth;
armazenamento;

simultaneamente e o upgrade passa, não sabe qual era a causa.

Prefira uma investigação baseada nos logs.

Exemplo: 0xC1900101 – 0x40017

Esse tipo de erro pode ocorrer durante:

SECOND_BOOT

e exige investigação do que estava sendo configurado quando ocorreu o rollback.

Mais uma vez:

logs.

Onde ficam os logs do Windows Setup?

Um dos locais importantes é:

C:\$WINDOWS.~BT\Sources\Panther

Essa pasta normalmente é oculta.

setupact.log

Um arquivo extremamente importante:

setupact.log

Ele registra grande quantidade de informações sobre as ações realizadas pelo Windows Setup.

setuperr.log

Outro arquivo:

setuperr.log

Ele reúne erros encontrados durante o processo.

Mas existe um detalhe importante.

Não analise somente setuperr.log

O arquivo pode mostrar o erro.

Mas:

setupact.log

frequentemente fornece o contexto necessário para compreender o que estava acontecendo antes da falha.

Portanto:

setuperr.log + setupact.log

é uma combinação muito melhor.

Procure pelo horário do rollback

Se o computador tentou atualizar às 02:00 e retornou à versão anterior às 02:37, concentre a análise nesse período.

Isso reduz muito a quantidade de informação.

Outros diretórios de log podem existir

Dependendo da fase, logs podem aparecer em locais diferentes durante e após o upgrade.

Por isso, uma ferramenta como SetupDiag pode ajudar a correlacionar informações.

O que é SetupDiag?

SetupDiag é uma ferramenta da Microsoft desenvolvida para analisar logs do Windows Setup e tentar identificar regras conhecidas relacionadas a falhas de upgrade.

Em vez de ler manualmente milhares de linhas, ela pode encontrar padrões conhecidos.

SetupDiag não é um reparador

Isso é importante.

SetupDiag:

analisa.

Ele não é um botão:

“corrigir upgrade”.

Seu resultado ajuda a descobrir a causa.

Resultado do SetupDiag

Dependendo do problema, o resultado pode apontar para:

driver;
aplicativo;
compatibilidade;
armazenamento;
dispositivo;
operação;
fase;
código.

Use esse resultado como evidência para aprofundar o diagnóstico.

Não pare na frase “driver problem”

Se SetupDiag indicar um driver, descubra:

nome;
arquivo .sys;
dispositivo;
fornecedor;
versão;
data;
função.

SetupAPI.dev.log

Outro log muito importante para problemas de drivers:

C:\Windows\INF\setupapi.dev.log

Ele registra operações relacionadas à instalação de dispositivos e drivers.

Procure pelo driver identificado

Se SetupDiag ou setupact.log apontar para:

exemplo.sys

podemos procurar esse arquivo no contexto do sistema.

Não delete .sys manualmente

Nunca encontre:

driverproblematico.sys

e simplesmente apague de:

C:\Windows\System32\drivers

Isso pode impedir o Windows de iniciar.

O procedimento correto é identificar:

qual pacote de driver instalou esse arquivo.

PnPUtil

Uma ferramenta extremamente útil:

pnputil /enum-drivers

Ela lista pacotes de drivers de terceiros presentes no Driver Store.

Informações úteis

Podemos encontrar:

Published Name;
Original Name;
Provider Name;
Class Name;
Driver Version;
Signer Name.

Essas informações ajudam a identificar pacotes antigos ou suspeitos.

Driver antigo não significa driver culpado

Uma data antiga isoladamente não prova problema.

Alguns drivers perfeitamente funcionais podem utilizar datas que parecem antigas.

Precisamos correlacionar com:

dispositivo;
log;
erro;
comportamento.

Como identificar um driver

Podemos utilizar:

driverquery /v

Ou PowerShell:

Get-CimInstance Win32_PnPSignedDriver | Select-Object DeviceName,DriverVersion,DriverProviderName,InfName

Isso cria uma visão útil dos drivers instalados.

Salve a lista antes do upgrade

Uma prática interessante:

pnputil /enum-drivers > "%userprofile%\Desktop\drivers-antes-upgrade.txt"

Agora temos um inventário.

Drivers de armazenamento merecem atenção

Um upgrade precisa continuar acessando o disco durante diferentes fases.

Drivers relacionados a:

SATA;
AHCI;
RAID;
NVMe;
controladores proprietários;

podem ter impacto significativo.

Não altere AHCI/RAID na BIOS aleatoriamente

Trocar:

RAID → AHCI

ou:

AHCI → RAID

sem preparar o Windows pode provocar:

INACCESSIBLE_BOOT_DEVICE

e impedir a inicialização.

Portanto, não use isso como tentativa aleatória para corrigir 0xC1900101.

BIOS e UEFI

Firmware também pode influenciar upgrades.

Verifique:

msinfo32

Observe:

fabricante;
modelo;
versão/data da BIOS;
modo BIOS.

Atualizar BIOS resolve 0xC1900101?

Pode ser relevante quando existe:

correção de compatibilidade;
problema conhecido;
firmware muito antigo;
recomendação do fabricante.

Mas:

0xC1900101 não significa automaticamente “atualize a BIOS”.

Firmware exige cuidado

Uma atualização de BIOS/UEFI interrompida pode tornar o equipamento inutilizável.

Siga apenas o procedimento oficial do fabricante e confirme o modelo exato.

Periféricos USB

Dispositivos externos também podem interferir em determinados upgrades.

Entre eles:

adaptadores USB;
discos externos;
docks;
interfaces;
dispositivos especializados.

Teste mínimo de hardware externo

Quando o log não identifica claramente o culpado, pode ser útil realizar o upgrade mantendo conectados apenas os dispositivos essenciais.

Por exemplo:

teclado;
mouse;
monitor;
armazenamento interno necessário.

Não desconecte dispositivos essenciais ao sistema

Em ambientes específicos, determinados dispositivos podem ser necessários.

Use julgamento técnico.

Antivírus de terceiros

Produtos de segurança podem instalar:

filtros;
drivers;
componentes de rede;
serviços de baixo nível.

Isso significa que podem participar de problemas de upgrade.

Mas não significa:

0xC1900101 = antivírus.

Desativar pode não remover o driver

Esse é um detalhe importante.

Clicar em:

Desativar proteção

pode interromper a interface de proteção, mas filtros e drivers do produto podem continuar carregados.

Quando existe evidência clara de incompatibilidade, pode ser necessário utilizar o procedimento oficial do fornecedor para remoção.

Backup antes

Antes de remover software de segurança ou alterar drivers:

salve dados importantes;
tenha acesso aos instaladores necessários;
confirme credenciais quando aplicável.

Softwares de virtualização

Ferramentas de virtualização podem instalar:

adaptadores virtuais;
filtros de rede;
drivers;
dispositivos virtuais.

Se os logs apontam para esses componentes, investigue.

VPN também pode instalar drivers

Clientes VPN podem adicionar:

filtros;
adaptadores;
drivers de rede.

Portanto, um problema atribuído genericamente a:

“rede”

pode na verdade estar em um driver de filtro.

Software de backup

Algumas soluções de backup, snapshot e proteção de disco também utilizam drivers de baixo nível.

Se o upgrade falha em fases específicas, esses componentes podem merecer análise.

Criptografia de disco

Se existe:

BitLocker;
criptografia de terceiros;

o cenário precisa ser analisado com cuidado.

BitLocker

Antes de alterações importantes, confirme:

estado da proteção;
chave de recuperação;
método utilizado.

Execute:

manage-bde -status

Não desative BitLocker sem entender o motivo

Em alguns procedimentos pode ser necessário suspender temporariamente a proteção.

Suspender é diferente de descriptografar completamente.

Mas faça isso somente quando o procedimento realmente exigir.

Tenha a chave de recuperação

Antes de mudanças em:

firmware;
TPM;
boot;
partições;

confirme que a chave de recuperação está disponível.

Espaço em disco

Upgrades exigem espaço para:

download;
preparação;
arquivos temporários;
nova instalação;
migração;
rollback.

Execute:

Get-Volume

Espaço livre em C: não conta toda a história

Também podem existir:

partição EFI;
partição de recuperação;
System Reserved.

Não altere essas partições sem evidência.

Verifique o layout

PowerShell:

Get-Partition

Ou:

diskmgmt.msc

Não exclua partição de recuperação para ganhar espaço

Ela pode ser necessária para:

WinRE;
recuperação;
manutenção.

Se existe problema relacionado ao tamanho da partição, resolva especificamente esse problema.

WinRE

Verifique:

reagentc /info

Observe se:

Windows RE status

está habilitado e qual é a localização.

Por que WinRE pode importar?

Algumas atualizações e operações podem depender da infraestrutura de recuperação.

Além disso, alterações de partições podem afetá-la.

Drivers incompatíveis versus drivers desnecessários

Imagine que o computador já utilizou:

impressora antiga;
adaptador Wi-Fi antigo;
placa de captura antiga;
VPN removida;
hardware que não existe mais.

Pacotes desses drivers podem permanecer no Driver Store.

Isso não significa que devemos apagar todos.

Mas um pacote antigo pode se tornar relevante se os logs apontarem para ele.

Driver Store

O Driver Store é uma área gerenciada pelo Windows.

Não delete arquivos manualmente de:

C:\Windows\System32\DriverStore\FileRepository

Use PnPUtil

Para listar:

pnputil /enum-drivers

Para operações de remoção, somente depois de identificar corretamente o pacote e confirmar que não é necessário.

Não transforme PnPUtil em ferramenta de limpeza

A finalidade não é:

“remover todos os drivers antigos”.

É:

gerenciar pacotes de drivers de maneira controlada.

Dispositivos ocultos

Gerenciador de Dispositivos pode mostrar dispositivos que não estão conectados naquele momento.

Mas novamente:

dispositivo oculto não significa problema.

Não remova todos indiscriminadamente.

Clean boot pode ajudar?

Uma inicialização limpa pode ajudar a reduzir interferências de serviços e aplicativos de terceiros.

Mas ela não remove necessariamente drivers de baixo nível.

Por isso:

clean boot não elimina todas as possíveis causas de 0xC1900101.

Como fazer um teste controlado

Em vez de mudar vinte coisas:

registre o erro;
execute SetupDiag;
analise logs;
identifique suspeito;
altere uma variável;
tente novamente;
compare.

Rollback é uma proteção

Quando o upgrade falha e o Windows retorna para a versão anterior, isso pode ser frustrante.

Mas o rollback existe para evitar que uma instalação incompleta deixe o computador inutilizável.

Não tente impedir rollback

O objetivo não é:

“forçar o Windows a permanecer na nova versão”.

O objetivo é:

descobrir por que a nova versão não conseguiu completar a instalação.

Logs depois do rollback

Depois que o Windows retorna à versão anterior, preserve os logs antes de iniciar limpezas agressivas.

Esse é um momento valioso para diagnóstico.

Não execute Limpeza de Disco imediatamente

Se você acabou de sofrer um rollback e pretende investigar, não saia apagando:

instalações anteriores;
arquivos temporários de instalação;
logs;
$WINDOWS.~BT.

Esses arquivos podem conter evidências.

Pasta $WINDOWS.~BT

Ela pode conter:

arquivos do Setup;
logs;
dados necessários para análise.

Não a remova antes de coletar o diagnóstico.

SetupDiag primeiro

Após rollback:

anote o código;
anote a combinação completa;
preserve $WINDOWS.~BT;
execute SetupDiag;
analise setupact.log;
analise setuperr.log;
investigue drivers quando indicado.

Como interpretar combinações de erro

Imagine:

0xC1900101 - 0x30018

Não pesquise apenas:

0xC1900101.

Pesquise e analise:

código completo + fase + operação.

Isso reduz drasticamente o universo de hipóteses.

Fase SAFE_OS

Quando o problema ocorre em SAFE_OS, pergunte:

qual operação?
boot?
aplicação da imagem?
recuperação?
driver?

Fase FIRST_BOOT

Quando ocorre em FIRST_BOOT, investigue:

inicialização;
drivers;
dispositivos;
migração;
serviços.

Fase SECOND_BOOT

Quando ocorre em SECOND_BOOT, investigue:

configuração final;
migração;
drivers;
aplicações;
serviços.

MIGRATE_DATA

Uma operação relacionada a migração pode envolver:

perfis;
dados;
configurações;
aplicativos.

Não é automaticamente um problema de driver.

INSTALL_DRIVERS

Quando o próprio erro aponta para:

INSTALL_DRIVERS

a investigação de drivers ganha prioridade.

SYSPREP

Falhas relacionadas a:

SYSPREP

podem envolver preparação e configuração do sistema durante as fases finais.

Procure o erro específico anterior nos logs.

BOOT

Quando a operação é:

BOOT

investigue componentes necessários à inicialização.

Entre eles:

driver de armazenamento;
boot;
firmware;
filtros;
dispositivos.

Não confunda fase com causa

SAFE_OS

não é a causa.

É:

onde a falha aconteceu.

BOOT

também não diz sozinho:

qual componente falhou.

Precisamos dos logs.

Compatibilidade de aplicativos

Nem todos os upgrades falham por driver.

Aplicativos incompatíveis também podem bloquear ou interromper um upgrade.

Verifique avisos do Setup

Antes da instalação, o Windows pode identificar softwares que exigem:

atualização;
remoção;
ação manual.

Não ignore essas mensagens.

Não contorne bloqueios de compatibilidade sem entender

Um bloqueio pode existir porque a Microsoft ou o fabricante identificou uma incompatibilidade conhecida.

Forçar o upgrade pode introduzir:

instabilidade;
falha de dispositivo;
perda de funcionalidade.

Safeguard holds

Em determinados cenários, a Microsoft pode impedir temporariamente que uma atualização de versão seja oferecida a dispositivos com uma incompatibilidade conhecida.

Isso é diferente de:

Windows Update quebrado.

Se a nova versão não aparece

Antes de tentar forçar:

confirme elegibilidade;
versão;
requisitos;
bloqueios conhecidos;
compatibilidade.

Upgrade Assistant e ISO

Instalar por outro método não elimina necessariamente uma incompatibilidade.

Se Windows Update bloqueia por um motivo válido, utilizar outra mídia pode apenas contornar o mecanismo de distribuição sem corrigir o problema subjacente.

SetupDiag versus DISM

Não confunda as funções.

DISM

Trabalha com servicing e imagem.

SetupDiag

Analisa falhas do Windows Setup.

Portanto:

0x80073712

pode levar você para DISM/CBS.

Enquanto:

0xC1900101-0x30018

provavelmente exige SetupDiag/logs do Setup/drivers.

SetupDiag versus SFC

SFC verifica arquivos protegidos do sistema.

Ele não é uma ferramenta para identificar:

qual driver provocou rollback durante FIRST_BOOT.

SetupDiag versus CHKDSK

CHKDSK analisa o sistema de arquivos/volume.

Ele não é uma ferramenta genérica para diagnosticar todas as falhas de upgrade.

Use cada ferramenta para a pergunta correta.

Tabela de diagnóstico dos 0xC1900101

Código/combinação	Contexto resumido	Primeira investigação
0xC1900101	Rollback frequentemente relacionado a driver	SetupDiag + Setup logs
0xC1900101-0x20017	Falha em SAFE_OS/boot em cenários conhecidos	Boot, drivers, firmware, logs
0xC1900101-0x30018	Falha em FIRST_BOOT em cenário de driver/dispositivo	SetupDiag + drivers
0xC1900101-0x3000D	Falha durante FIRST_BOOT/migração em cenário correspondente	Migração + drivers + logs
0xC1900101-0x40017	Falha durante SECOND_BOOT	Drivers/configuração/logs

A combinação precisa sempre ser confirmada nos logs.

Outros erros de upgrade

Nem toda falha de upgrade começa por:

0xC1900101.

Existem outros códigos importantes.

0xC1900200

Esse código pode indicar que o computador não atende aos requisitos necessários para o upgrade.

Nesse cenário:

reparar Windows Update não resolve requisitos de hardware.

Verifique requisitos reais

Não suponha qual requisito falhou.

Pode envolver:

processador;
memória;
armazenamento;
firmware;
recursos de segurança;
requisitos específicos da versão.

0xC1900208

Esse código pode estar associado a incompatibilidade detectada durante o processo de upgrade.

Aplicativos ou componentes incompatíveis podem estar envolvidos.

Não force antes de identificar

Procure nos logs e relatórios de compatibilidade qual elemento está bloqueando.

0xC1900209

Também pode aparecer quando existem problemas de compatibilidade que exigem ação do usuário.

Mais uma vez:

identifique o aplicativo ou componente.

0xC1900210

Em determinados contextos, esse resultado indica que não foram encontrados problemas de compatibilidade bloqueadores.

Portanto, novamente:

nem todo código começando por C190 representa falha catastrófica.

0x80070070 durante upgrade

Lembra da Parte 1?

Esse erro indicava espaço insuficiente.

Ele também pode aparecer durante upgrade.

Isso mostra como as famílias se cruzam.

Um upgrade pode mostrar vários códigos

Exemplo conceitual:

Windows Setup:

0xC1900101-0x30018

Setup log:

erro relacionado a determinado driver.

SetupAPI:

falha ao instalar dispositivo.

Agora temos uma cadeia coerente.

Outro exemplo

Windows Setup:

0x80070070

Agora o problema pode ser simplesmente espaço insuficiente em determinado volume.

Não há motivo para começar removendo drivers.

Outro exemplo

Setup:

0xC1900208

Relatório de compatibilidade aponta um aplicativo.

Nesse caso, Component Store pode estar perfeitamente saudável.

O objetivo é encontrar coerência entre evidências

Bom diagnóstico produz uma história técnica coerente.

Por exemplo:

upgrade entrou em FIRST_BOOT

↓

tentou instalar determinado dispositivo

↓

driver falhou

↓

Setup não conseguiu continuar

↓

rollback ocorreu

↓

0xC1900101.

Isso é muito melhor do que:

“rodei 15 comandos e depois funcionou”.

Inventário antes do upgrade

Em máquinas problemáticas, salve informações antes da próxima tentativa.

Drivers:

pnputil /enum-drivers > "%userprofile%\Desktop\drivers.txt"

Informações do sistema:

systeminfo > "%userprofile%\Desktop\systeminfo.txt"

Partições:

PowerShell:

Get-Partition | Format-Table -AutoSize

Volumes:

Get-Volume | Format-Table -AutoSize

BitLocker:

manage-bde -status

WinRE:

reagentc /info

Verifique integridade antes de tentar novamente

Quando existem sinais de corrupção:

DISM /Online /Cleanup-Image /ScanHealth

Depois, conforme o resultado:

DISM /Online /Cleanup-Image /RestoreHealth

sfc /scannow

Não execute reparações sem motivo

Se SetupDiag identificou claramente um driver incompatível e o Component Store está saudável, não precisamos transformar o diagnóstico em uma maratona de comandos.

Resolva primeiro o problema identificado.

Atualize driver ou remova?

Depende.

Se existe uma versão compatível mais recente:

atualizar

pode ser adequado.

Se o dispositivo não existe mais e o pacote problemático permanece:

remover corretamente

pode fazer sentido.

Se o dispositivo é necessário e não existe driver compatível:

não force o upgrade sem avaliar as consequências.

De onde obter drivers?

Prefira:

Windows Update quando apropriado;
fabricante do computador;
fabricante do componente.

Evite pacotes de drivers de procedência desconhecida.

Programas “Driver Updater”

Ferramentas genéricas que prometem atualizar todos os drivers podem instalar versões inadequadas.

Durante troubleshooting de upgrade, isso adiciona ainda mais variáveis.

Notebook exige cuidado especial

Fabricantes podem personalizar:

energia;
gráficos;
áudio;
touchpad;
sensores;
chipset;
firmware.

Um driver “mais novo” diretamente do fabricante do chip nem sempre é automaticamente a melhor opção para aquele notebook.

Backup completo antes de nova tentativa

Se o computador contém dados importantes, faça backup antes do upgrade.

Não confie no rollback como única estratégia de recuperação.

Depois de corrigir o suspeito

Faça nova tentativa.

Mas antes:

preserve o diagnóstico anterior;
registre a alteração realizada;
reinicie;
confirme o estado;
execute novamente o upgrade;
compare o resultado.

Se o código mudar

Isso pode ser informação útil.

Imagine:

Primeira tentativa:

0xC1900101-0x30018

Depois de corrigir um driver:

segunda tentativa:

0x80070070

Isso pode indicar que superamos uma etapa e encontramos outro problema.

Não significa necessariamente que a primeira correção foi inútil.

Troubleshooting é iterativo

Podemos ter:

problema A

↓

corrigido

↓

processo avança

↓

encontra:

problema B.

Isso é normal em sistemas com múltiplas inconsistências.

Quando considerar reparação in-place antes do upgrade?

Se a instalação atual apresenta:

servicing quebrado;
arquivos corrompidos;
Windows Update constantemente falhando;
Component Store problemático;

pode fazer sentido reparar primeiro o sistema atual.

Depois tente o upgrade.

Quando considerar instalação limpa?

Instalação limpa pode ser considerada quando:

sistema está profundamente comprometido;
reparações suportadas falham;
upgrade continua impossível;
usuário possui backup;
reinstalação de aplicativos é aceitável.

Mas ela não deve ser a primeira resposta para qualquer 0xC1900101.

Checklist para 0xC1900101

Antes da próxima tentativa:

anote código completo;
identifique fase;
identifique operação;
preserve $WINDOWS.~BT;
execute SetupDiag;
analise setupact.log;
analise setuperr.log;
verifique setupapi.dev.log quando houver driver;
liste drivers com PnPUtil;
verifique periféricos;
verifique software de baixo nível;
verifique espaço;
verifique partições;
confirme WinRE;
confirme BitLocker/chave de recuperação;
verifique firmware quando houver indicação;
faça backup;
altere apenas o necessário;
tente novamente;
compare os logs.

O que não fazer com 0xC1900101

Não:

atualize todos os drivers indiscriminadamente;
apague arquivos .sys;
limpe DriverStore manualmente;
altere AHCI/RAID por tentativa;
atualize BIOS sem confirmar modelo;
remova partições;
desligue segurança permanentemente;
force upgrade bloqueado sem investigar;
apague $WINDOWS.~BT antes de coletar logs;
execute limpeza agressiva imediatamente após rollback;
conclua que qualquer 0xC1900101 é placa de vídeo.

Fluxo de diagnóstico

Upgrade falhou

↓

anotar código completo

↓

houve rollback?

↓

preservar logs

↓

SetupDiag

↓

qual fase?

↓

qual operação?

↓

driver indicado?

Sim

↓

identificar pacote/dispositivo

↓

setupapi.dev.log + PnPUtil

↓

atualizar/remover corretamente quando apropriado

Não

↓

verificar outro bloqueador

↓

aplicativo?

espaço?

partição?

firmware?

servicing?

compatibilidade?

↓

corrigir somente a causa identificada

↓

backup

↓

nova tentativa

↓

comparar resultado.

A grande diferença entre Windows Update e Windows Setup

Esse conceito fecha esta parte.

Se uma atualização cumulativa falha:

podemos estar principalmente no universo:

Windows Update Agent + CBS + Component Store.

Quando um upgrade de versão falha e faz rollback:

entramos também no universo:

Windows Setup + fases de instalação + migração + drivers + compatibilidade.

Por isso:

não utilize o mesmo roteiro de troubleshooting para todos os tipos de atualização.

Erros de espaço, EFI, System Reserved, Recovery e WinRE no Windows Update

Existe uma mensagem que parece simples:

não há espaço suficiente para instalar a atualização.

A primeira reação costuma ser abrir:

Este Computador

e olhar a unidade:

C:

Se existem dezenas de gigabytes disponíveis, surge a dúvida:

“Como pode faltar espaço se meu SSD ainda tem espaço livre?”

A resposta é:

o Windows não utiliza somente C: durante todas as operações de atualização.

Dependendo da atualização e da configuração do computador, outras partições podem participar do processo.

Entre elas:

EFI System Partition;
System Reserved;
Recovery Partition;
partição do Windows;
partições utilizadas pelo Windows Recovery Environment.

É por isso que erros aparentemente simples de armazenamento podem exigir um diagnóstico muito mais cuidadoso.

Primeiro: não altere nenhuma partição

Antes de continuar, uma regra importante.

Não:

exclua partições;
formate EFI;
aumente Recovery por tentativa;
atribua letras e apague arquivos aleatórios;
utilize clean no DiskPart;
converta GPT/MBR;
mude o tipo da partição;
copie arquivos de boot manualmente.

Partições de sistema são áreas sensíveis.

Uma alteração errada pode transformar:

“Windows Update não instala”

em:

“Windows não inicia”.

Erro 0x80070070

Código:

0x80070070

Esse código está relacionado a:

espaço insuficiente em disco.

Parece simples.

Mas a primeira pergunta precisa ser:

em qual volume?

Não suponha que seja C:

Comece com PowerShell:

Get-Volume

Observe:

letra;
sistema de arquivos;
tamanho;
espaço restante.

Veja também as partições

Execute:

Get-Partition

Isso permite visualizar partições que talvez nem possuam letra de unidade.

Por que uma partição pode não possuir letra?

Partições internas utilizadas pelo sistema normalmente não precisam aparecer como:

D:

E:

ou:

F:

Elas podem permanecer ocultas no Explorador e ainda participar de operações importantes.

Abra Gerenciamento de Disco

Execute:

diskmgmt.msc

Observe cuidadosamente o layout.

Você pode encontrar algo parecido com:

EFI

Windows (C:)

Recovery

A estrutura varia conforme:

modo de instalação;
fabricante;
histórico do computador;
upgrades anteriores;
clonagens;
particionamento.

Não existe um único layout universal

Dois computadores com Windows 11 podem possuir layouts diferentes.

Por exemplo:

PC A

EFI → C: → Recovery

PC B

EFI → Recovery → C: → Recovery antiga

PC C

System Reserved → C:

Isso pode ocorrer devido a:

instalação antiga;
upgrade;
migração;
clonagem;
alterações anteriores;
ferramentas de fabricantes.

EFI System Partition

Em sistemas UEFI/GPT, existe normalmente uma:

EFI System Partition

ou:

ESP.

Ela armazena arquivos utilizados pelo firmware para iniciar sistemas operacionais.

EFI não é espaço de armazenamento comum

Não trate essa partição como uma pequena unidade onde podemos simplesmente excluir arquivos para ganhar espaço.

Ela pode conter:

boot manager;
arquivos de inicialização;
dados relacionados ao boot;
arquivos utilizados por outros sistemas instalados.

Não formate a EFI

Mesmo que pareça quase vazia ou muito pequena.

Formatá-la pode impedir o computador de iniciar.

System Reserved

Em determinadas instalações, especialmente em layouts legados ou originados de versões anteriores do Windows, podemos encontrar:

System Reserved.

Essa partição também pode participar de operações relacionadas ao boot.

EFI e System Reserved não são exatamente a mesma coisa

Não use os nomes como sinônimos.

A estrutura depende principalmente do modo de boot e do particionamento.

GPT e MBR

Em sistemas modernos com UEFI, GPT é comum.

Podemos verificar informações do disco com PowerShell:

Get-Disk

Observe:

Partition Style

Você pode encontrar:

GPT

ou:

MBR.

Não converta apenas porque GPT é mais moderno

Se o computador está funcionando, não execute conversões de particionamento como tentativa de corrigir Windows Update.

Conversões envolvem:

boot;
firmware;
partições;
recuperação.

Faça somente quando existe um projeto técnico específico e backup adequado.

Recovery Partition

Outra partição muito importante é a:

Recovery Partition.

Ela pode armazenar o Windows Recovery Environment.

Também conhecido como:

WinRE.

O que é WinRE?

WinRE significa:

Windows Recovery Environment.

É o ambiente utilizado para ferramentas de recuperação.

Ele pode fornecer recursos como:

Reparo de Inicialização;
Prompt de Comando;
restauração;
opções avançadas;
recuperação do sistema.

Descubra o estado do WinRE

Execute como administrador:

reagentc /info

Procure:

Windows RE status

Você pode encontrar:

Enabled

ou:

Disabled.

Veja também a localização

O resultado pode indicar a localização do ambiente de recuperação.

Essa informação é extremamente útil antes de mexer em qualquer partição.

Não conclua que “Disabled” significa partição quebrada

WinRE desabilitado pode ter diferentes causas.

Precisamos investigar:

configuração;
localização;
imagem de recuperação;
partição;
histórico do computador.

Por que Recovery ganhou tanta importância?

Algumas atualizações relacionadas ao ambiente de recuperação podem precisar modificar conteúdo dentro da partição correspondente.

Se ela não possui espaço adequado para a operação, a atualização pode falhar.

C: pode ter 500 GB livres e Recovery continuar sem espaço

Esse é exatamente o tipo de cenário que confunde usuários.

Imagine:

500 GB livres

Recovery:

quase sem espaço interno

A atualização que precisa modificar WinRE pode falhar.

Portanto:

espaço total do SSD não é igual a espaço disponível em cada partição.

Como saber se o problema realmente é Recovery?

Não comece redimensionando.

Primeiro:

identifique a KB;
identifique o código;
consulte a documentação da atualização;
verifique WinRE;
examine o layout;
analise logs.

Erro 0x800F0922 novamente

Na Parte 4 vimos:

0x800F0922

Esse código pode aparecer em diferentes cenários.

Um deles pode envolver problemas relacionados a partições necessárias durante servicing.

Mas:

0x800F0922 não significa automaticamente EFI cheia.

Essa simplificação é perigosa

Pesquisar:

0x800F0922

e imediatamente redimensionar a EFI é uma péssima estratégia.

Primeiro descubra:

qual operação falhou?

CBS.log

Abra:

C:\Windows\Logs\CBS\CBS.log

Procure:

800F0922

Analise as linhas anteriores.

Se o log aponta para boot/partição

Agora sim investigamos:

EFI;
System Reserved;
Recovery;
WinRE;
espaço;
estrutura.

Se o log aponta para outra coisa

Não mexa em partições.

Espaço temporário durante atualização

Atualizações podem precisar de muito mais espaço do que o tamanho final instalado.

Isso ocorre porque o processo pode envolver:

download;
descompactação;
staging;
cópias temporárias;
rollback;
instalação nova;
manutenção de componentes.

Exemplo conceitual

Uma atualização pode ter:

4 GB de download

mas exigir temporariamente muito mais espaço durante a instalação.

Portanto:

tamanho do download ≠ espaço máximo necessário.

Quanto espaço livre preciso?

Não existe um único número universal adequado para todos os cenários.

Depende de:

tipo de atualização;
build;
arquitetura;
conteúdo;
espaço temporário;
estado do sistema;
rollback.

Prefira consultar os requisitos específicos da atualização ou do upgrade.

Storage Sense

O Windows possui:

Sensor de Armazenamento

ou:

Storage Sense.

Ele pode ajudar a gerenciar arquivos temporários.

Mas configure conscientemente.

Configurações de Armazenamento

Abra:

Configurações → Sistema → Armazenamento

Analise as categorias.

Isso é muito melhor do que apagar pastas do Windows manualmente.

Arquivos temporários

Abra:

Arquivos temporários

Leia cada categoria antes de selecionar.

Atenção a Downloads

Dependendo da configuração e versão do Windows, categorias relacionadas a arquivos pessoais podem aparecer em ferramentas de limpeza.

Não marque tudo automaticamente.

Windows.old

Depois de determinados upgrades pode existir:

C:\Windows.old

Essa pasta pode consumir muitos gigabytes.

Windows.old é lixo?

Não necessariamente.

Ela pode participar da possibilidade de retornar à instalação anterior durante o período suportado.

Antes de remover Windows.old

Pergunte:

preciso da possibilidade de rollback?

Se sim, não remova apenas para recuperar espaço.

Não apague Windows.old manualmente

Prefira mecanismos suportados de limpeza do Windows.

SoftwareDistribution também ocupa espaço

Caminho:

C:\Windows\SoftwareDistribution

Pode conter dados utilizados pelo Windows Update.

Mas, novamente:

pasta grande não significa pasta descartável.

Delivery Optimization

O cache de Otimização de Entrega também pode ocupar espaço.

Use as ferramentas do próprio Windows para gerenciar esse conteúdo.

WinSxS

Já discutimos:

C:\Windows\WinSxS

Não apague manualmente.

Analise Component Store

Use:

DISM /Online /Cleanup-Image /AnalyzeComponentStore

Se houver indicação apropriada para limpeza suportada:

DISM /Online /Cleanup-Image /StartComponentCleanup

Não confunda espaço com corrupção

Um Component Store grande não significa:

Component Store corrompido.

E um Component Store corrompido não significa necessariamente:

ele está grande.

São problemas diferentes.

Pagefile

Outro arquivo grande pode ser:

pagefile.sys

Ele participa da memória virtual.

Não desative simplesmente para ganhar espaço para Windows Update.

Por quê?

A paginação pode ser necessária para:

gerenciamento de memória;
estabilidade;
dumps;
determinados aplicativos.

Se espaço está crítico, investigue primeiro o que está ocupando o volume.

hiberfil.sys

Outro arquivo grande:

hiberfil.sys

Está relacionado a recursos como:

hibernação;
Inicialização Rápida, dependendo da configuração.

Posso apagar hiberfil.sys?

Não apague manualmente.

O arquivo é gerenciado pelo sistema.

Alterações na hibernação devem ser realizadas através das configurações/comandos adequados e apenas quando o usuário entende a consequência.

Restore Points

Pontos de restauração também podem consumir espaço.

Abra:

SystemPropertiesProtection

Veja:

proteção;
utilização;
configuração.

Não desative proteção apenas para liberar espaço

Pontos de restauração podem ser úteis justamente quando uma atualização cria problemas.

Avalie antes de remover.

Reserved Storage

O Windows também pode utilizar:

Armazenamento Reservado.

Ele existe para ajudar a manter espaço disponível para determinadas operações do sistema, incluindo atualizações.

Reserved Storage não é lixo

Não tente remover mecanismos do sistema simplesmente porque aparecem consumindo espaço.

O objetivo é garantir que o sistema consiga manter e atualizar seus componentes.

Quando o disco está realmente cheio

Imagine:

C: possui:

1,2 GB livres.

Nesse cenário, antes de investigar Component Store profundamente, faz sentido resolver a falta de espaço.

Comece pelo que é seguro

Prioridade:

arquivos pessoais grandes;
downloads;
vídeos;
ISOs;
instaladores;
aplicativos não utilizados;
temporários gerenciados pelo Windows;
caches suportados.

Não comece pelas pastas do sistema

Evite começar apagando:

WinSxS;
Installer;
DriverStore;
System32;
SoftwareDistribution;
Recovery.

Use um analisador de armazenamento com cuidado

Ferramentas que mostram o tamanho das pastas podem ajudar a localizar consumo.

Mas existe uma regra:

ferramenta de análise mostra onde está o espaço; não decide o que é seguro apagar.

Hard links podem confundir

Especialmente em WinSxS, ferramentas podem contabilizar arquivos de forma que o usuário interprete incorretamente o espaço exclusivo consumido.

Por isso:

não some tamanhos de pastas do Windows e conclua que o SSD deveria ter aquele espaço livre.

E se a partição Recovery estiver realmente pequena?

Agora chegamos a um cenário delicado.

Se:

KB exige alteração em WinRE;
logs apontam para Recovery;
reagentc /info confirma o ambiente;
partição não possui espaço suficiente;

pode ser necessário modificar o particionamento.

Mas isso exige planejamento

Antes:

backup;
confirmar BitLocker;
salvar chave de recuperação;
identificar disco;
identificar partições;
confirmar WinRE;
confirmar posição física das partições;
compreender o procedimento.

Por que a posição da partição importa?

Imagine:

EFI | C: | Recovery

Se precisamos aumentar Recovery utilizando espaço proveniente de C:, o espaço não alocado precisa estar em uma posição que permita a operação pretendida.

Partições não podem simplesmente crescer através de outra partição sem reorganização.

Gerenciamento de Disco possui limitações

O Gerenciamento de Disco do Windows não consegue realizar todas as movimentações de partição possíveis.

Isso não significa que devemos imediatamente instalar qualquer particionador de terceiros.

Primeiro entenda o layout.

DiskPart

DiskPart é extremamente poderoso.

Execute:

diskpart

Depois:

list disk

list volume

list partition

Esses comandos de listagem são úteis para diagnóstico.

Cuidado extremo com DiskPart

Comandos como:

clean

delete partition

format

podem destruir dados ou tornar o sistema não inicializável.

Não os utilize apenas seguindo uma lista encontrada na internet.

Listar é diferente de modificar

Durante diagnóstico, prefira:

list disk

list volume

list partition

antes de qualquer ação destrutiva.

BitLocker antes de mexer em partições

Execute:

manage-bde -status

Confirme se existe proteção ativa.

Chave de recuperação

Se BitLocker estiver ativo, certifique-se de que a chave de recuperação está disponível antes de alterar:

boot;
firmware;
TPM;
partições.

Não confie que “nunca pediu a chave antes”

Mudanças na cadeia de boot podem fazer o BitLocker solicitar recuperação.

Múltiplas partições Recovery

Alguns computadores possuem mais de uma partição de recuperação.

Isso pode acontecer após upgrades.

Qual delas está sendo usada?

Não adivinhe pela posição.

Use:

reagentc /info

para identificar a localização configurada do WinRE.

Não apague a Recovery “antiga” apenas porque parece duplicada

Primeiro confirme:

qual está ativa;
o que existe na outra;
se o fabricante utiliza alguma partição;
se existe dependência.

OEM Recovery

Computadores de fabricantes podem possuir partições adicionais para:

restauração de fábrica;
diagnóstico;
ferramentas OEM.

Não confunda essas partições com a Recovery padrão do Windows.

Atualização de WinRE

Algumas atualizações podem modificar:

winre.wim

Se não existe espaço suficiente na partição correspondente, a atualização pode encontrar problemas.

Onde está winre.wim?

A localização é gerenciada pelo Windows e pode estar associada à partição de recuperação.

Não copie ou substitua manualmente sem um procedimento técnico específico.

reagentc

Alguns comandos disponíveis incluem:

reagentc /info

reagentc /enable

reagentc /disable

Mas:

não fique alternando enable/disable como tentativa aleatória.

Desabilitar WinRE altera o estado do sistema

Faça isso somente quando um procedimento de reparação específico exigir e você souber como restaurar corretamente.

E se Recovery estiver ausente?

O computador pode continuar iniciando normalmente, mas determinadas funções de recuperação podem não estar disponíveis.

Precisamos verificar:

reagentc /info

e o layout.

Não crie uma Recovery aleatoriamente

Criar corretamente uma infraestrutura WinRE envolve mais do que:

“criar uma partição NTFS de 1 GB”.

Existem:

tipo de partição;
atributos;
caminho;
imagem;
configuração do ReAgent.

Erro de espaço durante upgrade

Quando uma atualização de versão falha por espaço, também preserve os logs.

O Windows Setup pode fornecer informações mais específicas.

SetupDiag pode ajudar

Se houve rollback:

preserve $WINDOWS.~BT;
execute SetupDiag;
analise setupact.log;
procure erros relacionados a espaço ou partições.

Não limpe $WINDOWS.~BT antes do diagnóstico

A pasta pode ocupar bastante espaço.

Mas se o upgrade acabou de falhar e você quer descobrir a causa, ela pode conter os logs de que precisamos.

Depois do diagnóstico

Quando você não precisa mais dos logs e não existe necessidade de rollback, utilize mecanismos suportados para limpeza.

Cenário 1 — C: realmente cheio

Sintoma:

0x80070070

C: possui pouquíssimo espaço.

Primeira ação:

liberar espaço de maneira segura.

Cenário 2 — C: tem espaço, mas atualização continua acusando falta

Investigue:

qual volume;
Recovery;
EFI/System Reserved;
logs;
atualização específica.

Cenário 3 — atualização de WinRE falha

Verifique:

reagentc /info

e o espaço/estrutura da partição de recuperação.

Cenário 4 — upgrade falha e faz rollback

Use:

SetupDiag;
setupact.log;
setuperr.log;
informações das partições.

Cenário 5 — 0x800F0922

Não redimensione nada ainda.

Primeiro:

CBS.log;
KB;
operação;
contexto.

Cenário 6 — SSD quase cheio depois do Windows Update

Investigue:

temporários;
Windows.old;
Delivery Optimization;
SoftwareDistribution;
Component Store;
arquivos pessoais.

Não conclua automaticamente que a atualização está “vazando espaço”.

Como registrar o layout antes de qualquer alteração

PowerShell:

Get-Disk | Format-Table -AutoSize

Depois:

Get-Partition | Format-Table -AutoSize

Depois:

Get-Volume | Format-Table -AutoSize

Salve o resultado.

Exporte para arquivo

Exemplo:

Get-Disk | Format-Table -AutoSize | Out-File "$env:USERPROFILE\Desktop\discos.txt"

Get-Partition | Format-Table -AutoSize | Out-File "$env:USERPROFILE\Desktop\particoes.txt"

Get-Volume | Format-Table -AutoSize | Out-File "$env:USERPROFILE\Desktop\volumes.txt"

Agora você possui um registro antes das alterações.

Registre WinRE

Execute:

reagentc /info > "%userprofile%\Desktop\winre.txt"

Registre BitLocker

Execute:

manage-bde -status > "%userprofile%\Desktop\bitlocker.txt"

Esses registros podem ser muito úteis.

Tabela de áreas de armazenamento

Área	Função resumida	Apagar manualmente?
C:	Windows, aplicativos e dados	Somente conteúdo identificado
EFI	Inicialização UEFI	Não
System Reserved	Boot em determinados layouts	Não
Recovery	Recuperação/WinRE	Não
Windows.old	Instalação anterior/rollback	Use limpeza suportada
SoftwareDistribution	Estado/cache do Windows Update	Somente procedimento controlado
WinSxS	Component Store	Nunca manualmente
DriverStore	Pacotes de drivers	Nunca manualmente
Delivery Optimization	Cache de distribuição	Use mecanismos suportados
Temporários	Arquivos temporários	Use ferramentas do Windows

Tabela de comandos

Objetivo	Comando
Ver volumes	`Get-Volume`
Ver partições	`Get-Partition`
Ver discos	`Get-Disk`
Abrir Gerenciamento de Disco	`diskmgmt.msc`
Ver WinRE	`reagentc /info`
Ver BitLocker	`manage-bde -status`
Ver Component Store	`DISM /Online /Cleanup-Image /AnalyzeComponentStore`
Limpeza suportada de componentes	`DISM /Online /Cleanup-Image /StartComponentCleanup`
Ver layout pelo DiskPart	`diskpart` + comandos `list`

Fluxo de diagnóstico de espaço

Windows Update informa falta de espaço

↓

anotar código

↓

Get-Volume

↓

C: está realmente cheio?

Sim

↓

liberar espaço de maneira suportada

↓

testar novamente

Não

↓

Get-Partition

↓

qual atualização está falhando?

↓

envolve WinRE/boot/partição?

↓

reagentc /info

↓

analisar Recovery/EFI/System Reserved

↓

CBS.log ou Setup logs

↓

confirmar partição problemática

↓

backup + BitLocker + chave de recuperação

↓

somente então planejar alteração de particionamento

↓

testar atualização

↓

validar WinRE e boot.

Depois de alterar uma partição

Se um procedimento técnico exigiu alteração de partições, não teste apenas:

“Windows iniciou”.

Verifique também:

reagentc /info

manage-bde -status

Get-Partition

Depois teste Windows Update.

Windows iniciar não prova que tudo está correto

Pode existir:

WinRE desabilitado;
Recovery desconectada;
BitLocker suspenso;
espaço não alocado desnecessário;
configuração incompleta.

Valide o estado final.

O que não fazer

Não:

formate EFI;
exclua Recovery por impulso;
execute diskpart clean;
altere GPT/MBR para testar;
copie boot files aleatoriamente;
desative BitLocker sem planejamento;
mexa em TPM sem a chave;
apague WinSxS;
apague DriverStore;
remova Windows.old sem avaliar rollback;
limpe $WINDOWS.~BT antes de investigar rollback;
redimensione EFI só porque apareceu 0x800F0922;
conclua que espaço em C: representa todo o armazenamento utilizado pelo Update.

Erros de assinatura, certificados, CryptSvc, catroot2 e validação criptográfica do Windows Update

Nas partes anteriores vimos que uma atualização pode falhar em diferentes camadas:

detecção

↓

comunicação

↓

download

↓

servicing

↓

Component Store

↓

upgrade

↓

partições e recuperação

Agora chegamos a outra etapa essencial:

confiança e validação criptográfica.

O Windows não deve simplesmente baixar um arquivo e instalá-lo.

Ele precisa verificar se determinado conteúdo pode ser considerado válido e confiável.

É aqui que entram conceitos como:

assinatura digital;
certificados;
cadeia de certificados;
catálogos;
hashes;
Cryptographic Services;
CryptSvc;
catroot2;
WinVerifyTrust;
CryptoAPI.

Quando essa validação falha, o Windows Update pode recusar o conteúdo.

Por que o Windows verifica assinaturas?

Imagine que o computador baixa um pacote.

Antes de utilizá-lo, o sistema precisa ter mecanismos para responder perguntas como:

o conteúdo está íntegro?

foi alterado?

a assinatura pode ser validada?

a cadeia de confiança é aceitável?

Sem esse tipo de verificação, seria muito mais difícil garantir a integridade do processo de atualização.

Hash e assinatura não são exatamente a mesma coisa

Esses conceitos costumam ser confundidos.

Um hash funciona como uma impressão digital matemática de determinado conteúdo.

Se o conteúdo muda, o resultado calculado também pode mudar.

A assinatura digital acrescenta mecanismos de autenticidade e confiança baseados em criptografia.

Em troubleshooting, uma falha pode ocorrer porque:

conteúdo não corresponde ao esperado;
assinatura não valida;
certificado não é confiável;
cadeia não pode ser construída corretamente;
informações necessárias à validação estão indisponíveis.

O que é CryptSvc?

No Windows existe o serviço:

Cryptographic Services

Nome do serviço:

CryptSvc

Podemos consultar:

sc query cryptsvc

Esse serviço participa de várias funções criptográficas do Windows.

STOPPED significa defeito?

Novamente:

não necessariamente.

Assim como vimos com outros serviços, precisamos interpretar o estado dentro do contexto.

Não altere automaticamente o tipo de inicialização apenas porque encontrou um serviço parado em determinado instante.

Veja a configuração do serviço

Execute:

sc qc cryptsvc

Esse comando mostra informações sobre a configuração.

Não configure todos os serviços como Automático

Muitos tutoriais utilizam a estratégia:

“coloque todos os serviços do Windows Update em Automático”.

Isso não é um método de diagnóstico.

Serviços modernos do Windows podem utilizar:

inicialização sob demanda;
gatilhos;
estados dinâmicos.

A pergunta correta é:

o serviço consegue iniciar quando necessário?

O que é catroot2?

Um diretório importante para operações criptográficas e Windows Update é:

C:\Windows\System32\catroot2

Ele participa do armazenamento de informações utilizadas em processos de validação e catálogos.

catroot e catroot2 são a mesma coisa?

Não.

Existe uma diferença importante entre:

catroot

catroot2.

Não saia renomeando ou apagando diretórios porque os nomes são parecidos.

Nunca apague catroot indiscriminadamente

Tutoriais podem dizer:

“apague catroot”.

Não faça isso.

Quando um procedimento técnico de Windows Update pede reconstrução, normalmente estamos falando especificamente de:

catroot2

e mesmo assim isso deve ocorrer dentro de um procedimento controlado.

Por que catroot2 aparece em tantos tutoriais?

Porque reconstruir seu estado pode ajudar em determinados problemas relacionados aos componentes do Windows Update e validação.

Mas isso criou um hábito ruim:

qualquer erro → renomear catroot2.

Essa lógica está errada.

Quando catroot2 começa a fazer sentido?

Quando temos evidências relacionadas a:

catálogos;
validação;
assinatura;
estado local inconsistente;
determinados erros persistentes do Windows Update.

Ainda assim, primeiro devemos coletar evidências.

Erro 0x80096010

Código:

0x80096010

Nome:

TRUST_E_BAD_DIGEST

Em termos simplificados:

a assinatura digital do objeto não pôde ser validada corretamente.

Esse código merece atenção porque aponta diretamente para a camada de confiança/integridade.

Não conclua imediatamente que existe malware

Uma assinatura inválida não prova infecção.

Existem outras possibilidades.

Por exemplo:

conteúdo incompleto;
arquivo alterado;
download inconsistente;
cache problemático;
falha de validação;
problema na cadeia de processamento.

Precisamos investigar.

Primeiro identifique o arquivo ou pacote

Não fique apenas no código:

0x80096010.

Pergunte:

qual objeto falhou na validação?

WindowsUpdate.log

Gere:

Get-WindowsUpdateLog

Procure:

80096010

Observe:

KB;
horário;
arquivo;
operação;
tentativa anterior.

CBS.log

Se a falha aconteceu durante servicing, consulte também:

C:\Windows\Logs\CBS\CBS.log

Procure pelo mesmo período.

Assinatura inválida pode ser consequência

Imagine:

download incompleto

↓

arquivo local inconsistente

↓

validação falha

↓

0x80096010

Nesse cenário, o erro criptográfico pode ser consequência do conteúdo incorreto.

Erro 0x800B0109

Código:

0x800B0109

Nome:

CERT_E_UNTRUSTEDROOT

Significa, de maneira resumida:

a cadeia de certificados termina em uma autoridade raiz que não é considerada confiável pelo provedor de confiança.

O que é cadeia de certificados?

Imagine uma estrutura:

certificado utilizado

↓

autoridade intermediária

↓

autoridade raiz

Para confiar no certificado final, o Windows precisa conseguir construir e validar adequadamente essa cadeia.

Raiz não confiável

Se a cadeia termina em uma raiz que o sistema não considera confiável, podemos encontrar:

0x800B0109.

Isso pode acontecer em ambientes empresariais

Empresas podem utilizar:

PKI própria;
certificados internos;
inspeção HTTPS;
proxies corporativos;
políticas de certificados.

Nesse ambiente, a raiz corporativa precisa estar distribuída corretamente conforme a arquitetura definida pela organização.

Não instale certificado aleatório

Esse ponto é extremamente importante.

Nunca procure na internet:

“certificado para corrigir 0x800B0109”

e instale um arquivo desconhecido como autoridade raiz.

Uma nova autoridade raiz confiável pode ampliar significativamente quem o computador passa a considerar confiável.

Certificados raiz são parte crítica da segurança

Adicionar uma raiz ao repositório:

Trusted Root Certification Authorities

não deve ser tratado como um ajuste trivial.

Primeiro descubra:

qual certificado está falhando;
quem deveria emiti-lo;
qual cadeia deveria existir;
se o computador é gerenciado;
se existe PKI corporativa.

Como abrir certificados do computador?

Execute:

certlm.msc

Isso abre o gerenciamento de certificados do computador local.

E certmgr.msc?

certmgr.msc

normalmente trabalha com certificados relacionados ao usuário atual.

Essa diferença importa.

Computador versus usuário

Um certificado instalado apenas para um usuário pode não estar disponível para determinado serviço executado no contexto do sistema.

Portanto:

“eu vejo o certificado”

não prova que o componente que precisa dele consegue utilizá-lo.

Não mova certificados entre stores por tentativa

Descubra primeiro qual store deveria conter o certificado.

CAPI2

Quando o problema envolve validação de certificados, existe outro log extremamente útil:

CAPI2 Operational.

Abra:

eventvwr.msc

Depois navegue pelo Visualizador de Eventos até os logs relacionados ao CAPI2.

Por que CAPI2 é importante?

Ele pode fornecer detalhes sobre operações de:

construção de cadeia;
validação;
certificados;
confiança;
revogação.

Quando aparece um erro como:

0x800B0109

o CAPI2 pode ajudar a descobrir qual cadeia falhou.

Correlacione horário novamente

Suponha:

Windows Update falhou:

18:42:15

Abra CAPI2 e procure eventos próximos desse horário.

Não analise indiscriminadamente todos os erros de certificado registrados nos últimos meses.

Build Chain

Em problemas de cadeia, eventos relacionados à construção da cadeia podem revelar:

certificado final;
intermediárias;
raiz;
resultado.

Verify Chain Policy

Outro tipo de evento pode mostrar falhas durante a verificação da política da cadeia.

Isso ajuda muito mais do que simplesmente saber:

“certificado não confiável”.

Erro 0x80096004

Outro código relacionado a confiança:

0x80096004

Nome:

TRUST_E_CERT_SIGNATURE

Em termos simplificados:

a assinatura do certificado não pôde ser verificada.

Erro 0x80096002

Código:

0x80096002

Nome:

TRUST_E_NO_SIGNER_CERT

Indica problema relacionado ao certificado do signatário necessário à validação.

Erro 0x80096003

Código:

0x80096003

Nome:

TRUST_E_COUNTER_SIGNER

Relaciona-se a uma contra-assinatura que não pôde ser considerada válida.

Erro 0x80096005

Código:

0x80096005

Nome:

TRUST_E_TIME_STAMP

Relaciona-se à validação da assinatura/certificado de timestamp.

Timestamp

Assinaturas digitais podem utilizar carimbo de tempo para registrar quando determinada assinatura ocorreu.

Isso é importante porque certificados possuem períodos de validade.

Data e hora entram novamente

Lembra do:

0x80072F8F?

Data e hora incorretas também podem afetar operações de confiança e comunicação segura.

Execute:

w32tm /query /status

E confira:

Get-Date

Fuso horário também importa

Um computador pode mostrar uma hora aparentemente próxima da correta e ainda possuir configuração inadequada.

Confira:

Configurações → Hora e idioma → Data e hora

Não altere hora manualmente em computador de domínio sem entender

Computadores ingressados em domínio podem seguir uma hierarquia de sincronização específica.

Investigue a origem antes.

Revogação

Certificados também podem possuir mecanismos para verificar se continuam válidos ou se foram revogados.

Falhas nesse processo podem produzir outros códigos.

0x80092012

Código:

0x80092012

Nome:

CRYPT_E_NO_REVOCATION_CHECK

Indica que a função de revogação não conseguiu realizar a verificação necessária.

Isso não significa automaticamente certificado revogado

Existe diferença entre:

não foi possível verificar revogação

certificado foi confirmado como revogado.

Não confunda.

Rede pode participar de uma falha criptográfica

Isso parece estranho inicialmente.

Mas se o Windows precisa alcançar recursos necessários à validação da cadeia ou revogação e a comunicação está bloqueada, podemos ter um erro que parece puramente criptográfico.

Proxy e firewall voltam ao diagnóstico

Portanto, dependendo do erro:

proxy;
firewall;
filtragem;
rede;

podem participar da falha.

Isso mostra novamente como as famílias do nosso guia se conectam.

Não desative verificação de revogação como “solução”

Reduzir mecanismos de segurança para fazer uma atualização passar não é uma correção adequada.

Descubra por que a verificação falha.

Erro 0x800B0100

Outro código conhecido:

0x800B0100

Está relacionado a:

TRUST_E_NOSIGNATURE

Em termos simplificados:

nenhuma assinatura válida estava presente no objeto analisado.

O que investigar?

arquivo;
pacote;
origem;
integridade;
cache;
catálogo;
logs.

Erro 0x800B0101

Esse código está relacionado a certificado fora do período de validade.

Isso nos leva novamente a verificar:

data;
hora;
certificado;
cadeia.

Erro 0x800B010A

Esse tipo de erro pode envolver incapacidade de construir a cadeia até uma raiz confiável.

Mais uma vez:

CAPI2.

Tabela de erros de confiança

Código	Significado resumido	Primeira investigação
0x80096002	Certificado do signatário ausente/inválido	Certificado + CAPI2
0x80096003	Contra-assinatura inválida	Assinatura + CAPI2
0x80096004	Assinatura do certificado não verificável	Cadeia/certificado
0x80096005	Problema no timestamp	Data/hora + assinatura
0x80096010	Digest/assinatura digital não validou	Arquivo/pacote/cache
0x800B0100	Assinatura ausente	Pacote/catálogo
0x800B0101	Certificado fora da validade	Relógio/certificado
0x800B0109	Raiz não confiável	Cadeia + CAPI2
0x800B010A	Cadeia não pôde ser construída adequadamente	CAPI2/certificados
0x80092012	Não foi possível verificar revogação	Rede/PKI/CAPI2

Catálogos .cat

O Windows utiliza arquivos de catálogo:

.cat

em diferentes mecanismos de assinatura e validação.

Esses catálogos ajudam a relacionar arquivos com informações criptográficas utilizadas para verificar integridade e confiança.

Não edite arquivos .cat

Não:

abra e modifique;
substitua por arquivos encontrados na internet;
copie catálogo de outro computador aleatoriamente.

Eles fazem parte de mecanismos de confiança do sistema.

catroot2 e catálogos

É justamente por isso que catroot2 aparece em determinados procedimentos de Windows Update.

Quando existe estado local inconsistente relacionado a catálogos/validação, permitir que o Windows reconstrua esse armazenamento pode ajudar.

Como reconstruir catroot2 de forma controlada?

Quando o diagnóstico realmente justificar, abra Prompt de Comando como administrador.

Pare:

net stop cryptsvc

Dependendo do procedimento completo, também podemos parar:

net stop wuauserv

net stop bits

Depois renomear:

ren %windir%\System32\catroot2 catroot2.old

Depois iniciar novamente:

net start cryptsvc

net start bits

net start wuauserv

Reinicie quando apropriado e teste Windows Update novamente.

Por que renomear em vez de excluir?

Pelo mesmo princípio usado em SoftwareDistribution.

Renomear preserva temporariamente o estado anterior.

Isso é mais controlado do que:

apagar tudo imediatamente.

O Windows recria catroot2?

Quando necessário, o Windows pode recriar o diretório e o estado correspondente.

Mas isso não significa que devemos fazê-lo periodicamente.

Não faça “limpeza preventiva” de catroot2

Não existe benefício em reconstruí-lo toda semana.

Se Windows Update está funcionando:

deixe-o funcionar.

SoftwareDistribution e catroot2 têm a mesma função?

Não.

Esse é outro erro frequente.

De maneira simplificada:

SoftwareDistribution

está fortemente associado ao estado local/cache/dados do Windows Update.

catroot2

participa de aspectos relacionados a catálogos e operações criptográficas.

Renomear os dois em um reset não significa que são equivalentes.

Quando reconstruir os dois?

Existem procedimentos de reset do Windows Update que incluem:

SoftwareDistribution

catroot2.

Isso pode ser apropriado quando já existe evidência de estado local inconsistente e métodos anteriores não resolveram.

Mas não deve ser automaticamente:

Passo 1.

Preserve evidências primeiro

Antes:

Get-WindowsUpdateLog

Copie:

CBS.log

quando aplicável.

Verifique:

código;
horário;
KB.

Depois faça o reset se o diagnóstico justificar.

Exemplo 1 — 0x80096010 depois do download

Imagine:

Windows Update baixa determinada KB.

Depois:

0x80096010

WindowsUpdate.log mostra falha de validação do conteúdo.

Nesse cenário, faz sentido investigar:

conteúdo baixado;
catálogo;
cache;
assinatura.

Exemplo 2 — 0x800B0109 em ambiente empresarial

Computador corporativo.

Outros serviços também apresentam erros de certificado.

CAPI2 mostra:

cadeia terminando em raiz não confiável.

Nesse caso, simplesmente limpar SoftwareDistribution provavelmente não corrige a PKI.

Precisamos investigar:

certificado raiz;
política;
distribuição corporativa;
proxy de inspeção.

Exemplo 3 — data do computador completamente errada

Computador mostra ano incorreto.

Windows Update apresenta falhas relacionadas a comunicação segura/certificados.

Primeiro:

corrija e investigue a sincronização de horário.

Não comece reconstruindo Component Store.

Exemplo 4 — catroot2 inconsistente

Logs apontam repetidamente para problemas locais de validação/catálogos.

Agora uma reconstrução controlada de catroot2 pode fazer sentido.

CAPI2 no Visualizador de Eventos

Para diagnóstico avançado, abra:

eventvwr.msc

Procure o log operacional do CAPI2.

Se necessário, habilite o log quando o objetivo for reproduzir uma falha específica.

Depois:

registre horário;
tente Windows Update;
reproduza o erro;
volte ao CAPI2;
analise os eventos daquele período.

Isso reduz o ruído

Em vez de milhares de eventos antigos, temos:

uma janela de poucos minutos.

PowerShell para certificados

Para listar certificados raiz do computador:

Get-ChildItem Cert:\LocalMachine\Root

Mas uma lista enorme não resolve o problema sozinha.

Precisamos identificar:

qual cadeia está falhando.

Certificados intermediários

Também existem repositórios para autoridades intermediárias.

Uma cadeia incompleta pode falhar mesmo quando a raiz correta existe.

Por isso:

“a raiz está instalada”

não encerra a investigação.

Políticas corporativas

Em empresas, certificados podem ser distribuídos por:

Group Policy;
MDM;
infraestrutura PKI.

Não faça alterações locais que contradigam o gerenciamento.

Antivírus e inspeção HTTPS

Algumas soluções de segurança podem participar de inspeção de tráfego criptografado.

Isso pode introduzir certificados intermediários ou mecanismos próprios.

Se o problema começou após alteração em uma solução de segurança, essa informação é relevante.

Mas não conclua automaticamente:

antivírus é o culpado.

Use os logs.

Proxy corporativo

O mesmo vale para proxies que inspecionam TLS.

Se existe interceptação autorizada, a cadeia precisa ser confiável para os clientes conforme a arquitetura da organização.

Computador doméstico com certificado corporativo antigo

Imagine um notebook que pertencia a uma empresa e foi reutilizado.

Ele pode possuir:

políticas antigas;
certificados antigos;
agentes de segurança;
proxy;
VPN.

Esses resíduos podem complicar o diagnóstico.

Não saia apagando todos os certificados corporativos

Primeiro determine:

origem;
finalidade;
política;
software associado.

Excluir certificados indiscriminadamente pode quebrar:

VPN;
Wi-Fi empresarial;
aplicativos;
autenticação;
assinatura;
serviços internos.

SFC resolve erros de certificado?

Normalmente não é a primeira ferramenta para:

CERT_E_UNTRUSTEDROOT.

SFC verifica arquivos protegidos do Windows.

Ele não transforma automaticamente uma cadeia não confiável em confiável.

DISM resolve?

Também depende.

Se existe corrupção de componentes do sistema, DISM pode ser relevante.

Mas:

0x800B0109

causado por PKI corporativa incorreta não será resolvido simplesmente por:

DISM /RestoreHealth.

Cada ferramenta responde uma pergunta

CAPI2

Por que a validação da cadeia falhou?

WindowsUpdate.log

O que o Windows Update estava tentando fazer?

CBS.log

O que aconteceu durante servicing?

DISM

Qual é o estado da imagem/Component Store?

certlm.msc

Quais certificados existem no computador?

w32tm

Qual é o estado da sincronização de horário?

Essa é a lógica deste guia

Não execute:

ferramenta → ferramenta → ferramenta

sem saber a pergunta.

Faça:

pergunta → ferramenta → resultado → interpretação.

Reset completo do Windows Update

Agora já conseguimos entender melhor o famoso procedimento:

net stop bits

net stop wuauserv

net stop cryptsvc

ren %windir%\SoftwareDistribution SoftwareDistribution.old

ren %windir%\System32\catroot2 catroot2.old

net start cryptsvc

net start bits

net start wuauserv

Esse procedimento pode reconstruir estados locais importantes.

Mas ele não corrige automaticamente:

certificado raiz ausente;
proxy corporativo errado;
driver incompatível;
Component Store corrompido;
partição Recovery pequena;
falta de espaço;
atualização não aplicável;
BIOS incompatível.

É por isso que “reset Windows Update” não é solução universal

Ele resolve:

determinadas classes de problemas.

Não:

todos os erros do Windows Update.

Método VMIA para erro criptográfico

1. Copie o código completo

Exemplo:

0x80096010

2. Registre KB

3. Registre horário

4. Determine a etapa

Download?

Validação?

Instalação?

5. Gere WindowsUpdate.log

Get-WindowsUpdateLog

6. Consulte CBS.log quando servicing estiver envolvido

7. Se houver certificado, consulte CAPI2

8. Confira data e hora

w32tm /query /status

9. Identifique a cadeia

10. Determine se o PC é gerenciado

11. Verifique proxy/inspeção quando houver evidência

12. Se o problema for estado local de catálogos, considere reconstrução controlada de catroot2

13. Teste novamente

14. Compare os logs.

O que não fazer

Não:

instale certificados desconhecidos;
adicione raízes aleatórias;
desative verificação de certificados;
desative revogação permanentemente;
altere TLS para protocolos inseguros;
apague catroot;
apague catroot2 durante operação;
altere permissões de catroot2;
apague certificados corporativos sem investigação;
execute reset completo antes de coletar logs;
confunda erro de assinatura com corrupção do Component Store;
execute SFC/DISM como resposta automática a qualquer erro criptográfico.

Fluxo de diagnóstico

Windows Update apresenta erro criptográfico

↓

registrar código + KB + horário

↓

WindowsUpdate.log

↓

qual objeto/operação falhou?

↓

Assinatura/digest?

↓

verificar conteúdo/cache/catálogo

↓

Cadeia de certificado?

↓

CAPI2

↓

qual certificado?

↓

qual intermediária?

↓

qual raiz?

↓

relógio correto?

↓

ambiente corporativo?

↓

proxy/inspeção?

↓

Estado local de catálogos inconsistente?

↓

reconstrução controlada de catroot2

↓

testar novamente

↓

comparar resultado.

Serviços do Windows Update: wuauserv, BITS, CryptSvc, TrustedInstaller, DoSvc, UsoSvc e WaaSMedicSvc

Quando Windows Update apresenta problema, um dos primeiros conselhos encontrados na internet costuma ser:

“Abra Serviços e veja se Windows Update está iniciado.”

Essa verificação pode ser útil.

O problema começa quando o diagnóstico termina aí.

O Windows Update moderno não depende exclusivamente de um serviço.

Existem vários componentes envolvidos em diferentes fases:

detecção;
download;
transferência em segundo plano;
validação;
instalação;
servicing;
orquestração;
recuperação;
otimização de entrega.

Por isso, precisamos entender:

qual serviço faz o quê.

Windows Update não é apenas wuauserv

Entre os componentes que podem participar encontramos:

wuauserv

BITS

CryptSvc

TrustedInstaller

DoSvc

UsoSvc

WaaSMedicSvc

Além deles existem:

tarefas agendadas;
mecanismos de servicing;
processos;
componentes do Windows Setup.

Primeiro: serviço parado não significa serviço quebrado

Essa é uma das regras mais importantes desta parte.

Você executa:

sc query wuauserv

e encontra:

STATE : STOPPED

Isso não prova que existe defeito.

O serviço pode:

iniciar sob demanda;
responder a um gatilho;
iniciar quando Windows Update precisa;
parar quando termina determinada tarefa.

Manual também não significa configuração errada

Outro erro comum:

“Se está Manual, coloque Automático.”

Não faça isso indiscriminadamente.

O Windows utiliza diferentes modelos de inicialização.

Alterar todos os serviços para:

Automatic

pode modificar o comportamento projetado pelo sistema sem corrigir a causa original.

Use Get-Service

No PowerShell:

Get-Service wuauserv,bits,cryptsvc,trustedinstaller

Podemos observar:

Name;
DisplayName;
Status.

Para mais detalhes

Use:

sc qc wuauserv

Depois:

sc qc bits

sc qc cryptsvc

sc qc trustedinstaller

Isso fornece informações adicionais sobre a configuração de cada serviço.

wuauserv — Windows Update

Nome:

wuauserv

Display name:

Windows Update

É um dos principais serviços associados à detecção, download e instalação de atualizações.

Como verificar

sc query wuauserv

Como tentar iniciar manualmente

Quando o diagnóstico justificar:

net start wuauserv

ou:

sc start wuauserv

Se iniciar normalmente

Isso mostra que o serviço consegue iniciar naquele momento.

Mas ainda não prova que Windows Update como um todo está funcionando.

Se não iniciar

Agora o erro retornado pelo Service Control Manager se torna importante.

Não tente corrigir antes de anotar:

código;
mensagem;
horário.

Visualizador de Eventos

Abra:

eventvwr.msc

Procure eventos relacionados ao Service Control Manager no horário da tentativa.

Serviço inicia e para imediatamente

Isso também não prova defeito.

Alguns serviços podem parar quando não existe trabalho.

Precisamos saber se:

ele parou porque terminou a tarefa

ou:

ele caiu durante a operação.

Não mantenha wuauserv forçadamente em execução

O objetivo não é:

“fazer aparecer Running permanentemente”.

O objetivo é:

permitir que o Windows Update execute corretamente suas operações.

BITS — Background Intelligent Transfer Service

Nome:

BITS

BITS significa:

Background Intelligent Transfer Service.

Ele é utilizado por componentes do Windows e aplicativos para transferências em segundo plano.

Windows Update pode utilizar BITS em determinados fluxos.

Consultar BITS

sc query bits

Ou:

Get-Service bits

BITS parado é defeito?

Não necessariamente.

Novamente, o serviço pode iniciar quando existe trabalho.

Quando BITS merece investigação?

Quando temos evidências de:

download que não progride;
trabalhos presos;
erros explicitamente relacionados ao BITS;
serviço que não consegue iniciar;
transferência repetidamente interrompida.

PowerShell e trabalhos BITS

Podemos consultar trabalhos BITS do contexto atual com ferramentas apropriadas do PowerShell.

Por exemplo:

Get-BitsTransfer -AllUsers

Esse comando exige permissões adequadas para determinados trabalhos.

Lista vazia não prova problema

Pode simplesmente não existir transferência BITS naquele momento.

Não remova todos os jobs BITS automaticamente

Um computador pode utilizar BITS para outras aplicações.

Antes de remover um trabalho, descubra:

proprietário;
origem;
destino;
estado;
finalidade.

BITS e Windows Update não são sinônimos

Outro erro comum:

BITS está funcionando, então Windows Update deveria funcionar.

Não necessariamente.

BITS é apenas uma peça do processo.

Delivery Optimization

Nos Windows modernos, outro componente importante é:

Delivery Optimization.

Nome do serviço:

DoSvc

Consultar DoSvc

sc query dosvc

O que faz Delivery Optimization?

Ela participa da distribuição e obtenção de conteúdo utilizado pelo Windows e por determinados produtos Microsoft.

Dependendo da configuração, pode utilizar mecanismos que otimizam a entrega do conteúdo.

Delivery Optimization é P2P?

Ela pode utilizar compartilhamento peer-to-peer em determinados modos/configurações.

Mas reduzir Delivery Optimization a:

“torrent do Windows”

é uma simplificação ruim.

Ela possui políticas e diferentes modos de operação.

Configurações

Abra:

Configurações → Windows Update → Opções avançadas → Otimização de Entrega

A nomenclatura exata pode variar conforme a versão.

Posso desativar downloads de outros computadores?

O usuário pode controlar opções de compartilhamento conforme a edição e configuração do Windows.

Mas isso não significa que devemos desativar o serviço DoSvc como primeira tentativa de troubleshooting.

Delivery Optimization e ambiente corporativo

Empresas podem definir políticas específicas para:

origem;
peers;
cache;
comportamento de download.

Portanto, antes de alterar:

gpresult /r

CryptSvc

Já analisamos na Parte 7.

Nome:

CryptSvc

Display name:

Cryptographic Services

Consultar

sc query cryptsvc

Ele pode participar de operações relacionadas a:

catálogos;
assinaturas;
certificados;
validação criptográfica.

Se CryptSvc falha

Investigue:

erro do serviço;
Event Viewer;
código do Windows Update;
CAPI2 quando aplicável.

Não comece simplesmente apagando:

catroot2.

TrustedInstaller

Nome do serviço:

TrustedInstaller

Display name:

Windows Modules Installer

Esse serviço é extremamente importante para servicing do Windows.

Consultar

sc query trustedinstaller

Para que serve?

Ele permite:

instalação;
modificação;
remoção;

de atualizações e componentes do Windows.

TrustedInstaller não é vírus

O nome pode assustar usuários.

Mas:

TrustedInstaller

é um componente legítimo do Windows.

TrustedInstaller usando CPU

Durante servicing, Windows Update ou manutenção de componentes, atividade elevada pode ocorrer.

Precisamos analisar:

duração;
atividade;
disco;
atualização;
logs.

Não finalize TrustedInstaller à força

Encerrar servicing no momento errado pode deixar:

atualização incompleta;
operação pendente;
Component Store inconsistente.

TiWorker.exe

Outro processo frequentemente observado:

TiWorker.exe

Ele está relacionado ao:

Windows Modules Installer Worker.

Pode participar de operações de manutenção e servicing.

TiWorker.exe com CPU alta

Novamente:

CPU alta não significa malware automaticamente.

Se o computador acabou de:

iniciar;
procurar atualizações;
instalar KB;
executar manutenção;

atividade temporária pode ser esperada.

Quando investigar?

Quando o processo:

permanece excessivamente ativo por período anormal;
coincide com falhas;
repete a mesma operação;
produz erros em CBS.log.

CBS.log

Se TiWorker/TrustedInstaller parecem presos durante servicing:

C:\Windows\Logs\CBS\CBS.log

pode revelar o que está acontecendo.

Não use “End Task” como solução

Pode parecer que o computador ficou mais rápido.

Mas você apenas interrompeu a operação.

O problema pode retornar no próximo boot.

UsoSvc — Update Orchestrator Service

Nome:

UsoSvc

Display name:

Update Orchestrator Service

Esse componente participa da coordenação das operações do Windows Update.

Consultar

sc query usosvc

O que significa orquestração?

Windows Update precisa coordenar tarefas como:

procurar;
baixar;
instalar;
agendar;
reiniciar;
retomar operações.

UsoSvc participa dessa organização.

Update Orchestrator e tarefas agendadas

Parte da infraestrutura também utiliza tarefas agendadas.

Abra:

taskschd.msc

Mas não saia desabilitando tarefas relacionadas ao Update Orchestrator.

“Windows ligou sozinho para atualizar”

Em determinados equipamentos e configurações, mecanismos de manutenção, wake timers e políticas podem participar de atividades programadas.

Isso deve ser investigado separadamente.

Não desative tarefas aleatórias para impedir atualização.

WaaSMedicSvc

Outro componente importante:

WaaSMedicSvc

Associado ao:

Windows Update Medic Service.

Qual é sua função?

Ele participa da manutenção e recuperação de componentes relacionados ao Windows Update.

Isso ajuda a explicar uma situação comum:

“Eu desativei Windows Update, mas depois ele voltou.”

Windows possui mecanismos de manutenção do próprio Update

O Windows moderno foi projetado para manter a infraestrutura de atualização operacional.

Por isso, algumas modificações manuais podem ser revertidas ou não produzir o comportamento permanente esperado.

Não tente destruir WaaSMedicSvc

Existem tutoriais que recomendam:

alterar permissões;
assumir propriedade;
modificar Registro;
bloquear executável.

Isso pode criar um Windows Update permanentemente danificado.

“Quero impedir qualquer atualização”

Isso é diferente de:

“quero corrigir Windows Update”.

Para gerenciamento de atualizações, use:

configurações suportadas;
políticas;
ferramentas corporativas quando aplicável.

Não destrua componentes do sistema.

Medic Service e diagnóstico

Se Windows Update parece se reparar sozinho depois de uma falha, isso pode fazer parte da infraestrutura de manutenção.

Não interprete automaticamente como comportamento malicioso.

Windows Modules Installer

Já vimos TrustedInstaller.

Mas é importante separar:

Windows Update

de:

servicing.

wuauserv

pode encontrar a atualização.

Depois:

TrustedInstaller

e CBS podem participar da aplicação de componentes.

Por isso um serviço pode funcionar e outro estágio falhar

Exemplo:

wuauserv

funciona.

A KB é encontrada.

Download termina.

Depois:

CBS falha com:

0x80073712.

Nesse cenário:

o serviço Windows Update não era necessariamente o problema.

Outro exemplo

CBS está saudável.

Mas download não começa porque existe problema de comunicação.

Nesse caso:

TrustedInstaller não é a primeira área para investigar.

Serviços formam uma cadeia

Podemos imaginar:

Windows Update Agent / Orchestrator

↓

download / BITS / Delivery Optimization

↓

CryptSvc / validação

↓

Windows Modules Installer

↓

CBS / Component Store

↓

reinicialização / conclusão.

É uma simplificação, mas ajuda a compreender o fluxo.

Serviços e processos não são a mesma coisa

Exemplo:

wuauserv

é um serviço.

TiWorker.exe

é um processo executável associado a operações de servicing.

Não confunda:

serviço;
processo;
tarefa agendada;
DLL;
componente COM.

svchost.exe

Alguns serviços do Windows podem ser hospedados por:

svchost.exe

Portanto, encontrar svchost usando rede ou CPU não significa automaticamente que Windows Update é o responsável.

Descubra serviços dentro de svchost

Uma ferramenta útil:

tasklist /svc

Isso relaciona processos a serviços.

PowerShell

Também podemos combinar informações de processos e serviços para aprofundar a análise.

Mas primeiro:

qual processo está realmente consumindo recursos?

Resource Monitor

Execute:

resmon

Ele ajuda a observar:

CPU;
disco;
rede;
memória.

Windows Update parado em 0%

Se a interface mostra:

Baixando — 0%

não conclua imediatamente que BITS está quebrado.

Observe:

rede;
WindowsUpdate.log;
Delivery Optimization;
serviços;
horário.

Pode existir preparação antes do percentual mudar

A interface gráfica não necessariamente representa cada operação interna em tempo real.

O sistema pode estar:

avaliando;
preparando;
verificando;
aguardando outro componente.

Windows Update em 100%

Da mesma forma:

100%

não significa necessariamente:

processo inteiro terminou.

Pode representar apenas uma etapa.

Depois ainda podem ocorrer:

validação;
staging;
servicing;
reinicialização.

Serviço preso em START_PENDING

Ao executar:

sc query

podemos encontrar estados como:

START_PENDING

ou:

STOP_PENDING.

Se o estado permanece por muito tempo, investigue.

Não mate o processo imediatamente

Primeiro:

registre horário;
consulte eventos;
veja dependências;
veja processo associado.

Service Control Manager

No Event Viewer, eventos do:

Service Control Manager

podem registrar:

falha de inicialização;
timeout;
encerramento inesperado.

Código 1053

Um serviço pode retornar erro relacionado a não responder dentro do tempo esperado.

Isso não significa automaticamente corrupção do Windows Update.

Descubra qual serviço e por quê.

Código 1068

Pode indicar falha de serviço ou grupo de dependência.

Nesse caso, precisamos identificar:

qual dependência.

Código 1079 e outros erros de serviço

Erros de serviço possuem seus próprios significados.

Não tente corrigi-los com um “reset de Windows Update” antes de saber qual configuração está incorreta.

Consultar dependências

Use:

sc qc NOME_DO_SERVICO

Observe informações relevantes.

Não altere conta de serviço

Nunca mude:

Log On As;
LocalSystem;
LocalService;
NetworkService;

por tentativa.

Uma conta incorreta pode impedir o serviço de funcionar e criar problemas de segurança.

Descritores de segurança

Alguns procedimentos avançados de reset utilizam:

sc.exe sdset

para redefinir descritores de segurança.

Isso é uma operação avançada.

Não use como primeira tentativa.

Por quê?

Se você aplica um descritor incorreto:

serviço pode deixar de iniciar;
permissões podem ficar erradas;
segurança pode ser reduzida.

Registrar DLLs resolve Windows Update?

Tutoriais antigos frequentemente apresentam dezenas de comandos:

regsvr32 ...

para registrar DLLs.

No Windows moderno, isso não deve ser tratado como solução universal.

Muitos componentes não precisam ou não devem ser “registrados novamente” dessa forma.

Winsock reset

Outro comando comum:

netsh winsock reset

Ele atua na pilha Winsock.

Isso pode ser útil em problemas específicos de rede.

Mas não corrige:

Component Store;
certificado raiz;
driver de upgrade;
Recovery pequena.

WinHTTP proxy reset

netsh winhttp reset proxy

Também não deve ser usado sem verificar primeiro:

netsh winhttp show proxy

Em empresa, apagar proxy pode quebrar conectividade.

Serviços em computador gerenciado

Em ambiente corporativo, políticas podem controlar Windows Update.

Antes de modificar serviços:

gpresult /r

O computador pode estar configurado para usar:

WSUS;
gerenciamento corporativo;
políticas específicas.

Windows Update Medic e políticas

Não tente vencer o gerenciamento alterando serviços localmente.

Descubra primeiro qual arquitetura está controlando o dispositivo.

Ver todos os serviços relevantes

PowerShell:

Get-Service wuauserv,bits,cryptsvc,trustedinstaller,usosvc,dosvc,waasmedicsvc

Isso fornece uma visão rápida.

Não espere todos como Running

Esse ponto merece repetição.

Uma saída com vários:

Stopped

não prova falha.

Precisamos observar o comportamento durante uma tentativa real de atualização.

Método melhor: observar antes e durante

Antes

Execute:

Get-Service wuauserv,bits,cryptsvc,trustedinstaller,usosvc,dosvc,waasmedicsvc

Inicie Windows Update

Clique em:

Verificar se há atualizações

Observe novamente

Execute o comando outra vez.

Agora podemos ver mudanças de estado.

Isso é diagnóstico dinâmico

Em vez de olhar uma fotografia isolada, observamos:

o comportamento.

Process Monitor

Para casos avançados, Process Monitor pode ajudar a observar operações de:

arquivos;
Registro;
processos.

Mas o volume de dados é enorme.

Use filtros.

Não capture tudo durante horas

Defina:

processo;
caminho;
horário;
operação.

Caso contrário, o resultado pode ser difícil de interpretar.

Event Viewer

Além do Service Control Manager, existem logs específicos relacionados ao Windows Update.

Eles podem ajudar a correlacionar:

início;
falha;
instalação;
reinicialização.

PowerShell e Get-WinEvent

Para análises avançadas podemos consultar eventos via PowerShell.

Mas novamente:

filtre pelo período da falha.

Por que horário é tão importante?

Imagine:

10.000 eventos.

Sem horário:

difícil.

Com:

falha ocorreu às 14:37

podemos analisar poucos minutos ao redor.

Sempre registre horário

Esse hábito simples melhora enormemente o diagnóstico.

Serviço reinicia sozinho

Se um serviço falha e volta, isso pode ocorrer por:

recovery actions;
trigger;
outro componente;
manutenção.

Não conclua que “Windows está ignorando o administrador”.

Ver ações de recuperação

Abra:

services.msc

Propriedades do serviço podem mostrar opções relacionadas à recuperação, dependendo do serviço.

Não altere sem necessidade.

Windows Update fica procurando para sempre

Possíveis áreas:

Windows Update Agent;
política;
conectividade;
metadados;
serviços;
estado local.

Não escolha BITS automaticamente.

Windows Update não encontra nenhuma atualização

Pode significar:

sistema realmente atualizado;
atualização não aplicável;
política;
serviço;
problema de detecção.

Windows Update encontra mas não baixa

Agora priorizamos:

comunicação;
BITS;
Delivery Optimization;
proxy;
cache;
conteúdo.

Baixa mas não instala

Priorize:

servicing;
CBS;
Component Store;
espaço;
aplicabilidade.

Instala e pede reinicialização

Isso pode ser normal.

Continua pedindo reinicialização

Agora temos outro cenário:

operação pendente;
pacote não finalizado;
servicing preso;
estado de reinicialização persistente.

Não é simplesmente:

wuauserv parado.

Instala e desfaz alterações

Agora entramos em:

servicing;
driver;
boot;
erro durante reinicialização;
rollback.

Tabela dos principais serviços

Serviço	Função resumida	Quando investigar
wuauserv	Windows Update	Detecção/operação do Update
BITS	Transferência em segundo plano	Download/transferências
CryptSvc	Serviços criptográficos	Assinaturas/catálogos/certificados
TrustedInstaller	Windows Modules Installer	Instalação de componentes
DoSvc	Delivery Optimization	Distribuição/download
UsoSvc	Update Orchestrator	Coordenação das atualizações
WaaSMedicSvc	Manutenção do Windows Update	Recuperação da infraestrutura

Tabela de comandos

Objetivo	Comando
Windows Update	`sc query wuauserv`
BITS	`sc query bits`
CryptSvc	`sc query cryptsvc`
TrustedInstaller	`sc query trustedinstaller`
Delivery Optimization	`sc query dosvc`
Update Orchestrator	`sc query usosvc`
Medic Service	`sc query waasmedicsvc`
Ver vários serviços	`Get-Service wuauserv,bits,cryptsvc,trustedinstaller,usosvc,dosvc,waasmedicsvc`
Configuração do serviço	`sc qc nome`
Processos + serviços	`tasklist /svc`

Quando reiniciar um serviço?

Reiniciar um serviço pode ser útil para testar um estado temporariamente preso.

Mas faça isso quando:

não existe servicing crítico em andamento;
sabemos qual serviço;
registramos o estado anterior.

Não reinicie TrustedInstaller durante servicing

Se CBS está aplicando uma atualização, interromper Windows Modules Installer pode piorar o estado.

Antes de parar serviços

Observe:

Windows Update está instalando?
DISM está rodando?
TiWorker está ativo?
existe reinicialização pendente?

Reset controlado do Windows Update

Depois de diagnóstico, determinados cenários podem justificar:

net stop wuauserv

net stop bits

net stop cryptsvc

Depois reconstrução de estados específicos.

Mas esse procedimento é:

reparação

e não:

diagnóstico inicial.

O maior erro dos tutoriais

Muitos começam pelo final.

Eles fazem:

parar tudo;
apagar tudo;
resetar rede;
registrar DLL;
reiniciar.

Às vezes funciona.

Mas não sabemos:

o que estava errado.

E quando não funciona, perdemos várias pistas.

Método profissional

Faça:

sintoma

↓

código

↓

horário

↓

fase

↓

serviço/componente

↓

log

↓

hipótese

↓

teste

↓

correção

↓

validação.

Fluxo para serviços

Windows Update falhou

↓

qual etapa?

Não encontra atualizações

→ wuauserv / agente / política / comunicação.

Não baixa

→ rede / BITS / DoSvc / proxy.

Assinatura falha

→ CryptSvc / CAPI2 / catálogos.

Baixa mas não instala

→ TrustedInstaller / CBS / Component Store.

Orquestração/reinicialização problemática

→ UsoSvc / servicing / estado pendente.

↓

consultar serviço

↓

serviço inicia quando necessário?

Sim

Não conclua que ele é culpado.

Não

↓

registrar erro

↓

Event Viewer

↓

investigar causa

↓

corrigir

↓

testar novamente.

Windows Update travado sem código: 0%, 100%, reinicialização necessária, KB repetida e outros sintomas

Nem todo problema do Windows Update termina com algo claro como:

0x800F081F

ou:

0xC1900101-0x30018.

Em muitos computadores, a única informação apresentada é:

Baixando — 0%

ou:

Instalando — 100%

ou ainda:

Reinicialização necessária.

Às vezes não aparece código algum.

Isso não significa que estamos sem pistas.

O comportamento do Windows Update também fornece informações.

Precisamos descobrir:

em qual etapa ele aparentemente parou?

existe atividade real nos bastidores?

há erro registrado nos logs?

a interface está atrasada em relação ao processo interno?

existe outro componente impedindo o avanço?

Essa análise evita um erro muito comum:

considerar qualquer percentual parado como travamento.

Percentual parado não significa necessariamente processo parado

Esse conceito é fundamental.

A interface pode mostrar:

0%

enquanto o Windows executa atividades preparatórias.

Da mesma forma:

100%

pode representar o término de uma etapa, não de todo o processo.

Por isso:

percentual da interface ≠ estado técnico completo do Windows Update.

Como saber se existe atividade?

Antes de interromper qualquer coisa, observe:

CPU;
disco;
rede;
processos;
serviços;
logs.

Gerenciador de Tarefas

Abra:

taskmgr

Observe principalmente:

CPU;
Disco;
Rede.

Mas não conclua apenas pelo uso total.

Precisamos descobrir:

qual processo está utilizando o recurso.

Monitor de Recursos

Execute:

resmon

Ele fornece uma visão mais detalhada de:

CPU;
disco;
rede;
memória.

WindowsUpdate.log

Gere:

Get-WindowsUpdateLog

O log pode mostrar se o Windows ainda está:

procurando;
processando;
baixando;
avaliando;
instalando;
retornando erro.

Histórico de Atualizações

Abra:

Configurações → Windows Update → Histórico de atualizações

Identifique:

KB;
data;
resultado.

Registre o horário

Se o problema aconteceu às:

22:14

anote.

Isso permitirá correlacionar:

WindowsUpdate.log;
CBS.log;
Event Viewer.

Cenário 1 — “Verificando atualizações” por muito tempo

O usuário clica:

Verificar se há atualizações

e o Windows permanece verificando.

Não comece limpando SoftwareDistribution.

Primeiro descubra se existe atividade.

O que pode estar acontecendo?

Entre as possibilidades:

comunicação;
política;
Windows Update Agent;
metadados;
serviço;
servidor corporativo;
estado local;
outra operação em andamento.

Verifique os serviços

PowerShell:

Get-Service wuauserv,bits,cryptsvc,usosvc,dosvc

Não espere todos como:

Running.

Observe se eles respondem durante a tentativa.

Verifique proxy

netsh winhttp show proxy

Especialmente se:

navegador funciona;
Windows Update não.

Computador corporativo

Execute:

gpresult /r

O computador pode estar configurado para utilizar infraestrutura gerenciada.

Não compare imediatamente com outro PC doméstico

Uma máquina corporativa pode possuir políticas completamente diferentes.

WindowsUpdate.log

Procure o período da tentativa.

Se existe atividade contínua, talvez a interface apenas não tenha atualizado o status.

Se existe repetição do mesmo erro, agora temos uma pista concreta.

Cenário 2 — Baixando 0%

Esse é extremamente comum.

A interface mostra:

Baixando — 0%

por muito tempo.

Não significa automaticamente BITS quebrado

Pode existir:

preparação;
negociação;
verificação;
fila;
Delivery Optimization;
problema de comunicação;
cache;
política.

Observe rede

Abra:

resmon

Vá para:

Rede.

Veja se existe tráfego relacionado ao processo.

Não use apenas o Gerenciador de Tarefas

Tráfego pequeno pode parecer:

0 Mbps

por arredondamento.

Verifique WindowsUpdate.log

Procure mensagens de:

download;
timeout;
falha;
retry.

Se aparecer 0x80072EE2

Voltamos à Parte 2:

timeout.

Nesse caso:

“0%”

é apenas o sintoma visual.

O erro técnico é:

0x80072EE2.

Se aparecer 0x80240034

Temos:

download failed.

Agora procure o erro anterior.

Pode existir:

0x80072EE2

antes dele.

A cadeia seria

timeout

↓

download falhou

↓

interface permanece em 0%.

Isso é diagnóstico.

Cenário 3 — Baixando 100%

A interface chega a:

100%

e parece não avançar.

Não reinicie imediatamente.

O sistema pode estar:

validando;
preparando;
descompactando;
processando conteúdo;
iniciando servicing.

Observe disco

Mesmo sem rede, pode existir atividade intensa de armazenamento.

Isso faz sentido:

download terminou.

Agora a atividade pode ter mudado da rede para o disco.

Observe processos

Podem existir atividades relacionadas a:

servicing;
Windows Modules Installer;
Delivery Optimization;
Update Orchestrator.

WindowsUpdate.log

Verifique se o estado mudou de download para instalação.

Cenário 4 — Instalando 0%

Esse é outro caso clássico.

O Windows já baixou a atualização.

Agora mostra:

Instalando — 0%.

Isso pode significar que está:

preparando pacote;
verificando aplicabilidade;
iniciando servicing;
aguardando recurso;
processando estado anterior.

Não reinicie TrustedInstaller

Se servicing começou, interromper:

TrustedInstaller

pode piorar o problema.

CBS.log entra em cena

Abra:

C:\Windows\Logs\CBS\CBS.log

Veja se novas linhas estão sendo gravadas.

Como observar crescimento do log?

Você pode verificar:

data de modificação;
tamanho;
novas entradas.

Se CBS continua registrando atividade, o processo pode não estar realmente travado.

Quanto tempo devo esperar?

Não existe um número universal.

Depende de:

atualização;
CPU;
SSD/HDD;
quantidade de componentes;
estado do sistema;
outras operações.

O melhor critério não é apenas:

tempo.

É:

tempo + atividade + logs.

0% por 30 minutos com atividade

Pode estar trabalhando.

0% por horas sem atividade e com erro repetido

Agora temos evidência de problema.

Cenário 5 — Instalando em 20%, 44%, 73% ou outro número

Não atribua significado universal ao percentual.

Por exemplo:

44% = driver

não é uma regra técnica confiável.

Percentuais podem mudar entre atualizações

O percentual é uma representação da progressão daquela operação.

Não existe uma tabela universal:

20% = rede

40% = CBS

70% = driver

Não use esse tipo de diagnóstico.

O log é mais importante

Se parece parado em:

73%

registre o horário.

Depois procure nos logs o que estava ocorrendo naquele momento.

Cenário 6 — Instalando 100%

Novamente:

100% não significa finalizado.

Ainda podem existir:

commit;
servicing;
preparação de reinicialização;
operações pendentes.

Verifique se aparece reinicialização

Se Windows Update muda para:

Reinicialização necessária

isso pode ser completamente normal.

Cenário 7 — “Aguardando instalação”

Esse estado pode aparecer quando a atualização foi encontrada e possivelmente baixada, mas ainda não entrou na instalação.

Possíveis motivos incluem:

outra atualização em andamento;
política;
horário;
dependência;
reinicialização pendente;
orquestração.

Veja se existe outra KB

Uma atualização pode depender do término de outra.

Histórico

Verifique se alguma atualização anterior está:

pendente;
falhando;
aguardando reinicialização.

Cenário 8 — “Aguardando reinicialização”

Esse estado normalmente significa que existe trabalho que precisa ser concluído após reboot.

A primeira ação razoável costuma ser:

reiniciar corretamente o Windows.

Reiniciar é diferente de desligar e ligar

Dependendo da configuração de Inicialização Rápida, desligar e ligar pode não ser equivalente a uma reinicialização completa.

Use:

Reiniciar.

Linha de comando

Quando apropriado:

shutdown /r /t 0

Isso solicita reinicialização imediata.

Salve o trabalho antes.

Cenário 9 — Reinicialização necessária não desaparece

Agora temos um problema diferente.

O usuário reinicia.

Volta ao Windows.

Windows Update continua:

Reinicialização necessária.

Reinicia novamente.

Nada muda.

Não fique reiniciando indefinidamente

Depois de uma ou duas tentativas normais, precisamos investigar.

Pode existir operação pendente

O servicing pode manter estados relacionados a operações que precisam ser concluídas.

CBS.log

Procure erros durante:

shutdown;
boot;
finalização de atualização.

Histórico

Veja se alguma KB está repetidamente:

instalando;
falhando;
aguardando.

Não delete pending.xml

Um conselho antigo encontrado na internet é:

“apague pending.xml”.

Não faça isso como solução genérica.

Esse arquivo pode representar operações pendentes do servicing.

Removê-lo arbitrariamente pode deixar o estado inconsistente.

Não altere chaves PendingFileRenameOperations aleatoriamente

Outra prática perigosa é apagar indicadores de reinicialização do Registro apenas para fazer a mensagem desaparecer.

Isso pode ocultar o sintoma sem concluir a operação real.

O objetivo não é remover a mensagem

O objetivo é:

concluir ou reparar a operação pendente.

Cenário 10 — Mesma KB aparece repetidamente

Outro problema comum:

Windows Update instala:

KBxxxxxxx

Reinicia.

Depois a mesma KB aparece novamente.

Primeira pergunta

A KB realmente foi instalada?

Não confie apenas na impressão da interface.

Histórico de Atualizações

Verifique o resultado.

PowerShell e pacotes

Dependendo do tipo da atualização, informações podem ser obtidas por mecanismos diferentes.

Para pacotes do servicing:

DISM /Online /Get-Packages

Não dependa somente de Get-HotFix

Get-HotFix

pode ser útil em determinados casos, mas não representa necessariamente todos os tipos de atualização presentes no sistema.

Verifique a build

Execute:

winver

Se a KB deveria elevar o sistema para determinada build, compare com a build atual.

KB instalada mas reaparece

Possibilidades:

detecção inconsistente;
instalação parcial;
pacote não finalizado;
componente que continua aplicável;
falha na etapa de commit.

CBS.log

Procure a KB e o pacote correspondente.

Não esconda a atualização imediatamente

Ocultar apenas remove a oferta visual.

Não explica por que o sistema acredita que a atualização ainda é necessária.

Cenário 11 — “Você está atualizado”, mas existe versão mais recente

Essa frase gera muita confusão.

Windows Update pode dizer:

Você está atualizado

mesmo quando você sabe que existe uma versão mais nova do Windows.

Isso não é necessariamente contradição.

“Atualizado” dentro de qual contexto?

A máquina pode estar atualizada para:

versão atual instalada;
canal;
política;
disponibilidade;
elegibilidade.

Uma feature update pode não estar sendo oferecida

Possíveis razões:

rollout gradual;
compatibilidade;
safeguard hold;
política;
requisitos;
dispositivo gerenciado.

Não force automaticamente

Se a nova versão não aparece, primeiro descubra:

por quê.

winver

Execute:

winver

Anote:

versão;
build.

Windows Update

Depois compare com a versão oficialmente disponibilizada para aquele contexto.

Computador gerenciado

Novamente:

gpresult /r

Uma política pode controlar quando novas versões são oferecidas.

Cenário 12 — Atualização desaparece depois de falhar

Você tenta instalar.

Falha.

Volta para Windows Update.

A KB não aparece mais.

Isso pode ocorrer porque o estado de detecção mudou.

Não conclua que “Windows desistiu”

Execute nova verificação depois de registrar:

KB;
erro;
horário.

Histórico continua importante

Mesmo que a atualização desapareça da tela principal, a tentativa pode estar registrada.

Cenário 13 — Download começa novamente do zero

Isso pode indicar que o Windows decidiu:

descartar conteúdo anterior;
revalidar;
baixar novamente.

Mas não significa automaticamente defeito.

Se acontece repetidamente

Agora investigue:

rede;
cache;
validação;
armazenamento;
WindowsUpdate.log.

Pode existir falha de integridade

Se o conteúdo baixado repetidamente não passa na validação, o Windows pode precisar obtê-lo novamente.

Cenário 14 — Windows Update fica em branco

Configurações abre:

Windows Update

mas a página:

não carrega;
fica branca;
fecha;
mostra erro.

Nesse caso, precisamos separar:

problema da interface Configurações

de:

problema do mecanismo Windows Update.

Teste se o restante de Configurações funciona

Se várias páginas de Configurações falham, o problema pode não ser exclusivo do Windows Update.

Event Viewer

Procure falhas relacionadas ao aplicativo Configurações.

Não resete Windows Update imediatamente

Se o defeito é da interface, apagar cache de atualização pode não resolver.

Cenário 15 — Botão “Verificar se há atualizações” não responde

Observe:

wuauserv;
UsoSvc;
interface;
logs.

Teste o comportamento

Clique uma vez.

Registre horário.

Depois:

Get-WindowsUpdateLog

Procure atividade naquele momento.

Se existe atividade

A interface pode estar falhando em representar o estado.

Se não existe atividade

Agora investigamos:

interface;
serviço;
política;
agente.

Cenário 16 — Instala, reinicia e aparece “Desfazendo alterações”

Esse é um sinal muito importante.

A atualização avançou até uma fase em que alterações precisaram ser aplicadas durante o boot.

Depois algo falhou.

O Windows iniciou rollback.

Não desligue durante rollback

Deixe o Windows concluir quando possível.

Interromper essa etapa pode agravar a situação.

Depois que voltar ao Windows

Registre:

KB;
código;
horário;
mensagem.

CBS.log

Para atualização cumulativa:

C:\Windows\Logs\CBS\CBS.log

é especialmente importante.

Setup logs

Para upgrade de versão:

SetupDiag;
setupact.log;
setuperr.log.

Cenário 17 — Atualização chega a 100%, reinicia e some

Depois do reboot, parece que nada aconteceu.

Primeiro:

winver

Depois:

Histórico de Atualizações.

Talvez:

atualização tenha sido instalada;
atualização tenha feito rollback;
build não tenha mudado porque era outro tipo de pacote.

Não use apenas o nome da KB

Determine o resultado real.

Cenário 18 — Atualização instala muito lentamente

Antes de chamar de problema, observe:

SSD ou HDD;
CPU;
disco;
CBS;
antivírus;
espaço.

HDD pode alterar drasticamente a percepção

Servicing envolve muitas operações de arquivo.

Em HDD, isso pode levar muito mais tempo do que em SSD.

Disco em 100%

Abra:

resmon

Veja:

processo;
arquivos;
fila;
atividade.

Não conclua que o SSD está morrendo apenas pelo uso em 100%

100% de tempo ativo não é a mesma coisa que:

100% de capacidade ocupada.

São métricas diferentes.

Cenário 19 — Windows Update usa muita CPU

Veja qual processo.

Pode ser:

TiWorker;
svchost;
antivírus;
outro componente.

Se for TiWorker

Consulte CBS.log.

O sistema pode estar processando servicing normalmente.

Cenário 20 — Windows Update usa muita internet

Delivery Optimization e downloads de atualizações podem consumir banda.

Abra:

Configurações de Otimização de Entrega

e verifique as opções disponíveis.

Não bloqueie domínios aleatoriamente

Bloquear servidores relacionados ao Update pode criar falhas difíceis de diagnosticar depois.

Cenário 21 — Windows Update termina e SSD perde muitos GB

Isso pode ocorrer devido a:

arquivos temporários;
Windows.old;
cache;
Component Store;
rollback;
arquivos de instalação.

Não apague tudo imediatamente

Primeiro determine:

onde o espaço foi utilizado.

Cenário 22 — Atualização falha apenas em um computador

Isso sugere investigar características locais:

drivers;
Component Store;
cache;
política local;
armazenamento;
software instalado.

Cenário 23 — Vários computadores falham ao mesmo tempo

Agora a prioridade muda.

Investigue:

rede;
proxy;
WSUS;
política;
infraestrutura;
problema externo.

Isso é um excelente teste comparativo

um computador

versus:

todos os computadores

pode mudar completamente a investigação.

Cenário 24 — Funciona em outra rede

Se o mesmo computador falha em:

Rede A

e funciona em:

Rede B

temos forte evidência de diferença no caminho de rede.

Investigue:

proxy;
firewall;
DNS;
filtragem;
inspeção.

Cenário 25 — Falha em qualquer rede

Agora a hipótese de problema local ganha força.

Não confunda evidência com prova absoluta

Mesmo testes comparativos precisam ser interpretados.

Mas eles reduzem significativamente o universo de hipóteses.

Tabela mestre de sintomas

Sintoma	Camada inicial a investigar	Primeira evidência
Verificando indefinidamente	Agente/rede/política	WindowsUpdate.log
Baixando 0%	Rede/BITS/DoSvc	Log + atividade de rede
Baixando 100%	Validação/preparação	Log + disco
Instalando 0%	Servicing/preparação	CBS.log
Percentual parado	Depende da fase	Horário + atividade + logs
Aguardando instalação	Orquestração/dependência	Histórico/log
Aguardando reinicialização	Operação pendente	Reinicializar + histórico
Reinicialização persistente	Servicing pendente	CBS.log
Mesma KB repetindo	Detecção/commit	Histórico + DISM
“Você está atualizado”	Elegibilidade/política	winver + política
Desfazendo alterações	Servicing/rollback	CBS/Setup logs
Download reinicia	Rede/cache/validação	WindowsUpdate.log
Página em branco	Interface/Settings	Event Viewer
Update usa CPU	Processo específico	Task Manager/resmon
Update usa disco	Servicing/arquivos	resmon + CBS
Update usa rede	Download/DO	resmon
Perdeu muitos GB	Temporários/rollback/cache	Armazenamento

Quanto tempo caracteriza travamento?

Essa pergunta não pode ser respondida apenas com:

10 minutos

ou:

1 hora.

Use quatro critérios:

1. Tempo

Quanto tempo está no mesmo estado?

2. Atividade

Existe CPU, disco ou rede?

3. Logs

Novas linhas continuam sendo registradas?

4. Erros

Existe erro repetido?

Travamento provável

Um cenário mais suspeito seria:

mesmo percentual por horas;
praticamente nenhuma atividade;
logs repetindo a mesma falha;
nenhum avanço entre reinicializações.

Processo lento

Outro cenário:

percentual aparentemente parado;
disco ativo;
CBS.log avançando;
processos de servicing trabalhando.

Aqui:

interromper pode ser pior do que esperar.

Nunca use somente o percentual

Essa é a principal regra desta parte.

Como montar um diagnóstico de cinco minutos

Quando encontrar Windows Update “travado”:

1

Anote o percentual/status.

2

Anote o horário.

3

Abra:

taskmgr

4

Abra:

resmon

5

Veja:

CPU;
disco;
rede.

6

Gere:

Get-WindowsUpdateLog

7

Se estiver instalando:

abra CBS.log.

8

Veja Histórico.

9

Anote a KB.

10

Só então decida se precisa interferir.

Resetar ou não resetar?

Agora temos critérios melhores.

Reset pode fazer sentido quando:

estado local está claramente inconsistente;
cache apresenta falhas;
download/metadata permanecem quebrados;
procedimentos menos invasivos falharam.

Reset não é primeira escolha quando:

CBS está processando;
driver causa rollback;
partição está sem espaço;
certificado raiz está errado;
atualização não é aplicável.

Não interrompa uma instalação ativa

Antes de parar serviços, confirme que não existe servicing em andamento.

Observe:

TrustedInstaller;
TiWorker;
CBS.log.

Não desligue à força

Segurar o botão Power durante atualização pode transformar uma falha recuperável em um problema de boot ou servicing.

Use desligamento forçado somente em situações realmente necessárias, não como rotina de troubleshooting.

Depois que o Windows Update voltar a funcionar

Não pare no:

“agora instalou”.

Valide.

Verifique Histórico

Confirme:

Instalado com êxito.

Verifique build

winver

quando a atualização deveria alterar a build.

Verifique se a KB reaparece

Execute nova busca.

Verifique reinicialização

Confirme que a mensagem não continua pendente.

Verifique logs

Se o computador apresentava falhas persistentes, confirme que o erro anterior não continua ocorrendo.

Método VMIA para Windows Update sem código

O procedimento pode ser resumido assim:

sintoma

↓

horário

↓

atividade

↓

WindowsUpdate.log

↓

CBS.log quando houver servicing

↓

Histórico

↓

identificar camada

↓

corrigir causa

↓

reiniciar quando necessário

↓

validar instalação.

Erros de download: BITS, Delivery Optimization, 0x802000xx, proxy, VPN e downloads que não terminam

Quando o Windows Update mostra:

Baixando — 0%

é muito fácil concluir:

“a internet está com problema”.

Mas essa conclusão pode estar errada.

Para uma atualização chegar ao computador, diferentes componentes e etapas podem participar do processo.

Precisamos separar:

detecção

↓

obtenção dos metadados

↓

seleção do conteúdo

↓

transferência

↓

armazenamento local

↓

validação

↓

instalação.

Uma falha em qualquer uma dessas etapas pode ser apresentada ao usuário simplesmente como:

download não funciona.

Encontrar a atualização não prova que o download funciona

O Windows pode conseguir consultar os serviços necessários para descobrir:

KBxxxxxxx

e ainda assim falhar ao obter o conteúdo.

Portanto:

Windows Update encontrou a KB

não significa:

todo o caminho de download está funcionando.

Download concluído também não significa pacote válido

O inverso também acontece.

O conteúdo chega ao computador.

Depois a validação falha.

Nesse caso, a interface pode tentar novamente ou apresentar um erro que parece relacionado ao download.

Mas o problema real aconteceu:

depois da transferência.

As três perguntas iniciais

Quando o download falha, tente responder:

1. A atualização foi detectada?

2. A transferência realmente começou?

3. O conteúdo transferido passou pela validação?

Essas três respostas já eliminam muitas hipóteses.

BITS

BITS significa:

Background Intelligent Transfer Service.

Nome do serviço:

BITS

Consulte:

sc query bits

Ou:

Get-Service bits

O que BITS faz?

BITS fornece infraestrutura para transferência de arquivos em segundo plano.

Uma de suas características é permitir que trabalhos sejam transferidos e retomados de maneira controlada.

BITS não é exclusivo do Windows Update

Isso é importante.

Outros aplicativos e componentes também podem utilizar BITS.

Portanto, um problema em BITS pode afetar mais coisas do que apenas Windows Update.

Da mesma forma, encontrar um job BITS não significa automaticamente que ele pertence ao Windows Update.

BITS parado não significa BITS quebrado

Já vimos essa regra na Parte 8.

O serviço pode iniciar quando necessário.

O que interessa é:

ele consegue executar o trabalho quando solicitado?

Como observar jobs BITS?

No PowerShell:

Get-BitsTransfer

Para visualizar trabalhos em contextos permitidos:

Get-BitsTransfer -AllUsers

A execução pode exigir privilégios administrativos.

O que podemos observar?

Dependendo do trabalho:

DisplayName;
JobState;
BytesTotal;
BytesTransferred;
FilesTotal;
FilesTransferred.

Essas informações podem ajudar a saber se uma transferência:

está ativa;
está suspensa;
apresentou erro;
terminou.

Não remova jobs imediatamente

Primeiro identifique:

de quem é o job?

qual arquivo?

qual origem?

qual estado?

JobState

Estados diferentes podem aparecer.

O importante é não tratar todos como:

“travado”.

Um trabalho pode estar aguardando condições apropriadas.

Se houver erro

Inspecione o trabalho antes de removê-lo.

A mensagem pode revelar:

problema de rede;
servidor;
credenciais;
arquivo;
comunicação.

Família 0x802000xx

Existe uma família de códigos associada ao BITS.

Quando encontramos um erro nessa faixa, a investigação pode se concentrar mais diretamente no mecanismo de transferência.

0x80200010

Um código conhecido dessa família é:

0x80200010

Ele pode aparecer quando BITS não encontra uma conexão de rede utilizável para realizar o trabalho.

Não significa necessariamente “sem internet”

Esse é um ponto fundamental.

O navegador pode abrir sites.

Mesmo assim, BITS pode não conseguir utilizar adequadamente a conexão para aquele trabalho.

Precisamos verificar:

estado da rede;
proxy;
política;
interface;
contexto do serviço.

“Google abre” não encerra o diagnóstico

Um navegador abrir:

google.com

prova apenas que aquele navegador conseguiu realizar aquela comunicação.

Não prova que:

WinHTTP;
BITS;
Delivery Optimization;
Windows Update;

estão utilizando exatamente o mesmo caminho e configuração.

WinHTTP

Consulte:

netsh winhttp show proxy

Você pode encontrar algo como:

Direct access

ou uma configuração de proxy.

Não execute reset primeiro

Evite começar com:

netsh winhttp reset proxy

Primeiro veja:

qual configuração existe.

Em ambiente empresarial, o proxy pode ser obrigatório.

Proxy errado

Se existe proxy antigo ou incorreto, componentes de sistema podem falhar mesmo que o navegador funcione.

Proxy corporativo

Se o computador pertence a uma empresa, verifique políticas antes de alterar.

Execute:

gpresult /r

VPN

Clientes VPN podem alterar:

rotas;
DNS;
adaptadores;
filtros;
proxy;
caminho da comunicação.

Teste controlado

Quando apropriado:

registre o erro;
desconecte a VPN;
teste novamente;
compare.

Mas somente se a política do ambiente permitir.

Se funciona sem VPN

Isso não significa automaticamente que:

“a VPN é ruim”.

Pode existir:

rota;
filtragem;
configuração;
política;
incompatibilidade.

Agora temos uma direção para investigar.

Se funciona somente com VPN

Também é uma pista.

Talvez a rede normal esteja bloqueando algo que a VPN contorna.

Teste em outra rede

Quando possível e apropriado, testar o mesmo computador em outra rede confiável pode ser extremamente útil.

Exemplo

Rede doméstica A:

Windows Update não baixa.

Hotspot/rede B:

baixa normalmente.

Isso aumenta a suspeita sobre:

roteador;
DNS;
firewall;
filtragem;
operadora;
caminho de rede.

Mas cuidado com hotspot

Atualizações podem consumir bastante tráfego.

Não utilize conexão móvel limitada sem considerar:

franquia;
custo;
política de dados.

Conexão limitada

O Windows permite marcar determinadas redes como:

conexão limitada

ou:

metered connection.

Isso pode alterar o comportamento de downloads.

Verifique nas Configurações

Abra as propriedades da rede utilizada.

Veja se:

Conexão limitada

está habilitada.

Não desative automaticamente

Talvez o usuário tenha ativado intencionalmente para controlar consumo.

Delivery Optimization

Além do BITS, Windows moderno utiliza:

Delivery Optimization

em diferentes cenários de distribuição de conteúdo.

Serviço:

DoSvc

Verificar serviço

sc query dosvc

Mas novamente:

Stopped ≠ quebrado.

Configurações de Delivery Optimization

Abra:

Configurações → Windows Update → Opções avançadas → Otimização de Entrega

Dependendo da versão do Windows, existem opções relacionadas a:

downloads;
dispositivos na rede;
internet;
largura de banda.

Delivery Optimization pode usar outros computadores?

Dependendo da configuração, sim.

O sistema pode obter partes do conteúdo por mecanismos de distribuição que incluem peers.

Isso significa que Windows Update depende de outros PCs?

Não.

A arquitetura possui mecanismos próprios de obtenção de conteúdo.

O uso de peers depende da configuração e disponibilidade.

Downloads de outros PCs não devem ser confundidos com upload público obrigatório

As opções de Delivery Optimization determinam como o compartilhamento pode ocorrer.

Consulte a configuração real do computador antes de concluir.

Monitor de Atividade da Otimização de Entrega

Em versões compatíveis do Windows, as configurações de Delivery Optimization podem mostrar estatísticas relacionadas a:

origem dos downloads;
volume;
uploads.

Essas informações podem ajudar a entender de onde veio o conteúdo.

PowerShell e Delivery Optimization

O Windows possui cmdlets relacionados a Delivery Optimization em sistemas compatíveis.

Um comando útil para diagnóstico pode ser:

Get-DeliveryOptimizationStatus

Ele pode mostrar informações sobre downloads gerenciados pelo mecanismo.

Outro comando útil

Get-DeliveryOptimizationPerfSnap

pode fornecer dados relacionados ao desempenho/atividade do Delivery Optimization quando disponível.

Não baseie todo diagnóstico nesses cmdlets

A disponibilidade e saída podem variar conforme:

versão;
edição;
estado;
operação em andamento.

Use-os como fonte adicional.

Download 0% com DoSvc ativo

Isso não prova que existe transferência.

Precisamos observar:

bytes;
rede;
logs.

Download 0% e rede completamente parada

Agora investigamos:

fila;
comunicação;
política;
proxy;
erro anterior.

Download 0% mas disco ativo

Pode existir:

preparação;
verificação;
cache;
processamento local.

WindowsUpdate.log continua sendo importante

Gere:

Get-WindowsUpdateLog

Procure:

código;
horário;
URL/contexto quando registrado;
download;
falha;
retry.

Retry

O Windows pode repetir uma transferência automaticamente.

Isso pode produzir um comportamento como:

0% → espera → 0% → tenta novamente.

Não clique “Tentar novamente” cinquenta vezes

Cada tentativa pode:

gerar mais logs;
reiniciar fluxo;
dificultar a leitura.

Faça uma tentativa controlada e registre o horário.

Download reinicia do zero

Imagine:

30%

↓

25%

↓

0%.

Isso merece investigação.

Possíveis causas

comunicação instável;
conteúdo descartado;
falha de validação;
cache inconsistente;
armazenamento;
serviço;
proxy.

Não culpe a internet imediatamente

Se o download chega a 100% e depois volta para 0%, talvez o problema esteja:

depois da transferência.

Por exemplo:

validação.

Parte 7 volta a ser relevante

Se aparecem erros como:

0x80096010

ou outros erros de confiança, o conteúdo pode estar sendo rejeitado.

SoftwareDistribution

O cache/estado local do Windows Update também pode participar de problemas de download.

Caminho:

C:\Windows\SoftwareDistribution

Download folder

Dentro da estrutura de SoftwareDistribution existem dados associados ao conteúdo baixado.

Mas não saia apagando arquivos individualmente.

Quando reconstruir SoftwareDistribution?

Pode fazer sentido quando existem evidências de:

cache local inconsistente;
conteúdo preso;
download repetidamente corrompido;
metadados/estado local problemático.

Procedimento controlado

Quando realmente necessário:

net stop wuauserv

net stop bits

Depois:

ren C:\Windows\SoftwareDistribution SoftwareDistribution.old

Depois:

net start bits

net start wuauserv

Reinicie quando apropriado

Depois, Windows Update recriará os componentes necessários.

O que você perde ao reconstruir?

O Windows precisa reconstruir determinados estados/cache locais.

Por isso, não faça isso sem necessidade.

SoftwareDistribution.old

Não precisa ser apagada imediatamente.

Primeiro:

teste Windows Update;
confirme funcionamento;
preserve-a temporariamente se precisar comparar.

Depois, quando não for mais necessária, faça a limpeza de maneira consciente.

catroot2 não é SoftwareDistribution

Não renomeie automaticamente:

catroot2

só porque o download falhou.

catroot2 ganha relevância principalmente em determinados problemas de:

catálogo;
assinatura;
validação.

Download e espaço em disco

Uma transferência também pode falhar porque não existe espaço suficiente para armazenar/processar o conteúdo.

Execute:

Get-Volume

Não espere o disco chegar a zero bytes

Windows precisa de espaço para:

download;
temporários;
descompactação;
servicing;
rollback.

Erro 0x80070070

Se aparecer:

0x80070070

volte à Parte 6.

O problema agora é:

espaço.

Não BITS.

Download e antivírus

Software de segurança pode inspecionar:

tráfego;
arquivos;
conteúdo baixado.

Isso não significa que devemos desativá-lo.

Como investigar?

Procure:

logs do produto;
horário;
bloqueio;
quarentena;
evento.

Não desligue proteção permanentemente

Se existe suspeita legítima de interferência, faça um teste controlado conforme as orientações do produto e do ambiente.

Firewall

A mesma regra.

Não faça:

“desative o firewall e tente.”

como procedimento permanente.

Primeiro descubra se existe bloqueio.

Windows Defender Firewall

Pode registrar eventos dependendo da configuração de auditoria/log.

Em ambientes corporativos, regras podem ser gerenciadas.

DNS

Problemas de resolução podem impedir acesso aos serviços necessários.

Verifique:

ipconfig /all

Limpar cache DNS

Quando existe evidência de cache inconsistente:

ipconfig /flushdns

Mas não trate isso como solução universal.

Trocar DNS para 8.8.8.8 resolve?

Talvez em um problema específico de resolução.

Mas trocar DNS indiscriminadamente pode:

ignorar DNS corporativo;
quebrar resolução interna;
não resolver o problema real.

DNS público não é diagnóstico

Primeiro descubra:

o DNS atual está falhando?

Ping não testa Windows Update

Outro mito.

Executar:

ping microsoft.com

e receber resposta não prova que Windows Update funciona.

Ping utiliza ICMP.

Windows Update precisa de comunicação por outros protocolos e endpoints.

Falha de ping também não prova bloqueio do Update

Um servidor pode não responder ICMP e ainda aceitar comunicação necessária ao serviço.

Test-NetConnection

PowerShell pode ajudar em testes específicos:

Test-NetConnection

Mas utilize um destino e porta relevantes ao diagnóstico.

Não invente endpoints

Use documentação e evidências do ambiente para determinar o destino necessário.

TLS

A transferência pode depender de comunicação HTTPS.

Se existe problema de:

TLS;
certificado;
inspeção;
relógio;

o download pode falhar.

0x80072F8F

Se aparece:

0x80072F8F

investigue:

horário;
TLS;
certificados;
comunicação segura.

0x80072EE2

Se aparece:

0x80072EE2

investigue:

timeout.

0x80072EFE

Se aparece:

0x80072EFE

investigue:

conexão abortada.

0x80072EFD

Se aparece:

0x80072EFD

investigue:

falha para estabelecer conexão.

A interface pode mostrar o mesmo sintoma

Todos esses erros podem resultar visualmente em algo parecido:

Baixando — 0%.

Por isso o código é mais importante do que o percentual.

Família 0x802000xx em maior profundidade

Essa família pode trazer códigos relacionados a operações BITS.

Não tente memorizar todos.

Use o código para identificar:

estado do job;
rede;
arquivo;
servidor;
protocolo;
transferência.

0x80200011

Outro código dessa família pode estar relacionado a tentativa de utilizar um protocolo que não é suportado pelo BITS naquele contexto.

Isso direciona o diagnóstico para:

origem;
configuração;
trabalho.

0x80200013

Pode estar associado a problemas envolvendo faixas/ranges do conteúdo solicitado.

Nesse tipo de cenário, intermediários de rede e servidor podem entrar na investigação.

0x8020001B

Pode aparecer em cenários em que as credenciais utilizadas para determinado proxy não são aceitas.

Isso é particularmente relevante em:

empresas;
proxies autenticados.

Não salve credenciais aleatórias

Se existe proxy corporativo, siga a arquitetura de autenticação definida pela organização.

0x80200049

Outro código da família pode estar associado a trabalho BITS em estado inadequado para determinada operação.

Novamente:

estado do job importa.

A família é grande

O objetivo deste guia não é decorar centenas de constantes.

É ensinar a reconhecer:

0x802000xx

↓

BITS / transferência

↓

identificar código específico

↓

consultar estado do job

↓

correlacionar com rede e logs.

BITS pode possuir fila problemática

Quando existe evidência de jobs quebrados, podemos investigar a fila.

Mas remover todos os jobs de todos os usuários é uma ação agressiva.

Por quê?

Pode afetar outras aplicações que utilizam BITS.

Portanto:

identifique antes de remover.

bitsadmin

Tutoriais antigos utilizam:

bitsadmin

A ferramenta aparece em documentação e sistemas antigos, mas para administração moderna é preferível utilizar mecanismos atuais, como PowerShell, quando disponíveis.

Não copie tutoriais antigos sem contexto

Windows Update mudou bastante ao longo das versões do Windows.

Um procedimento criado para:

Windows XP;
Windows 7;

não deve ser automaticamente aplicado ao Windows 11.

Windows 10 e Windows 11

Mesmo dentro dessas famílias, componentes e comportamentos podem evoluir.

Por isso, sempre combine:

documentação atual;
build;
logs.

Rede Wi-Fi ruim pode afetar download?

Sim.

Mas “Wi-Fi conectado” não significa conexão estável.

Podemos ter:

perda;
latência;
roaming;
sinal fraco;
interferência.

Teste por cabo

Quando disponível, um teste Ethernet pode ser útil para comparar.

Se:

Wi-Fi falha

Ethernet funciona,

investigue a camada Wi-Fi.

Não significa que Windows Update precisa de cabo

É apenas um teste comparativo.

Packet loss

Perda de pacotes pode afetar transferências.

Mas novamente:

ping é apenas uma ferramenta parcial.

Use o comportamento real do download e outras evidências.

Roteador

Se vários dispositivos apresentam problemas para acessar serviços Microsoft na mesma rede, investigue:

roteador;
DNS;
firewall;
filtragem.

Se apenas um PC falha

A prioridade muda para:

configuração local;
proxy;
driver;
software de segurança;
Windows Update;
cache.

Reiniciar roteador é diagnóstico?

Pode corrigir estados temporários, mas não explica a causa.

Se o problema retorna, investigue.

IPv6

Não desative IPv6 automaticamente.

O Windows possui suporte nativo e diferentes componentes podem utilizá-lo.

“Desative IPv6 para corrigir Windows Update”

Isso não é uma regra geral.

Se existe suspeita de problema IPv6, diagnostique:

endereço;
rota;
DNS;
conectividade.

MTU

Outro ajuste frequentemente sugerido:

“mude MTU para 1400”.

Não faça isso sem evidência.

MTU incorreto pode causar problemas, mas escolher um valor arbitrário não é diagnóstico.

Proxy, VPN, DNS, IPv6 e MTU

Todos podem afetar rede.

Mas isso não significa que todos devam ser alterados ao mesmo tempo.

Faça um teste por vez

Essa regra aparece novamente:

uma variável

↓

novo teste

↓

comparação.

Cenário completo 1

Sintoma:

Baixando — 0%.

WindowsUpdate.log:

0x80072EE2

Interpretação:

timeout.

Prioridade:

rede;
proxy;
caminho de comunicação.

Não:

DISM.

Cenário completo 2

Sintoma:

download chega a 100% e recomeça.

Log:

0x80096010

Interpretação:

falha de validação/integridade.

Prioridade:

conteúdo;
assinatura;
cache;
catálogos.

Cenário completo 3

Sintoma:

0%.

Código:

0x80070070

Interpretação:

espaço insuficiente.

Prioridade:

volume;
armazenamento.

Cenário completo 4

Sintoma:

download não começa.

BITS apresenta erro específico.

Agora:

job;
BITS;
rede;
proxy.

Cenário completo 5

Sintoma:

download funciona em hotspot, mas não no Wi-Fi doméstico.

Isso sugere investigar a rede doméstica antes de reparar Component Store.

Cenário completo 6

Sintoma:

todos os computadores da empresa falham.

Agora investigue:

WSUS;
proxy;
firewall;
política;
infraestrutura.

Não formate cinquenta computadores.

Rede medida

Quando a conexão está marcada como limitada, o comportamento de determinadas atualizações/downloads pode ser diferente.

Sempre confira essa configuração antes de considerar o mecanismo quebrado.

Horário ativo não controla tudo

Horário ativo está principalmente relacionado ao comportamento de reinicialização.

Não confunda com controle absoluto do download.

Pausar atualizações

Se atualizações estão pausadas, isso obviamente altera o comportamento.

Verifique:

Configurações → Windows Update

antes de iniciar troubleshooting profundo.

Política pode pausar ou adiar

Em ambiente gerenciado, configurações podem ser definidas administrativamente.

Não remova política para “testar”

Primeiro registre:

gpresult /h "%userprofile%\Desktop\gpresult.html"

Analise.

Tabela de diagnóstico de download

Sintoma/código	Primeira área	Ferramenta
Baixando 0%	Transferência/rede	WindowsUpdate.log
0x802000xx	BITS	Get-BitsTransfer
0x80072EE2	Timeout	Rede/proxy
0x80072EFE	Conexão abortada	Rede/proxy/filtros
0x80072EFD	Conexão não estabelecida	Rede/proxy/firewall
0x80072F8F	Comunicação segura	Hora/TLS/certificados
0x80240034	Download falhou	Procurar erro anterior
0x80096010	Validação	Assinatura/cache
0x80070070	Espaço	Get-Volume
Funciona em outra rede	Rede original	Roteador/DNS/filtros
Todos os PCs falham	Infraestrutura	Proxy/WSUS/política
Só um PC falha	Estado local	Proxy/serviços/cache

Checklist de download

Antes de resetar qualquer coisa:

atualização foi detectada?
qual KB?
qual código?
qual horário?
transferência iniciou?
existe atividade de rede?
BITS apresenta erro?
Delivery Optimization mostra atividade?
existe proxy?
existe VPN?
rede está marcada como limitada?
existe espaço?
outro computador falha?
outra rede funciona?
conteúdo chega a 100% e depois é rejeitado?
WindowsUpdate.log mostra erro anterior mais específico?

O que não fazer

Não:

redefina BITS sem diagnóstico;
remova todos os jobs;
troque DNS aleatoriamente;
desative IPv6;
altere MTU por palpite;
desligue firewall permanentemente;
desligue antivírus permanentemente;
remova proxy corporativo;
apague SoftwareDistribution durante instalação;
renomeie catroot2 sem evidência;
execute DISM para qualquer problema de download;
reinicie serviços enquanto servicing crítico está ocorrendo.

Fluxo de diagnóstico

Windows Update não baixa

↓

qual código?

↓

0x80072xxx?

rede/comunicação

↓

0x802000xx?

BITS/transferência

↓

0x800960xx ou 0x800Bxxxx?

validação/certificados

↓

0x80070070?

armazenamento

↓

sem código?

WindowsUpdate.log + atividade de rede

↓

BITS/DoSvc

↓

proxy/VPN/rede medida

↓

teste comparativo de rede quando apropriado

↓

estado local/cache

↓

corrigir apenas a camada identificada

↓

testar novamente

↓

validar download e instalação.

A grande lição dos erros de download

Uma atualização que não baixa pode estar falhando:

antes

durante

ou:

depois

da transferência.

A interface:

Baixando — 0%

não revela necessariamente qual dessas três situações está ocorrendo.

É por isso que WindowsUpdate.log, código de erro e testes controlados são mais úteis do que simplesmente:

“minha internet está funcionando”.

Erros de drivers no Windows Update: Driver Store, PnPUtil, SetupAPI, rollback e 0xC1900101

Windows Update não distribui apenas:

atualizações cumulativas;
correções de segurança;
atualizações do Windows;
componentes do sistema.

Ele também pode oferecer:

drivers.

É aqui que nasce uma série de problemas aparentemente contraditórios.

Por exemplo:

“Instalei o driver mais novo do fabricante e o Windows colocou outro.”

Ou:

“Windows Update está oferecendo um driver com uma data antiga.”

Ou:

“O computador funciona normalmente, mas o upgrade do Windows falha com 0xC1900101.”

Essas situações exigem entender como o Windows escolhe drivers.

Windows Update e drivers

O Windows pode obter drivers através de diferentes fontes.

Entre elas:

drivers já existentes no Driver Store;
Windows Update;
pacote do fabricante;
instalador OEM;
instalação manual através de INF.

Esses métodos podem instalar versões diferentes do mesmo dispositivo.

Driver não é apenas um arquivo .sys

Essa é uma simplificação comum.

Um pacote de driver pode conter:

arquivos .sys;
arquivos .inf;
catálogos .cat;
DLLs;
informações de instalação;
identificadores;
serviços;
configurações.

Por isso:

copiar somente um .sys não equivale a instalar corretamente um driver.

Nunca baixe DLL ou SYS aleatório

Se existe problema com driver, utilize:

Windows Update;
fabricante do computador;
fabricante do componente;
pacote confiável.

Evite sites que oferecem arquivos individuais para download.

O que é INF?

Arquivos:

.inf

descrevem como determinado pacote deve ser instalado.

Eles podem definir:

dispositivos suportados;
arquivos;
serviços;
configurações;
referências ao catálogo.

Driver Store

O Windows mantém pacotes de drivers no:

Driver Store.

Um caminho conhecido é:

C:\Windows\System32\DriverStore

Mas:

não altere manualmente essa pasta.

Não apague FileRepository

Dentro do Driver Store existe:

FileRepository

Tutoriais podem recomendar apagar diretórios dessa área para “limpar drivers antigos”.

Isso pode danificar:

dispositivos;
atualizações;
Plug and Play;
futuras instalações.

Use ferramentas suportadas.

PnPUtil

Uma das principais ferramentas nativas para gerenciamento e diagnóstico de drivers é:

pnputil

Listar drivers de terceiros

Execute:

pnputil /enum-drivers

Esse comando pode mostrar informações como:

Published Name;
Original Name;
Provider Name;
Class Name;
Driver Version;
Signer Name.

Published Name

Você pode encontrar algo como:

oem42.inf

Esse é o nome publicado do pacote dentro do sistema.

Original Name

Pode ser algo como:

netwtwxx.inf

O nome varia conforme o fabricante/pacote.

Não remova oem42.inf apenas pelo número

oem42.inf

não significa:

driver 42.

É apenas um nome publicado atribuído pelo Windows.

Outro computador pode atribuir número completamente diferente ao mesmo pacote.

Como listar dispositivos?

Versões atuais do PnPUtil possuem comandos para enumeração de dispositivos.

Por exemplo:

pnputil /enum-devices /connected

Isso ajuda a visualizar dispositivos conectados.

Gerenciador de Dispositivos

Abra:

devmgmt.msc

Ele continua sendo uma ferramenta importante.

Mas existe uma limitação:

“Nenhum símbolo amarelo” não significa “todos os drivers estão perfeitos”.

Um driver pode carregar e ainda causar problema

Ele pode:

funcionar parcialmente;
apresentar incompatibilidade;
falhar somente sob carga;
falhar durante upgrade;
interferir em suspensão;
provocar rollback.

Portanto:

Gerenciador de Dispositivos normal não elimina drivers da investigação.

IDs de Hardware

Uma das melhores maneiras de identificar exatamente um dispositivo é pelos:

Hardware IDs.

No Gerenciador de Dispositivos:

Propriedades → Detalhes → IDs de Hardware

Você pode encontrar algo parecido com:

PCI\VEN_xxxx&DEV_xxxx

ou:

USB\VID_xxxx&PID_xxxx

Por que Hardware ID é importante?

Porque nomes comerciais podem ser genéricos.

O ID ajuda a identificar:

fabricante;
família;
dispositivo;
variante.

Não instale driver apenas pelo nome

Por exemplo:

Realtek Audio

pode representar muitos dispositivos e pacotes diferentes.

Use:

modelo do computador;
Hardware ID;
sistema operacional;
arquitetura.

OEM versus fabricante do componente

Imagine um notebook com chip Intel.

Existe:

driver publicado pela Intel;
driver disponibilizado pelo fabricante do notebook.

Eles podem não ser idênticos.

Qual é melhor?

Não existe uma regra universal:

“sempre use o mais novo da Intel”.

O fabricante do notebook pode personalizar:

energia;
áudio;
vídeo;
teclas;
sensores;
firmware;
integração.

Por isso, o pacote OEM pode ser mais apropriado em determinados equipamentos.

Windows Update oferece driver aparentemente antigo

Esse é um dos casos que mais confunde usuários.

Exemplo conceitual:

Driver instalado:

2026

Windows Update oferece:

2025

O usuário conclui:

“Windows Update quer fazer downgrade.”

Talvez.

Mas a data sozinha não prova isso.

Data do driver não é único critério de ranking

A seleção de drivers pelo Windows considera informações do pacote e correspondência com o dispositivo.

Portanto, não compare apenas:

data.

Observe também:

versão;
Hardware ID;
INF;
fornecedor;
origem;
ranking/aplicabilidade.

Microsoft pode utilizar datas específicas em drivers

Datas de drivers podem ser utilizadas de maneira que não correspondam simplesmente à data em que o fabricante publicou o pacote comercialmente.

Portanto:

data antiga ≠ driver necessariamente inferior.

Veja o driver ativo

PowerShell:

Get-CimInstance Win32_PnPSignedDriver | Select-Object DeviceName,DriverVersion,DriverDate,DriverProviderName,InfName

Isso fornece uma visão ampla.

Para salvar

Get-CimInstance Win32_PnPSignedDriver | Select-Object DeviceName,DriverVersion,DriverDate,DriverProviderName,InfName | Out-File "$env:USERPROFILE\Desktop\drivers.txt"

Agora você possui um inventário.

Faça isso antes de grandes upgrades

Esse registro pode ser extremamente útil.

Se o upgrade falhar depois, você consegue comparar.

Atualizações opcionais

Alguns drivers podem aparecer em:

Windows Update → Opções avançadas → Atualizações opcionais

Isso permite avaliar determinados drivers separadamente das atualizações principais.

Não instale tudo porque está disponível

Opcional não significa:

obrigatório.

Se o dispositivo funciona corretamente e não existe necessidade específica, avalie antes de instalar.

Também não ignore automaticamente

Uma atualização opcional pode corrigir um problema real.

A decisão deve considerar:

problema atual;
fabricante;
versão;
changelog quando disponível;
compatibilidade.

Windows Update substituiu meu driver

Esse cenário pode acontecer.

Primeiro confirme que realmente ocorreu.

Compare antes e depois

Use:

pnputil /enum-drivers

Get-CimInstance Win32_PnPSignedDriver

Histórico de Atualizações

Veja também a seção relacionada a atualizações de driver.

Anote:

nome;
versão;
data da instalação.

Não conclua apenas porque o problema começou depois

A relação temporal é uma pista.

Precisamos confirmar qual driver mudou.

Rollback de driver

No Gerenciador de Dispositivos:

Propriedades → Driver

pode existir:

Reverter Driver.

Quando disponível, isso permite retornar ao driver anterior.

Botão cinza

Se:

Reverter Driver

está indisponível, o Windows pode não possuir uma versão anterior disponível para aquele dispositivo através desse mecanismo.

Não copie um .sys antigo manualmente

Isso pode deixar:

versão incompatível;
catálogo incorreto;
serviço inconsistente.

Use um pacote de driver adequado.

Driver Store possui múltiplas versões

Pode existir mais de um pacote capaz de atender determinado dispositivo.

Isso é normal.

PnP escolhe o melhor pacote aplicável

O Plug and Play avalia os pacotes disponíveis para determinar qual corresponde ao dispositivo conforme suas regras.

O que é Plug and Play?

Plug and Play é a infraestrutura do Windows responsável por detectar e configurar dispositivos.

Ela relaciona:

hardware;
IDs;
drivers;
recursos;
estado do dispositivo.

Windows Update trabalha com Plug and Play

Quando um driver é oferecido, ele precisa ser aplicável ao dispositivo correspondente.

Portanto, erros de driver pelo Windows Update também podem envolver:

PnP;
Driver Store;
assinatura;
INF;
dispositivo.

SetupAPI.dev.log

Um dos logs mais importantes para diagnóstico de driver é:

C:\Windows\INF\setupapi.dev.log

Para que serve?

Ele registra informações relacionadas à instalação de dispositivos e drivers.

Pode ajudar a responder:

qual INF foi considerado;
qual pacote foi selecionado;
instalação falhou?
qual código apareceu?

Esse log é extremamente valioso

Imagine:

Windows Update mostra:

Falha na instalação do driver.

A interface fornece pouca informação.

setupapi.dev.log

pode mostrar detalhes muito mais úteis.

Procure pelo dispositivo

Você pode utilizar:

Hardware ID;
nome do INF;
horário;
código.

Não leia o arquivo inteiro do início

Ele pode ser grande.

Use o horário da instalação.

Exemplo

Falha aconteceu:

16:42

Abra setupapi.dev.log e procure operações próximas desse horário.

Driver e assinatura

Pacotes de drivers precisam atender requisitos de assinatura aplicáveis.

Portanto, erros de:

certificado;
catálogo;
assinatura;

podem aparecer durante instalação de drivers.

Isso conecta esta parte à Parte 7.

Driver e catálogos

O pacote pode incluir arquivo:

.cat

utilizado na validação.

Não substitua o catálogo manualmente.

Driver falha no Windows Update mas instala pelo fabricante

Isso é uma pista interessante.

Pode existir diferença entre:

pacote;
versão;
método de distribuição;
estado do Windows Update.

Compare os pacotes.

Driver instala manualmente mas Windows Update continua oferecendo outro

Agora precisamos verificar:

Hardware ID;
versão ativa;
INF;
aplicabilidade;
pacote oferecido.

Não esconda imediatamente

Primeiro descubra por que Windows Update acredita que o pacote é apropriado.

Driver aparece repetidamente

Cenário:

Windows Update instala.

Reinicia.

Driver aparece novamente.

Possíveis causas:

instalação não concluiu;
dispositivo continua usando outro pacote;
pacote oferecido permanece aplicável;
instalação fez rollback.

Veja qual INF está ativo

PowerShell:

Get-CimInstance Win32_PnPSignedDriver | Select-Object DeviceName,InfName,DriverVersion,DriverProviderName

Depois compare com Driver Store

pnputil /enum-drivers

Driver com erro no Gerenciador de Dispositivos

Abra propriedades do dispositivo.

Observe:

Device status.

Pode existir um:

Code XX

Código do Gerenciador de Dispositivos não é código do Windows Update

Por exemplo:

Code 10

0x8024xxxx

pertencem a contextos diferentes.

Não misture.

Code 10

Geralmente indica que o dispositivo não consegue iniciar corretamente.

Mas ainda precisamos investigar:

driver;
hardware;
firmware;
dependências.

Code 28

Pode indicar ausência de driver adequado.

Nesse caso, precisamos identificar o dispositivo e localizar pacote correto.

Code 43

Pode indicar que o dispositivo informou um problema ao Windows.

Não significa automaticamente:

driver corrompido.

Pode envolver:

hardware;
firmware;
driver.

Não reinstale Windows por causa de um Code 43 sem investigar

Primeiro identifique o dispositivo e contexto.

Driver de vídeo

Drivers gráficos são especialmente complexos porque podem envolver:

kernel driver;
componentes de usuário;
painel;
áudio HDMI;
serviços;
componentes adicionais.

“Instalar somente o .inf” pode mudar o resultado

Um instalador completo do fabricante pode incluir mais componentes do que a instalação do driver básico.

Isso explica por que dois métodos de instalação podem produzir comportamentos diferentes.

Driver de rede

Se Windows Update atualiza o driver da placa de rede e a internet para de funcionar, temos um problema interessante:

o mecanismo necessário para buscar outro driver pode ter perdido conectividade.

Antes de atualizar driver de rede manualmente

Quando possível, tenha o pacote anterior disponível localmente.

Isso facilita rollback.

Driver de armazenamento

Drivers de:

SATA;
AHCI;
RAID;
NVMe;

merecem cuidado especial.

Um problema nessa camada pode afetar boot e upgrades.

Não altere AHCI/RAID na BIOS para corrigir Windows Update

Isso pode resultar em:

INACCESSIBLE_BOOT_DEVICE

se o Windows não estiver preparado para a mudança.

Driver de chipset

“Chipset driver” também pode ser um conjunto de componentes.

Não trate como um único arquivo.

Firmware pelo Windows Update

Alguns fabricantes também distribuem atualizações de firmware através do Windows Update.

Firmware não é exatamente a mesma coisa que driver.

Firmware exige cuidado adicional

Pode envolver:

BIOS/UEFI;
energia;
reinicialização;
BitLocker.

BitLocker antes de firmware

Verifique:

manage-bde -status

E tenha a chave de recuperação disponível quando um procedimento de firmware puder afetar medições do boot/TPM.

Não desligue durante atualização de firmware

Uma interrupção inadequada pode causar consequências muito mais sérias do que uma atualização cumulativa comum.

Driver e 0xC1900101

Agora chegamos à ligação com a Parte 5.

Código:

0xC1900101

durante upgrade é frequentemente associado a problemas de driver.

Mas isso não significa:

“atualize todos os drivers e tente novamente”.

Precisamos encontrar o driver suspeito

Use:

SetupDiag;
setupact.log;
setuperr.log;
setupapi.dev.log;
inventário de drivers.

Um driver pode funcionar no Windows atual e falhar no upgrade

Isso parece contraditório.

Mas não é.

Durante upgrade, o sistema passa por diferentes fases.

Um driver pode encontrar problemas durante:

SAFE_OS;
FIRST_BOOT;
SECOND_BOOT.

Drivers antigos

Um driver muito antigo merece atenção.

Mas:

idade não prova incompatibilidade.

Drivers recentes

Da mesma forma:

driver novo não prova compatibilidade.

Use evidência.

Software instala drivers sem parecer driver

Isso é muito importante.

Programas como:

VPN;
antivírus;
backup;
virtualização;
monitoramento;
filtros de rede;

podem instalar drivers.

Você pode não vê-los como “hardware”

Eles podem funcionar como:

filtros;
drivers virtuais;
adaptadores;
drivers de sistema.

Por isso clean boot possui limites

Clean boot desativa vários serviços e programas de inicialização.

Mas não necessariamente remove drivers de kernel carregados.

Upgrade falha mesmo em clean boot

Ainda pode existir:

driver;
filtro;
software de baixo nível.

driverquery

Outra ferramenta:

driverquery /v

Ela fornece informações sobre drivers carregados/instalados.

Salvar resultado

driverquery /v > "%userprofile%\Desktop\driverquery.txt"

Compare com PnPUtil

As ferramentas respondem perguntas diferentes.

pnputil

é especialmente útil para pacotes PnP/Driver Store.

driverquery

fornece informações sobre drivers do sistema.

Autoruns

Ferramentas avançadas de diagnóstico podem ajudar a identificar componentes de inicialização e drivers de terceiros.

Mas não desative itens indiscriminadamente.

Driver Verifier

Existe também:

Driver Verifier.

É uma ferramenta avançada para testar drivers.

Mas ela pode deliberadamente provocar falhas quando detecta comportamento problemático.

Não use Driver Verifier casualmente

Em um computador de produção, ativá-lo sem saber:

quais drivers testar;
como desativá-lo;
como recuperar o sistema;

pode criar problemas de inicialização.

Ele não é uma primeira ferramenta para Windows Update.

Atualizador de drivers de terceiros

Evite programas que prometem:

“atualizar todos os drivers automaticamente”.

Eles podem:

escolher pacote inadequado;
instalar versões genéricas;
dificultar rollback;
adicionar software desnecessário.

Fontes preferenciais

Em geral, priorize:

fabricante do computador;
fabricante do componente quando apropriado;
Windows Update;
Microsoft Update Catalog quando existe motivo técnico específico.

A ordem pode variar conforme o equipamento e problema.

Não use “mais novo” como único critério

O objetivo é:

driver adequado e estável para aquele hardware e sistema.

Como criar inventário antes de troubleshooting

Execute:

pnputil /enum-drivers > "%userprofile%\Desktop\pnputil-drivers.txt"

Depois:

driverquery /v > "%userprofile%\Desktop\driverquery.txt"

Depois:

Get-CimInstance Win32_PnPSignedDriver | Select-Object DeviceName,DriverVersion,DriverDate,DriverProviderName,InfName | Out-File "$env:USERPROFILE\Desktop\pnp-drivers.txt"

Agora temos três visões complementares.

Se Windows Update acabou de quebrar um dispositivo

Procedimento racional:

identifique o dispositivo;
registre Hardware ID;
registre driver atual;
consulte Histórico do Windows Update;
veja setupapi.dev.log;
confirme qual pacote mudou;
avalie rollback;
instale pacote correto quando necessário;
teste;
confirme se Windows Update volta a oferecer o pacote.

Se o driver volta novamente

Agora investigamos o mecanismo de seleção/aplicabilidade.

Não fique em um ciclo:

instala A

↓

Windows instala B

↓

instala A

↓

Windows instala B.

Descubra por que B está sendo selecionado.

Políticas para drivers

Ambientes administrados podem utilizar políticas relacionadas à distribuição de drivers.

Não altere políticas sem entender o impacto.

Windows Update e atualizações opcionais

Antes de instalar um driver opcional, pergunte:

qual problema estou tentando resolver?

Se a resposta for:

nenhum

talvez não exista necessidade imediata.

Exceção

Se o fabricante ou documentação recomenda aquela atualização para:

segurança;
estabilidade;
compatibilidade;

ela merece avaliação mesmo que o dispositivo pareça funcionar.

Drivers e segurança

Drivers executam em níveis privilegiados do sistema.

Por isso, drivers vulneráveis ou incompatíveis merecem atenção.

Não mantenha deliberadamente um driver vulnerável apenas porque:

“está funcionando”.

Mas também não instale qualquer versão

Segurança e compatibilidade precisam ser consideradas juntas.

Tabela de diagnóstico de drivers

Sintoma	Primeira investigação
Driver falha no Windows Update	setupapi.dev.log
Dispositivo parou após Update	Histórico + driver ativo
Driver reaparece	INF + versão + aplicabilidade
Driver parece antigo	Versão + ID + pacote, não só data
0xC1900101	SetupDiag + drivers
Code 10	Driver/dispositivo
Code 28	Driver ausente
Code 43	Driver/firmware/hardware
Rede parou após driver	Rollback/pacote OEM
Firmware apareceu no Update	Fabricante + BitLocker
Driver Store suspeito	PnPUtil, não exclusão manual

Tabela de ferramentas

Objetivo	Ferramenta
Gerenciador de Dispositivos	`devmgmt.msc`
Listar pacotes de driver	`pnputil /enum-drivers`
Dispositivos conectados	`pnputil /enum-devices /connected`
Inventário PnP	`Get-CimInstance Win32_PnPSignedDriver`
Drivers do sistema	`driverquery /v`
Log de instalação	`C:\Windows\INF\setupapi.dev.log`
Upgrade	SetupDiag
BitLocker	`manage-bde -status`

O que não fazer

Não:

apague DriverStore manualmente;
apague FileRepository;
exclua arquivos .sys;
baixe drivers de sites desconhecidos;
instale “driver updater” genérico;
atualize todos os drivers sem motivo;
use apenas a data para escolher;
altere AHCI/RAID por tentativa;
force firmware sem verificar fabricante;
ignore BitLocker antes de alterações de firmware;
use Driver Verifier casualmente;
remova oemXX.inf sem saber qual dispositivo depende dele;
atribua todo 0xC1900101 ao driver de vídeo.

Fluxo de diagnóstico

Windows Update apresenta erro de driver

↓

qual dispositivo?

↓

Hardware ID

↓

qual driver está ativo?

↓

Get-CimInstance Win32_PnPSignedDriver

↓

qual INF?

↓

pnputil /enum-drivers

↓

quando foi instalado?

↓

Histórico do Windows Update

↓

o que aconteceu durante a instalação?

↓

setupapi.dev.log

↓

Dispositivo parou?

avaliar rollback/pacote OEM

↓

Driver reaparece?

investigar ranking/aplicabilidade

↓

Upgrade apresenta 0xC1900101?

SetupDiag + Setup logs + inventário

↓

corrigir somente o componente identificado

↓

testar

↓

validar dispositivo e Windows Update.

Erros de atualização do .NET Framework: 0x800F081F, .NET 3.5, DISM, Features on Demand e CBS.log

Entre os problemas encontrados no Windows Update, existe uma categoria que costuma gerar muita confusão:

atualizações do .NET Framework.

O usuário encontra algo parecido com:

Atualização Cumulativa do .NET Framework

e recebe:

Falha na instalação.

Depois procura uma solução e encontra recomendações como:

“baixe o .NET mais recente.”

Isso pode não resolver absolutamente nada.

O primeiro passo é entender:

qual .NET estamos diagnosticando?

.NET Framework e .NET não são exatamente a mesma coisa

Atualmente existem duas famílias que usuários frequentemente chamam simplesmente de:

“.NET”.

Temos:

.NET Framework

.NET moderno.

Essa distinção é essencial.

.NET Framework

O .NET Framework é uma tecnologia utilizada há muitos anos por aplicações Windows e possui integração profunda com o próprio Windows.

Versões como:

.NET Framework 3.5;
.NET Framework 4.x;

podem estar relacionadas aos componentes e recursos do sistema operacional.

.NET moderno

Também existe a plataforma moderna:

.NET

com versões independentes e runtimes que podem ser instalados lado a lado.

Aplicativos modernos podem exigir versões específicas desses runtimes.

Instalar .NET moderno não “atualiza” automaticamente o .NET Framework

Esse é um dos erros conceituais mais comuns.

Imagine:

Windows Update falha ao instalar uma atualização do:

.NET Framework 3.5 e 4.8.x

e alguém recomenda instalar uma versão moderna do:

.NET Runtime.

São componentes diferentes.

A instalação pode terminar perfeitamente e o Windows Update continuar apresentando exatamente o mesmo erro.

Primeiro identifique a atualização

Abra:

Configurações → Windows Update → Histórico de atualizações

Anote:

KB;
descrição;
data;
código de erro.

Não pesquise apenas “erro .NET”

Pesquise tecnicamente:

KB + código + versão/build do Windows.

Isso reduz bastante o universo de possibilidades.

Descubra sua versão do Windows

Execute:

winver

Anote:

edição;
versão;
build.

Por que a build importa?

Uma KB pode:

ser destinada a determinada versão;
ter pré-requisitos;
ter sido substituída;
possuir conteúdo diferente conforme a plataforma.

.NET Framework 3.5

No Windows moderno, o .NET Framework 3.5 é especialmente interessante porque pode aparecer como um:

recurso do Windows.

Ele inclui tecnologias mais antigas necessárias a determinados programas.

Aplicativo pede .NET Framework 3.5

Ao executar um programa antigo, o Windows pode solicitar a instalação do recurso.

Isso é diferente de simplesmente instalar um runtime moderno do .NET.

Recursos do Windows

Abra:

optionalfeatures

Você pode encontrar uma opção relacionada a:

.NET Framework 3.5

Não marque e desmarque repetidamente

Se a instalação falha, precisamos descobrir:

por quê.

DISM e recursos opcionais

Podemos consultar recursos com:

DISM /Online /Get-Features

Para localizar informações relacionadas ao .NET:

DISM /Online /Get-Features /Format:Table

PowerShell

Também podemos utilizar:

Get-WindowsOptionalFeature -Online

E filtrar quando necessário.

NetFx3

O recurso relacionado ao .NET Framework 3.5 costuma ser identificado como:

NetFx3

Podemos consultar:

Get-WindowsOptionalFeature -Online -FeatureName NetFx3

Estado do recurso

Ele pode aparecer em estados diferentes conforme a instalação e disponibilidade do conteúdo.

Isso ajuda a saber se:

está habilitado;
está desabilitado;
conteúdo está disponível.

Features on Demand

Aqui entra um conceito importante:

Features on Demand.

Alguns recursos do Windows podem depender de conteúdo que não está integralmente presente na instalação local.

Quando habilitamos determinado recurso, o Windows pode precisar obter arquivos de origem apropriados.

Isso explica alguns erros 0x800Fxxxx

Se o Windows não consegue localizar ou obter o conteúdo necessário, a instalação do recurso pode falhar.

0x800F081F

Já vimos esse código na Parte 4.

0x800F081F

corresponde a um cenário em que os arquivos de origem necessários não puderam ser encontrados.

Em troubleshooting do .NET Framework 3.5, esse código é particularmente conhecido.

O erro não significa “.NET corrompido”

Isso é importante.

0x800F081F

não deve ser traduzido automaticamente como:

“.NET está corrompido”.

A questão principal pode ser:

onde estão os arquivos necessários?

Exemplo

Usuário tenta habilitar:

NetFx3

Windows procura conteúdo.

A origem necessária não está disponível.

Resultado:

0x800F081F.

Nesse cenário, executar dezenas de reparos aleatórios pode não resolver.

Precisamos fornecer uma origem adequada

Uma mídia compatível do Windows pode conter arquivos necessários para determinados recursos.

Um caminho conhecido é:

sources\sxs

Exemplo de mídia montada

Imagine que a mídia esteja em:

D:

O caminho pode ser:

D:\sources\sxs

Instalação com DISM

Em um cenário apropriado:

DISM /Online /Enable-Feature /FeatureName:NetFx3 /All /Source:D:\sources\sxs /LimitAccess

Mas existe uma condição fundamental:

a origem precisa ser compatível.

Não use qualquer ISO

Uma ISO aleatória encontrada na internet pode:

não corresponder ao sistema;
ter outra arquitetura;
outra versão;
outro nível de atualização;
ter sido modificada.

Use mídia confiável e apropriada.

Verifique arquitetura

PowerShell:

Get-ComputerInfo | Select-Object WindowsProductName,WindowsVersion,OsBuildNumber,OsArchitecture

/LimitAccess

No comando anterior usamos:

/LimitAccess

Isso instrui o DISM a não utilizar Windows Update como fonte online naquele processo.

Portanto, a origem informada precisa realmente fornecer o conteúdo necessário.

Não copie sources\sxs de computador aleatório

Isso não é uma boa estratégia.

Utilize fonte compatível e confiável.

0x800F0906

Outro erro que pode aparecer em cenários de recursos opcionais é:

0x800F0906.

Ele pode ocorrer quando o Windows não consegue obter os arquivos necessários.

Rede ou política podem participar

Agora perceba a conexão com partes anteriores.

Se o conteúdo precisa ser obtido externamente, podem interferir:

conectividade;
proxy;
política;
WSUS;
configuração corporativa.

Computadores corporativos e .NET 3.5

Esse é um cenário clássico.

O computador é gerenciado.

O usuário tenta instalar:

.NET Framework 3.5

e recebe erro.

O problema pode estar relacionado à forma como o dispositivo foi configurado para obter conteúdo opcional.

Não remova WSUS por tentativa

Antes:

gpresult /r

Ou gere relatório:

gpresult /h "%userprofile%\Desktop\gpresult.html"

Políticas de componentes opcionais

Ambientes gerenciados podem definir de onde o Windows deve obter:

conteúdo de reparo;
Features on Demand;
recursos opcionais.

Isso pode mudar completamente o troubleshooting.

0x800F0954

Outro código frequentemente encontrado em cenários de instalação de recursos opcionais é:

0x800F0954.

Ele merece atenção especial em computadores gerenciados porque pode estar relacionado ao caminho/política utilizada para obter o conteúdo necessário.

Não transforme 0x800F0954 em “apague uma chave do WSUS”

Existem tutoriais que sugerem modificar Registro imediatamente.

Isso pode violar a configuração definida pela empresa.

Primeiro determine:

computador é gerenciado?
usa WSUS?
existe política para conteúdo opcional?
de onde deveria vir o recurso?

Se for computador corporativo

A correção pode precisar ocorrer na:

infraestrutura/política

e não individualmente em cada máquina.

Esse princípio é importante

Se:

100 computadores

apresentam o mesmo erro de .NET 3.5,

não comece reparando o Component Store de 100 máquinas.

Investigue a configuração central.

E se apenas um computador falha?

Agora uma causa local ganha mais força.

Podemos investigar:

Component Store;
estado do recurso;
cache;
corrupção;
políticas locais;
servicing.

CBS.log

Para falhas de .NET Framework integrado ao Windows e recursos opcionais, um dos logs mais importantes é:

C:\Windows\Logs\CBS\CBS.log

Procure pelo horário

Anote quando a tentativa ocorreu.

Depois procure:

código;
package;
feature;
NetFx3;
erro secundário.

Erro mostrado pela interface pode não ser o mais específico

Exemplo conceitual:

Windows Update:

falha genérica

↓

CBS:

0x800F081F

Agora sabemos:

source missing.

DISM.log

Também consulte:

C:\Windows\Logs\DISM\dism.log

quando a operação envolveu DISM ou gerenciamento de recursos.

Copie os logs antes de novas tentativas

Crie:

C:\DiagnosticoWU

Depois:

copy C:\Windows\Logs\CBS\CBS.log C:\DiagnosticoWU\CBS.txt

copy C:\Windows\Logs\DISM\dism.log C:\DiagnosticoWU\DISM.txt

Isso preserva uma fotografia

Novas tentativas acrescentam informações aos logs.

Preservar uma cópia facilita comparação.

.NET Framework 4.x

Agora temos outro cenário.

O Windows pode receber atualizações cumulativas relacionadas ao .NET Framework 4.x.

Se uma dessas atualizações falha, não assuma que o problema é igual ao NetFx3.

Não use sources\sxs automaticamente

sources\sxs

é especialmente relevante para determinados recursos opcionais, como NetFx3.

Isso não significa que todo erro de atualização cumulativa do .NET Framework deve ser tratado com:

/Source:D:\sources\sxs.

Atualização cumulativa do .NET Framework falha

Agora investigue:

KB;
código;
CBS.log;
Component Store;
aplicabilidade;
servicing.

0x80073712

Se aparecer:

0x80073712

temos evidência de problema relacionado ao Component Store.

Volte à Parte 4.

0x800F0831

Se aparecer:

0x800F0831

investigue dependências e pacotes do servicing.

0x800F081F

Se aparecer durante servicing:

investigue a origem/componente ausente no contexto registrado pelo CBS.

Não reinstale aplicativos antes de entender

Se a KB do .NET Framework falha no Windows Update, reinstalar:

navegador;
Office;
aplicativo de contabilidade;

não necessariamente terá qualquer efeito.

Aplicativo falha depois de atualização .NET

Agora temos outro problema.

Precisamos separar:

Windows Update falhou

de:

Windows Update instalou corretamente, mas o aplicativo deixou de funcionar.

Se a KB instalou corretamente

Veja:

Histórico de Atualizações;
Event Viewer;
logs do aplicativo.

Não desinstale a KB imediatamente

Primeiro confirme:

quando o problema começou;
qual erro o aplicativo gera;
se existe atualização do próprio aplicativo.

Aplicações antigas

Aplicativos antigos podem depender de:

.NET Framework 3.5;
componentes legados;
configurações específicas.

Se o recurso está desabilitado, o aplicativo pode não abrir.

Instalar .NET 8, 9 ou outra versão moderna resolve?

Não necessariamente.

Se o aplicativo exige:

.NET Framework 3.5

ele continua precisando desse componente.

Side-by-side

Versões modernas do .NET podem coexistir conforme o modelo suportado.

Isso é diferente do modelo histórico do .NET Framework.

Não remova versões aleatoriamente

Um aplicativo pode depender de um runtime específico.

Antes de remover:

descubra aplicação;
arquitetura;
runtime necessário.

x86 e x64

Aplicações podem utilizar arquiteturas diferentes.

Isso também pode afetar runtimes instalados.

Não conclua que:

“tenho x64, então x86 é inútil”.

Um aplicativo de 32 bits pode precisar de componentes apropriados.

Atualização do .NET fica repetindo

Cenário:

Windows Update instala uma KB do .NET Framework.

Reinicia.

A mesma KB aparece novamente.

Use a mesma metodologia da Parte 9.

Confirme instalação

Veja:

Histórico de Atualizações.

Depois consulte servicing.

DISM /Get-Packages

Execute:

DISM /Online /Get-Packages

Procure pacotes relevantes.

Não dependa somente do nome exibido

Uma atualização pode corresponder a pacotes internos com nomes diferentes.

CBS.log ajuda a relacioná-los.

Atualização falha em 0%

Se é uma KB do .NET, não conclua que .NET está corrompido.

Pode ser:

download;
rede;
espaço.

A fase continua sendo importante.

Atualização baixa e falha durante instalação

Agora servicing ganha prioridade.

Atualização instala e desfaz após reboot

Investigue:

CBS;
estado pendente;
Component Store;
código secundário.

DISM

Quando existe evidência de Component Store problemático:

DISM /Online /Cleanup-Image /CheckHealth

Depois:

DISM /Online /Cleanup-Image /ScanHealth

Se houver motivo para reparar:

DISM /Online /Cleanup-Image /RestoreHealth

Não execute RestoreHealth automaticamente em qualquer erro .NET

Primeiro descubra:

há corrupção de Component Store?

SFC

Depois de reparo de Component Store, em determinados cenários:

sfc /scannow

pode verificar e reparar arquivos protegidos do sistema.

DISM e SFC têm funções diferentes

DISM pode trabalhar com a imagem e Component Store.

SFC verifica arquivos protegidos do sistema utilizando os mecanismos apropriados.

“SFC encontrou corrupção e reparou”

Isso é informação útil.

Mas ainda precisamos testar novamente a KB.

“SFC não encontrou violações”

Isso não prova que:

Windows Update;
BITS;
WSUS;
proxy;

estão funcionando.

Ferramenta de reparo do .NET Framework

A Microsoft historicamente disponibiliza ferramentas específicas para determinados problemas do .NET Framework.

Mas não trate uma ferramenta de reparo como substituta do diagnóstico de:

Windows Update;
CBS;
Features on Demand;
política.

Reparar .NET e reparar Windows não são sempre a mesma coisa

Esse é outro conceito importante.

Se a falha está no:

Component Store

o problema é mais amplo do que uma única aplicação .NET.

E se DISM não consegue reparar?

Imagine:

DISM /RestoreHealth

retorna:

0x800F081F.

Agora temos:

fonte de reparo ausente.

Nesse caso, podemos precisar fornecer uma origem compatível, conforme já explicado na Parte 4.

install.wim e install.esd

Uma mídia pode possuir:

install.wim

ou:

install.esd.

Antes de utilizar uma fonte, descubra:

arquivo;
índices;
edição.

Ver índices

Para WIM:

DISM /Get-WimInfo /WimFile:D:\sources\install.wim

Para ESD:

DISM /Get-WimInfo /WimFile:D:\sources\install.esd

Fonte errada também falha

Não adianta apontar DISM para uma ISO qualquer.

A fonte precisa ser adequada ao sistema e à operação.

Windows Update como fonte de reparo

Em determinados cenários, DISM pode utilizar componentes obtidos através dos mecanismos do Windows Update.

Se a própria comunicação do Windows Update está quebrada, isso pode impedir o reparo.

Isso cria uma cadeia interessante

Component Store precisa de reparo

↓

DISM tenta obter conteúdo

↓

Windows Update/rede não consegue fornecer

↓

RestoreHealth falha.

Nesse caso precisamos corrigir ou contornar a origem do conteúdo.

Ambiente corporativo novamente

Políticas podem controlar de onde o conteúdo de reparo será obtido.

Por isso:

DISM funciona em casa, mas falha na empresa

pode ter explicação de infraestrutura.

.NET 3.5 e internet funcionando

Mesmo que sites abram, o recurso ainda pode não ser obtido.

Lembre-se da Parte 2:

navegador funcionando ≠ todos os componentes do Windows conseguem alcançar sua fonte.

Fluxo para .NET Framework 3.5

Aplicativo pede .NET 3.5

↓

habilitar NetFx3

↓

Instalou?

Fim.

Falhou?

↓

anotar código

↓

0x800F081F?

investigar source

↓

0x800F0954?

investigar política/origem

↓

0x800F0906?

investigar obtenção do conteúdo

↓

CBS.log + DISM.log

↓

corrigir origem/política/componentes

↓

testar novamente.

Fluxo para KB cumulativa do .NET Framework

Windows Update oferece KB .NET

↓

download conclui?

Não

Volte à camada de download.

Sim

↓

instalação falha

↓

código + horário

↓

CBS.log

↓

Component Store / pacote / aplicabilidade

↓

DISM quando houver evidência

↓

reparar causa

↓

reinstalar KB

↓

validar Histórico.

Cenário prático 1

Usuário:

“Não consigo instalar .NET Framework 3.5.”

Erro:

0x800F081F

CBS confirma arquivos de origem ausentes.

Agora faz sentido trabalhar com:

fonte apropriada;
mídia compatível;
Features on Demand.

Cenário prático 2

Empresa inteira:

NetFx3 falha com 0x800F0954.

Agora a prioridade é:

política;
WSUS;
fonte de conteúdo opcional.

Não reparar 100 Component Stores.

Cenário prático 3

Uma atualização cumulativa .NET falha com:

0x80073712.

Agora o problema aponta para:

Component Store.

A estratégia muda.

Cenário prático 4

KB .NET permanece em:

Baixando 0%.

Não comece reparando .NET.

O problema pode estar em:

BITS;
Delivery Optimization;
rede.

Cenário prático 5

KB instala e depois aplicativo não abre.

Primeiro confirme:

KB realmente instalou?

Depois:

Event Viewer;
log da aplicação;
versão necessária;
atualização do fornecedor.

Tabela de erros frequentes

Código	Contexto inicial	Primeira investigação
0x800F081F	Source ausente	CBS + fonte
0x800F0906	Conteúdo não obtido	Rede/política/source
0x800F0954	Conteúdo/política gerenciada	GPO/WSUS/source
0x800F0831	Dependência/pacote	CBS
0x80073712	Component Store	DISM + CBS
0x80070070	Espaço	Volumes
0x80072EE2	Timeout	Rede/proxy
0x80240034	Download	Procurar causa anterior

Ferramentas principais

Objetivo	Ferramenta
Ver versão Windows	`winver`
Recursos opcionais	`optionalfeatures`
Consultar NetFx3	`Get-WindowsOptionalFeature`
Gerenciar feature	DISM
Servicing	CBS.log
DISM	DISM.log
Políticas	`gpresult`
Component Store	`DISM /ScanHealth`
Pacotes	`DISM /Get-Packages`

O que não fazer

Não:

instale .NET moderno achando que substituirá .NET Framework;
baixe DLLs individuais;
copie assemblies de outro PC;
apague arquivos do .NET manualmente;
altere WinSxS;
use qualquer ISO como source;
remova WSUS sem entender a política;
apague chaves de política para contornar empresa;
execute DISM sem interpretar o resultado;
desinstale KB apenas porque um aplicativo apresentou erro;
habilite/desabilite NetFx3 repetidamente sem consultar CBS;
use sites de terceiros para baixar “pacotes de reparo” desconhecidos.

Método VMIA para erros .NET no Windows Update

1. Identifique o produto

.NET Framework?

.NET moderno?

2. Identifique a KB

3. Registre código

4. Registre horário

5. Execute winver

6. Determine a fase

Download?

Feature?

Servicing?

7. Consulte CBS.log

8. Consulte DISM.log quando aplicável

9. Verifique políticas em computadores gerenciados

10. Determine se existe problema de source

11. Determine se Component Store está saudável

12. Corrija somente a camada necessária

13. Reinstale/teste

14. Valide no Histórico.

Como descobrir o erro real do Windows Update: WindowsUpdate.log, CBS.log, DISM.log, SetupDiag, SetupAPI e Event Viewer

Um dos maiores erros no diagnóstico do Windows Update é considerar:

o último código exibido

como:

a causa original.

Nem sempre são a mesma coisa.

O Windows Update envolve várias camadas.

Uma camada pode falhar.

A seguinte recebe o resultado.

Outra registra que a operação não terminou.

Por fim, a interface apresenta apenas:

Falha na instalação.

Por isso, precisamos reconstruir a sequência.

Pense em cadeia de erros

Um exemplo conceitual:

rede apresenta timeout

↓

download não termina

↓

Windows Update registra falha de download

↓

interface mostra falha.

Podemos ter:

0x80072EE2

↓

0x80240034

↓

Falha na instalação.

Nesse cenário, tentar reparar Component Store seria começar pela camada errada.

Outro exemplo

Windows Update encontra a KB.

Download funciona.

Pacote chega ao servicing.

CBS precisa de determinado componente.

O componente não está disponível.

CBS registra:

0x800F081F.

A interface pode apresentar apenas uma falha genérica.

Aqui:

a rede não é o principal problema.

Terceiro exemplo

Feature Update começa normalmente.

Download termina.

Instalação avança.

Computador reinicia.

Um driver falha durante FIRST_BOOT.

Setup inicia rollback.

Resultado final:

0xC1900101-0x30018.

Nesse caso, apagar SoftwareDistribution dificilmente atacará a causa.

Precisamos responder cinco perguntas

Para qualquer erro do Windows Update:

1. O que estava sendo instalado?

2. Em qual fase falhou?

3. Em qual horário?

4. Qual componente registrou a primeira falha relevante?

5. Qual log corresponde àquela camada?

Não existe um único log universal

Essa é uma regra importante.

WindowsUpdate.log não substitui:

CBS.log.

CBS.log não substitui:

SetupAPI.dev.log.

SetupDiag não substitui:

DISM.log.

Cada fonte responde perguntas diferentes.

Matriz inicial de logs

Problema	Fonte inicial
Detecção/Windows Update Agent	WindowsUpdate.log
Download/comunicação	WindowsUpdate.log
Servicing	CBS.log
DISM	DISM.log
Upgrade de versão	SetupDiag + Setup logs
Driver/dispositivo	setupapi.dev.log
Certificado/validação	CAPI2/Event Viewer
Serviço não inicia	Service Control Manager
Aplicativo Configurações falha	Event Viewer

WindowsUpdate.log

Comecemos pelo log mais associado ao nome do recurso.

Nas versões modernas do Windows, podemos gerar um arquivo legível usando PowerShell:

Get-WindowsUpdateLog

Salvar em local específico

Por exemplo:

Get-WindowsUpdateLog -LogPath C:\DiagnosticoWU\WindowsUpdate.log

Crie antes:

mkdir C:\DiagnosticoWU

O que procurar?

Não pesquise apenas:

error

Procure também:

código hexadecimal;
KB;
horário;
download;
serviço;
tentativa.

O horário é sua âncora

Imagine que a falha aconteceu às:

14:32:18.

Não comece analisando eventos de três dias atrás.

Procure alguns minutos:

antes

depois

da falha.

Por que antes?

Porque o erro exibido às:

14:32:18

pode ter sido causado por algo registrado às:

14:31:54.

O primeiro erro nem sempre é a causa

Também precisamos tomar cuidado com o extremo oposto.

O primeiro ERROR encontrado no arquivo não é automaticamente a causa.

Pode ser:

evento recuperável;
tentativa anterior;
operação secundária.

Precisamos correlacionar com a atualização e o horário.

Procure a KB

Se sabemos:

KBxxxxxxx

isso ajuda bastante.

Nem sempre a KB aparece exatamente como esperamos

Internamente podem aparecer:

Update IDs;
pacotes;
revisões;
nomes de componentes.

Por isso, código e horário continuam importantes.

WindowsUpdate.log é bom para quê?

Principalmente para entender etapas relacionadas a:

detecção;
avaliação;
download;
agente;
comunicação;
resultado do Windows Update.

Quando abandonar WindowsUpdate.log e abrir CBS.log?

Quando a atualização já chegou à etapa de:

servicing/instalação de componentes.

CBS.log

Caminho:

C:\Windows\Logs\CBS\CBS.log

CBS significa:

Component-Based Servicing.

Quando CBS é fundamental?

Especialmente em:

atualizações cumulativas;
componentes do Windows;
Component Store;
Features on Demand;
.NET Framework integrado;
instalação de pacotes.

Copie o log

Em vez de trabalhar diretamente no arquivo ativo:

copy C:\Windows\Logs\CBS\CBS.log C:\DiagnosticoWU\CBS.txt

O arquivo pode estar em uso

Copiar para uma pasta de diagnóstico facilita:

pesquisa;
preservação;
comparação.

O que procurar no CBS.log?

Procure:

horário;
código;
package;
corruption;
missing;
failed;
HRESULT.

Mas novamente:

não trate qualquer palavra failed como causa.

CBS registra muita coisa

Algumas falhas podem ser:

tentativas;
verificações;
condições esperadas;
erros secundários.

O contexto importa.

Exemplo: 0x800F081F

Se CBS registra:

0x800F081F

no momento da falha e contexto mostra ausência de source, temos uma pista muito mais específica do que:

Windows Update não instalou.

Exemplo: 0x80073712

Se aparece:

0x80073712

e o contexto aponta Component Store, a investigação muda para servicing.

CBS.log e DISM.log são iguais?

Não.

DISM.log

Caminho:

C:\Windows\Logs\DISM\dism.log

Esse log é particularmente relevante quando utilizamos:

DISM.

Exemplo

Você executa:

DISM /Online /Cleanup-Image /RestoreHealth

e recebe:

0x800F081F.

Agora consulte:

DISM.log

e também:

CBS.log.

Por que os dois?

DISM inicia/gerencia a operação.

CBS pode registrar detalhes do servicing subjacente.

Pense em camadas

DISM

↓

servicing

↓

CBS / Component Store.

DISM.log não é só para Windows Update

Ele registra operações relacionadas à ferramenta DISM.

Portanto, use quando realmente existe operação DISM relevante.

SetupDiag

Para upgrades de versão, a estratégia muda.

Exemplo:

Windows 11 24H2

↓

tentativa de upgrade

↓

reinicialização

↓

rollback.

Nesse caso, não dependa apenas de WindowsUpdate.log.

SetupDiag

SetupDiag analisa informações produzidas pelo Windows Setup para tentar identificar padrões de falha.

É particularmente útil quando o upgrade:

começa;
avança;
reinicia;
volta à versão anterior.

SetupDiag não repara o computador

Ele é uma ferramenta de diagnóstico.

Seu objetivo é ajudar a responder:

por que o Setup falhou?

Setup logs

Um caminho importante durante upgrade é:

C:\$WINDOWS.~BT\Sources\Panther

Arquivos importantes

Entre eles:

setupact.log

setuperr.log

setupact.log

Pode registrar uma quantidade grande de atividades executadas pelo Setup.

setuperr.log

Concentra erros encontrados pelo Setup.

Mas atenção:

o último erro do setuperr.log não é automaticamente a causa raiz.

Por quê?

Rollback pode gerar novos erros enquanto desfaz operações.

Precisamos descobrir o que iniciou a falha.

Código + fase + operação

Em upgrades, uma combinação pode ser muito mais útil do que um código isolado.

Por exemplo:

0xC1900101-0x30018

pode apontar para um rollback em contexto de FIRST_BOOT, frequentemente direcionando a investigação para drivers/dispositivos.

Não pesquise somente 0xC1900101

Procure a combinação completa.

SetupAPI.dev.log

Para drivers e dispositivos:

C:\Windows\INF\setupapi.dev.log

é extremamente importante.

Quando consultar?

Quando:

driver falha;
dispositivo não instala;
upgrade aponta para driver;
INF não é aplicado;
dispositivo muda após Windows Update.

Procure Hardware ID

Exemplo conceitual:

PCI\VEN_xxxx&DEV_xxxx

Isso pode ajudar a localizar o dispositivo dentro do log.

Procure INF

Se sabemos:

oem42.inf

procure esse nome.

Procure horário

Novamente:

tempo é uma das melhores ferramentas de correlação.

setupapi.dev.log pode revelar seleção do driver

Ele pode ajudar a entender:

pacote considerado;
instalação;
ranking;
erro;
dispositivo.

CAPI2

Quando o problema envolve:

certificado;
cadeia;
assinatura;
validação criptográfica;

o log operacional do CAPI2 pode ser muito útil.

Event Viewer

Abra:

eventvwr.msc

Navegue pelos logs de aplicativos e serviços conforme o componente investigado.

CAPI2 não é para qualquer erro

Use quando existe evidência de:

trust;
certificate;
signature;
chain.

Exemplo

Erro:

0x800B0109

Agora CAPI2 pode ser muito mais relevante do que:

DISM.log.

Service Control Manager

Se um serviço não inicia:

net start bits

e retorna erro,

não comece imediatamente reconstruindo SoftwareDistribution.

Event Viewer → System

Procure eventos do:

Service Control Manager

no horário da tentativa.

Isso pode revelar

timeout;
dependência;
falha de logon;
serviço encerrado;
erro de inicialização.

WindowsUpdateClient

O Event Viewer também possui registros relacionados ao Windows Update Client.

Eles podem fornecer outra visão sobre:

instalação;
sucesso;
falha.

Event Viewer não substitui logs textuais

Ele complementa.

PowerShell e Get-WinEvent

Para análises mais avançadas:

Get-WinEvent

permite consultar logs diretamente.

Não exporte milhões de eventos sem filtro

Use:

horário;
provider;
log;
ID.

Criando uma linha do tempo

Essa é uma técnica extremamente eficiente.

Imagine:

14:30:00 — usuário clica em instalar.

14:30:12 — download começa.

14:31:40 — download termina.

14:31:58 — servicing começa.

14:32:14 — CBS registra erro.

14:32:16 — Windows Update registra falha.

14:32:18 — interface mostra “Falha na instalação”.

Agora sabemos:

14:32:14

é provavelmente mais interessante que:

14:32:18.

Essa é a diferença entre sintoma e causa

Interface:

Falha na instalação

é o sintoma.

CBS:

componente ausente

pode ser a causa técnica.

Erro primário e erro secundário

Podemos pensar em:

erro primário

= evento que iniciou a falha.

erro secundário

= consequência.

Exemplo de rede

0x80072EE2

↓

transferência não termina

↓

0x80240034.

O segundo pode apenas dizer:

download failed.

O primeiro explica:

timeout.

Exemplo de servicing

componente ausente

↓

CBS retorna:

0x800F081F

↓

Windows Update registra falha genérica.

Exemplo de upgrade

driver falha

↓

Setup não conclui FIRST_BOOT

↓

rollback

↓

0xC1900101-0x30018.

Exemplo de espaço

volume necessário sem espaço

↓

operação falha

↓

0x80070070.

Nesse caso, o código já pode ser bastante direto.

Nem sempre existe um código “mais profundo”

Às vezes o código principal já descreve adequadamente a causa.

Não procure complexidade quando não existe.

Como procurar hexadecimal em logs

Códigos normalmente aparecem como:

0x800F081F

Podemos pesquisar diretamente.

PowerShell Select-String

Exemplo:

Select-String -Path C:\DiagnosticoWU\CBS.txt -Pattern "0x800F081F"

Pesquisar várias palavras

Podemos utilizar:

Select-String -Path C:\DiagnosticoWU\CBS.txt -Pattern "error","failed","corrupt"

Mas isso pode gerar muitos resultados.

Melhor ainda: procure o código conhecido

Se a interface mostrou:

0x800F081F

comece por ele.

Pesquisar KB

Select-String -Path C:\DiagnosticoWU\WindowsUpdate.log -Pattern "KBxxxxxxx"

Logs muito grandes

Não abra necessariamente tudo no Bloco de Notas.

Ferramentas capazes de pesquisar arquivos grandes podem facilitar.

Não altere os logs

Trabalhe em cópias.

Preservando evidências

Crie:

C:\DiagnosticoWU

Depois:

Get-WindowsUpdateLog -LogPath C:\DiagnosticoWU\WindowsUpdate.log

copy C:\Windows\Logs\CBS\CBS.log C:\DiagnosticoWU\CBS.txt

copy C:\Windows\Logs\DISM\dism.log C:\DiagnosticoWU\DISM.txt

Informações do sistema

Adicione:

systeminfo > C:\DiagnosticoWU\systeminfo.txt

Build

PowerShell:

Get-ComputerInfo | Select-Object WindowsProductName,WindowsVersion,OsBuildNumber,OsArchitecture | Out-File C:\DiagnosticoWU\windows.txt

Drivers

pnputil /enum-drivers > C:\DiagnosticoWU\drivers.txt

Partições

PowerShell:

Get-Disk | Format-Table -AutoSize | Out-File C:\DiagnosticoWU\discos.txt

Get-Partition | Format-Table -AutoSize | Out-File C:\DiagnosticoWU\particoes.txt

Get-Volume | Format-Table -AutoSize | Out-File C:\DiagnosticoWU\volumes.txt

WinRE

reagentc /info > C:\DiagnosticoWU\winre.txt

BitLocker

manage-bde -status > C:\DiagnosticoWU\bitlocker.txt

Políticas

gpresult /h C:\DiagnosticoWU\gpresult.html

Em máquina gerenciada, isso pode ser extremamente útil.

Agora temos um pacote de diagnóstico

Em vez de dizer:

“Windows Update não funciona”

temos:

versão do Windows;
build;
drivers;
partições;
políticas;
WindowsUpdate.log;
CBS.log;
DISM.log;
WinRE;
BitLocker.

Não precisamos coletar tudo em todos os casos

Isso é importante.

Se o problema é claramente:

0x80072EE2

não precisamos imediatamente investigar partições.

Colete informações de acordo com o caso.

Princípio da menor investigação necessária

Comece pela camada mais provável.

Aprofunde conforme a evidência.

Matriz: sintoma → log

Sintoma	Log/fonte principal
Não encontra atualizações	WindowsUpdate.log
Download falha	WindowsUpdate.log
0x80072xxx	WindowsUpdate.log + rede
BITS falha	BITS/Event Viewer
Instalação cumulativa falha	CBS.log
0x800Fxxxx	CBS.log
0x800737xx	CBS.log
DISM falha	DISM.log + CBS.log
Upgrade faz rollback	SetupDiag + Setup logs
0xC1900101	SetupDiag + SetupAPI
Driver falha	setupapi.dev.log
Certificado falha	CAPI2
Serviço não inicia	Service Control Manager
.NET Feature falha	CBS.log + DISM.log
Reinicialização pendente	CBS + Histórico
Interface Configurações falha	Event Viewer

Matriz: código → camada

Família	Camada inicial
0x800700xx	Win32/sistema
0x80072xxx	Comunicação
0x802000xx	BITS/transferência
0x8024xxxx	Windows Update Agent
0x800Fxxxx	Servicing/CBS
0x800737xx	Side-by-Side/Component Store
0x800960xx	Trust/assinatura
0x800Bxxxx	Certificados/trust
0xC19001xx	Setup/upgrade
0xC1900101	Frequentemente driver/rollback

Código não substitui contexto

0x80070005

significa acesso negado em muitos contextos.

Mas:

acesso negado a quê?

Isso só aparece no contexto.

Não aplique solução pelo Google sem contexto

Pesquisar:

0x80070005 Windows Update fix

pode trazer dezenas de procedimentos.

O correto é:

0x80070005 em qual componente?

Mesma coisa com 0x80070057

Parâmetro inválido.

Mas:

qual parâmetro?

qual operação?

O log pode responder.

HRESULT e Win32

Muitos códigos seguem estruturas que ajudam a identificar sua origem.

Mas não é necessário decorar toda a estrutura hexadecimal para diagnosticar corretamente.

Use ferramentas de tradução com cuidado

Ferramentas podem traduzir códigos para nomes simbólicos.

Isso ajuda.

Mas:

nome simbólico ≠ causa raiz.

ERROR_ACCESS_DENIED

Se traduzimos um código para:

Access denied

a próxima pergunta é:

qual objeto negou acesso?

ERROR_FILE_NOT_FOUND

Se temos:

File not found

a próxima pergunta é:

qual arquivo?

ERROR_PATH_NOT_FOUND

Pergunte:

qual caminho?

TRUST_E_BAD_DIGEST

Pergunte:

qual arquivo/pacote falhou na validação?

CBS_E_SOURCE_MISSING

Pergunte:

qual componente/source está ausente?

Isso é diagnóstico de verdade

Traduzir o código é:

passo 1.

Encontrar o objeto/operação que gerou o código é:

passo 2.

Logs correlacionados

Às vezes precisamos usar dois ou três logs.

Exemplo:

WindowsUpdate.log:

instalação falhou

CBS.log:

pacote X falhou

DISM.log:

source não disponível.

Agora temos uma história completa.

Não misture horários de tentativas diferentes

Se você tentou instalar a KB:

10 vezes,

o log terá várias sequências.

Escolha uma tentativa específica.

Melhor prática

Faça:

reinicie quando apropriado;
anote horário;
execute uma única tentativa;
aguarde o resultado;
anote novo horário;
colete logs.

Agora temos uma janela limpa.

Não reinicie antes de preservar logs quando o caso exigir análise imediata

Alguns logs persistem, outros estados podem mudar.

Se o problema é complexo:

preserve primeiro.

Exportando Event Viewer

Para casos avançados, eventos relevantes podem ser exportados.

Isso permite analisar posteriormente sem depender do computador estar no mesmo estado.

Logs também podem rotacionar

Arquivos possuem limites.

Em sistemas muito ativos, eventos antigos podem ser substituídos.

Por isso, problemas intermitentes merecem coleta próxima da ocorrência.

“Aconteceu há três meses”

Pode ser difícil reconstruir tecnicamente se:

logs rotacionaram;
Windows foi atualizado;
drivers mudaram;
cache foi limpo.

Quanto mais próximo da falha, melhor.

Não limpe Event Viewer antes de diagnosticar

Alguns “otimizadores” fazem isso.

Você perde histórico valioso.

Não use limpadores de log como manutenção

Logs ocupam espaço controlado e possuem finalidade de diagnóstico.

Reliability Monitor

Outra ferramenta útil é:

perfmon /rel

O Monitor de Confiabilidade oferece uma linha do tempo visual de:

falhas;
instalações;
eventos.

Ele pode ajudar a localizar a data

Por exemplo:

Windows Update começou a falhar na terça-feira.

Monitor de Confiabilidade pode ajudar a correlacionar:

atualização;
driver;
aplicativo;
falha.

Reliability Monitor não substitui CBS

Ele ajuda a encontrar:

quando.

CBS ajuda a descobrir:

o que aconteceu no servicing.

Event Viewer + Reliability Monitor + logs

Juntos, eles oferecem:

linha do tempo

evento

detalhe técnico.

Exemplo completo de diagnóstico

Sintoma:

Atualização cumulativa falha.

Interface:

0x800F081F.

Passo 1:

anotar KB e horário.

Passo 2:

WindowsUpdate.log confirma que download terminou.

Passo 3:

CBS.log registra:

CBS_E_SOURCE_MISSING.

Passo 4:

DISM ScanHealth identifica problema de reparabilidade.

Passo 5:

RestoreHealth também não encontra source.

Conclusão técnica:

o foco deve estar no:

servicing/source, não na rede.

Outro exemplo

Sintoma:

Windows Update fica em:

Baixando 0%.

WindowsUpdate.log mostra:

0x80072EE2.

BITS não apresenta corrupção.

Teste em outra rede funciona.

Conclusão:

a investigação deve priorizar:

caminho de rede da conexão original.

Outro exemplo

Sintoma:

upgrade chega a determinado percentual e volta.

Código:

0xC1900101-0x30018.

SetupDiag aponta contexto de driver.

setupapi.dev.log mostra falha relacionada a determinado dispositivo.

Agora temos um alvo.

Não precisamos:

apagar SoftwareDistribution;
resetar catroot2;
executar SFC dez vezes.

Outro exemplo

Sintoma:

driver pelo Windows Update falha.

WindowsUpdate.log apresenta falha genérica.

setupapi.dev.log mostra que o pacote não foi aplicado ao dispositivo.

Agora a investigação é:

driver/PnP, não Component Store.

Outro exemplo

Sintoma:

pacote baixado é rejeitado.

Erro:

0x800B0109.

CAPI2 mostra problema na cadeia de confiança.

Agora investigamos:

certificados/trust.

Não DNS.

Árvore universal de logs

Windows Update falhou

↓

Falhou antes do download?

→ WindowsUpdate.log.

Durante download?

→ WindowsUpdate.log + BITS/DO + rede.

Depois do download, durante instalação?

→ CBS.log.

DISM também falha?

→ DISM.log + CBS.log.

Feature Update fez rollback?

→ SetupDiag + Panther.

Driver?

→ setupapi.dev.log.

Certificado?

→ CAPI2.

Serviço?

→ Service Control Manager.

Interface?

→ Event Viewer.

O que não fazer antes de coletar evidências

Evite:

apagar SoftwareDistribution;
apagar catroot2;
limpar Event Viewer;
apagar $WINDOWS.~BT;
remover drivers;
limpar Driver Store;
apagar Windows.old;
executar dezenas de resets;
usar “repair scripts” desconhecidos.

Cada uma dessas ações pode destruir pistas.

Preserve antes de reparar

Essa regra resume esta parte.

Primeiro evidência.

Depois correção.

Diagnóstico não precisa ser complicado

Mesmo um usuário doméstico pode seguir quatro passos:

anotar KB;
anotar código;
anotar horário;
identificar a fase.

Só isso já melhora enormemente a investigação.

Para técnicos

Adicione:

WindowsUpdate.log;
CBS.log;
DISM.log;
SetupDiag;
SetupAPI;
Event Viewer;
políticas;
inventário.

Agora o diagnóstico deixa de ser tentativa e erro.

Tabela Mestre de Erros do Windows Update: código, significado, camada, log e diagnóstico

Depois de analisar separadamente rede, BITS, Windows Update Agent, servicing, Component Store, certificados, drivers, armazenamento, .NET Framework e Windows Setup, podemos reunir os principais códigos em uma referência única.

Mas esta tabela precisa ser utilizada corretamente.

Ela não significa:

“código X = execute comando Y”.

O método correto continua sendo:

código

↓

família

↓

fase

↓

componente

↓

log

↓

causa

↓

correção

↓

validação.

Antes de usar a tabela

Sempre registre pelo menos:

código completo;
KB;
horário;
versão do Windows;
fase em que falhou.

Execute:

winver

E consulte:

Configurações → Windows Update → Histórico de atualizações

Família 0x800700xx — erros Win32 e do sistema

Essa família é muito ampla.

Um código 0x800700xx pode aparecer em:

Windows Update;
DISM;
Setup;
drivers;
arquivos;
permissões;
armazenamento.

Portanto, o contexto é indispensável.

Tabela 0x800700xx

Código	Significado/contexto inicial	Investigue primeiro
`0x80070002`	Arquivo não encontrado	Qual arquivo/pacote está ausente
`0x80070003`	Caminho não encontrado	Caminho/recurso utilizado
`0x80070005`	Acesso negado	Objeto/permissão/contexto
`0x8007000D`	Dados inválidos	Pacote/metadata/manifesto
`0x80070020`	Arquivo/recurso em uso	Processo/filtro/software
`0x80070057`	Parâmetro inválido	Operação e parâmetro
`0x80070070`	Espaço insuficiente	Volume/partição
`0x80070490`	Item não encontrado	Componente/pacote
`0x80070570`	Arquivo/diretório corrompido ou ilegível	Arquivo, filesystem, storage
`0x80071A91`	Mecanismo transacional relacionado ao filesystem	Estado transacional/filesystem

0x80070002

Tradução prática:

algo necessário não foi encontrado.

Não significa automaticamente:

SoftwareDistribution corrompida.

Procure:

arquivo;
pacote;
caminho;
etapa.

Logs possíveis:

WindowsUpdate.log;
CBS.log;
Setup logs.

0x80070003

Relacionado a:

caminho não encontrado.

Pergunte:

qual caminho?

O erro sozinho não responde.

0x80070005

Acesso negado.

Uma das mensagens mais perigosas para troubleshooting genérico.

Não resolva concedendo:

Everyone — Full Control

em pastas do sistema.

Descubra:

qual objeto;
qual conta;
qual serviço;
qual operação.

0x8007000D

Dados inválidos.

Pode aparecer em diferentes contextos.

Investigue:

pacote;
metadados;
manifesto;
conteúdo baixado;
servicing.

0x80070020

Pode estar associado a compartilhamento/recurso em uso.

Investigue:

processo;
antivírus;
backup;
filtro;
arquivo aberto.

Ferramentas avançadas como Process Monitor podem ajudar quando existe evidência.

0x80070057

Parâmetro inválido.

Extremamente genérico.

Não existe uma correção universal para:

0x80070057.

0x80070070

Espaço insuficiente.

Verifique:

Get-Volume

Mas lembre-se:

o volume problemático pode não ser apenas:

C:.

Em upgrades e determinados updates, outras partições podem participar.

0x80070570

Pode apontar para arquivo ou diretório corrompido/ilegível.

Isso não significa automaticamente:

SSD morrendo.

Investigue:

arquivo;
origem;
filesystem;
armazenamento;
pacote.

Família 0x80072xxx — comunicação

Quando aparece:

0x80072xxx

a investigação frequentemente muda para:

rede;
proxy;
HTTPS;
TLS;
conexão;
timeout.

Tabela 0x80072xxx

Código	Contexto	Primeira investigação
`0x80072EE2`	Timeout	Rede/proxy/caminho
`0x80072EFE`	Conexão abortada	Rede/filtros/proxy
`0x80072EFD`	Não conseguiu estabelecer conexão	Rede/proxy/firewall
`0x80072F8F`	Comunicação segura	Hora/TLS/certificados

0x80072EE2

Pense:

timeout.

Não pense imediatamente:

DNS.

DNS é apenas uma das possibilidades.

Verifique:

netsh winhttp show proxy

ipconfig /all

0x80072EFE

Conexão foi interrompida/abortada.

Investigue:

estabilidade;
proxy;
VPN;
filtros;
segurança.

0x80072EFD

A conexão necessária não pôde ser estabelecida.

Compare:

outra rede;
outros computadores;
VPN;
proxy.

0x80072F8F

Pode apontar para problemas de comunicação segura.

Verifique:

Get-Date

w32tm /query /status

Além de:

TLS;
certificados;
inspeção HTTPS.

Família 0x802000xx — BITS

Quando encontramos:

0x802000xx

BITS merece atenção.

Tabela BITS

Código	Contexto inicial	Investigue
`0x80200010`	BITS não encontra conectividade adequada	Rede/interface
`0x80200011`	Protocolo/contexto de transferência	Job/origem
`0x80200013`	Transferência/ranges	Servidor/intermediários
`0x8020001B`	Proxy/credenciais	Proxy/autenticação
`0x80200049`	Estado do job	Job BITS

Comandos

Get-Service bits

Get-BitsTransfer

Quando apropriado:

Get-BitsTransfer -AllUsers

Não remova todos os jobs

Primeiro descubra qual trabalho está falhando.

Família 0x8024xxxx — Windows Update Agent

Essa é uma das famílias mais diretamente relacionadas ao Windows Update.

Mas até dentro dela existem muitos contextos diferentes.

Tabela 0x8024xxxx — Parte 1

Código	Nome/contexto	Primeira investigação
`0x8024000B`	Operação cancelada	Quem/o que cancelou
`0x8024000C`	Nenhuma operação necessária	Estado/aplicabilidade
`0x8024000D`	Dados XML ausentes	Metadata
`0x8024000E`	XML inválido	Metadata
`0x8024000F`	Ciclo detectado	Relação entre updates
`0x80240010`	Relação excessivamente profunda	Metadata/relações
`0x80240012`	Valor de Registro inválido	Contexto/configuração
`0x80240013`	Item duplicado	Metadata/estado
`0x80240016`	Instalação não permitida naquele estado	Outra operação/estado
`0x80240017`	Atualização não aplicável	Build/edição/arquitetura

0x80240017

Esse merece destaque.

Not applicable não significa necessariamente:

Windows Update quebrado.

A atualização pode não ser destinada ao computador.

Verifique:

winver

Get-ComputerInfo | Select-Object WindowsProductName,WindowsVersion,OsBuildNumber,OsArchitecture

Tabela 0x8024xxxx — Parte 2

Código	Contexto	Primeira investigação
`0x80240018`	Contexto/token de usuário	Contexto da operação
`0x8024001A`	Política não definida	GPO/configuração
`0x8024001D`	Atualização inválida	Metadata/pacote
`0x8024001E`	Serviço/operação interrompida	Serviços/log
`0x8024001F`	Sem conexão	Rede
`0x80240020`	Usuário interativo necessário	Contexto
`0x80240021`	Timeout	Operação/serviço
`0x80240022`	Todas as atualizações falharam	Procurar erros anteriores
`0x80240023`	EULA recusada	Licença/contexto
`0x80240024`	Nenhuma atualização	Detecção/aplicabilidade
`0x80240025`	Acesso do usuário desabilitado	Política

0x80240022

Esse é um excelente exemplo de:

erro final que pode não ser a causa.

Ele informa que o conjunto falhou.

Pergunte:

qual atualização falhou primeiro e com qual código?

Tabela 0x8024xxxx — Parte 3

Código	Contexto	Primeira investigação
`0x8024002B`	Servidor legado/incompatível	Infraestrutura
`0x8024002C`	Origem binária ausente	Source
`0x8024002D`	Source ausente	Origem/conteúdo
`0x80240032`	Critério inválido	Consulta/metadata
`0x80240033`	EULA indisponível	Metadata
`0x80240034`	Download falhou	Procurar erro anterior
`0x80240035`	Update não processado	Estado/agente
`0x80240036`	Operação inválida	Contexto
`0x80240037`	Operação/update não suportado	Plataforma
`0x80240040`	Contexto específico de suporte da plataforma	Edição/plataforma
`0x80240041`	Sysprep em andamento	Estado do sistema
`0x80240042`	Serviço desconhecido	Configuração/agente
`0x80240044`	Acesso por máquina negado	Permissão/política

0x80240034

Download failed.

Não pare aí.

Procure antes dele:

0x80072EE2

0x80072EFE

ou outro código mais específico.

Família 0x800Fxxxx — servicing

Essa família merece muita atenção quando:

download terminou, mas instalação falha.

Tabela 0x800Fxxxx

Código	Contexto	Log principal
`0x800F081F`	Source ausente	CBS.log
`0x800F0831`	Dependência/pacote ausente	CBS.log
`0x800F0900`	Problema de processamento/XML no servicing	CBS.log
`0x800F0906`	Conteúdo necessário não obtido	CBS/DISM
`0x800F0922`	Falha de servicing que exige contexto	CBS.log
`0x800F0954`	Obtenção de conteúdo/política em cenários gerenciados	CBS + GPO
`0x800F0988`	Processamento de componentes/pacotes	CBS.log

0x800F081F

Um dos códigos mais importantes deste guia.

Pense:

source necessário não encontrado.

Não:

formate o Windows.

0x800F0831

Pode envolver dependência de servicing/pacote.

CBS.log é essencial.

0x800F0900

Investigue o processamento realizado pelo servicing e o contexto registrado no CBS.

0x800F0906

O Windows não conseguiu obter conteúdo necessário.

Agora podem entrar:

source;
rede;
política.

0x800F0922

Esse código é frequentemente reduzido na internet a:

“partição EFI cheia”.

Isso é perigoso.

O código pode aparecer em diferentes contextos de servicing.

Use:

CBS.log.

Somente investigue EFI/partições quando houver evidência.

0x800F0954

Especialmente interessante em:

Features on Demand;
.NET Framework 3.5;
ambientes gerenciados.

Investigue:

política;
WSUS;
origem.

0x800F0988

Não aplique uma solução universal.

Consulte:

CBS.log

e identifique o componente/pacote.

Família 0x800737xx — Side-by-Side e Component Store

Esses códigos frequentemente apontam para servicing/componentes.

Tabela 0x800737xx

Código	Contexto inicial	Primeira investigação
`0x80073701`	Assembly/componente ausente	CBS + DISM
`0x8007370A`	Side-by-Side	CBS
`0x8007370B`	Side-by-Side	CBS
`0x8007370D`	Side-by-Side	CBS
`0x80073712`	Component Store corrompido	DISM + CBS
`0x8007371B`	Side-by-Side	CBS
`0x8007371C`	Side-by-Side	CBS

0x80073712

Esse é um código forte para investigar:

Component Store.

Execute inicialmente:

DISM /Online /Cleanup-Image /CheckHealth

Depois:

DISM /Online /Cleanup-Image /ScanHealth

Se reparável

Quando apropriado:

DISM /Online /Cleanup-Image /RestoreHealth

Não delete WinSxS

Nunca tente corrigir Component Store apagando manualmente:

C:\Windows\WinSxS

Família 0x800960xx — assinatura e confiança

Quando aparecem códigos dessa família, investigue:

assinatura;
digest;
certificado;
catálogo.

Tabela 0x800960xx

Código	Contexto	Investigue
`0x80096002`	Certificado do signatário	Assinatura/certificado
`0x80096003`	Counter-signer	Assinatura
`0x80096004`	Assinatura do certificado	Certificado
`0x80096005`	Timestamp	Assinatura/hora
`0x80096010`	Digest/assinatura não confere	Integridade/assinatura

0x80096010

Pergunte:

qual arquivo/pacote falhou na verificação?

Pode existir:

conteúdo corrompido;
problema de validação;
interferência.

Família 0x800Bxxxx — certificados

Tabela

Código	Contexto	Investigue
`0x800B0100`	Assinatura ausente	Pacote/assinatura
`0x800B0101`	Período de validade	Hora/certificado
`0x800B0109`	Raiz não confiável	Cadeia de certificados
`0x800B010A`	Construção da cadeia	Certificados

Ferramenta importante

Event Viewer:

CAPI2 Operational

quando o contexto é validação criptográfica.

Não instale certificados aleatórios

Se aparece:

0x800B0109

não baixe um certificado de qualquer fórum para:

“resolver”.

Descubra qual cadeia falhou.

Família 0xC190xxxx — Windows Setup

Agora saímos das atualizações cumulativas e entramos principalmente em:

upgrades de versão.

Tabela 0xC190xxxx

Código	Contexto inicial	Ferramenta
`0xC1900101`	Rollback frequentemente associado a driver	SetupDiag
`0xC1900200`	Requisitos/compatibilidade	Setup
`0xC1900208`	Incompatibilidade detectada	Compatibilidade
`0xC1900209`	Ação necessária por compatibilidade	Setup
`0xC1900210`	Contexto de compatibilidade sem bloqueio identificado	Setup

0xC1900101

Não pare no código principal.

Procure a combinação completa.

Exemplos:

0xC1900101-0x20017

0xC1900101-0x30018

0xC1900101-0x40017

A segunda parte ajuda a localizar a fase/operação do rollback.

Logs

Consulte:

C:\$WINDOWS.~BT\Sources\Panther

especialmente:

setupact.log

setuperr.log

e utilize SetupDiag quando apropriado.

Drivers

Também consulte:

C:\Windows\INF\setupapi.dev.log

quando houver evidência relacionada a dispositivos.

Família de espaço e armazenamento

Não existe apenas um código para armazenamento.

Mas alguns merecem atenção especial.

Tabela

Código	Possibilidade	Ferramenta
`0x80070070`	Espaço insuficiente	Get-Volume
`0x80070570`	Arquivo/diretório ilegível/corrompido	Logs + filesystem/storage
`0x800F0922`	Pode exigir investigação de servicing/partições conforme contexto	CBS + partições

Comandos

Get-Disk

Get-Partition

Get-Volume

reagentc /info

Não redimensione partições por código isolado

Especialmente:

0x800F0922.

Primeiro procure evidência.

Erros do .NET Framework

Muitos não são exclusivos do .NET.

Eles pertencem ao servicing.

Tabela

Código	Cenário comum
`0x800F081F`	Source ausente
`0x800F0906`	Conteúdo não obtido
`0x800F0954`	Política/source em ambiente gerenciado
`0x80073712`	Component Store
`0x800F0831`	Dependência de servicing

Erros de drivers

Novamente, alguns códigos pertencem a outras camadas.

Tabela

Sintoma/código	Ferramenta
Driver falha no Update	setupapi.dev.log
Dispositivo Code 10	Device Manager + SetupAPI
Code 28	Driver ausente
Code 43	Driver/firmware/hardware
`0xC1900101`	SetupDiag + drivers
Driver reaparece	PnPUtil + Histórico

Tabela mestre resumida

Agora podemos criar uma consulta rápida por família.

Prefixo	Pense primeiro em
`0x800700xx`	Win32/sistema
`0x80072xxx`	Comunicação
`0x802000xx`	BITS
`0x8024xxxx`	Windows Update Agent
`0x800Fxxxx`	Servicing
`0x800737xx`	Component Store/Side-by-Side
`0x800960xx`	Assinatura/trust
`0x800Bxxxx`	Certificados
`0xC190xxxx`	Windows Setup/upgrade

Mas existem exceções

Prefixos ajudam a orientar.

Eles não substituem:

mensagem;
nome simbólico;
log;
contexto.

Código que muda depois de uma correção

Isso é muito interessante.

Imagine:

primeira tentativa:

0x80072EE2

Você corrige o problema de comunicação.

Segunda tentativa:

download funciona.

Agora aparece:

0x800F081F.

Isso não significa necessariamente que a primeira correção falhou.

Pode significar:

o processo avançou para uma etapa posterior.

Antes

Rede impedia download.

Depois

Download funciona.

Agora servicing encontrou outro problema.

Mudança de código pode representar progresso

Esse é um conceito importante em troubleshooting.

Não tente fazer o sistema voltar ao código anterior.

Investigue o novo estágio.

Erro genérico versus erro específico

Se temos:

0x80240022

e antes dele:

0x800F081F

o segundo pode ser muito mais útil.

Outro exemplo

0x80240034

e antes:

0x80072EE2.

Priorize o timeout.

Outro exemplo

Interface:

Falha na instalação

CBS:

0x80073712.

Priorize Component Store.

Hierarquia prática

Em muitos casos:

mensagem visual

↓

resultado do Windows Update Agent

↓

erro da camada

↓

causa específica no log.

Nosso objetivo é descer nessa cadeia.

Como usar esta tabela corretamente

Passo 1

Copie o código completo.

Passo 2

Identifique a família.

Passo 3

Determine a fase:

detectar;
baixar;
validar;
instalar;
reiniciar;
upgrade.

Passo 4

Escolha o log.

Passo 5

Procure o horário.

Passo 6

Encontre o erro anterior mais específico.

Passo 7

Crie uma hipótese.

Passo 8

Teste uma mudança.

Passo 9

Execute Windows Update novamente.

Passo 10

Valide.

Não faça cinco reparos simultaneamente

Imagine executar de uma vez:

DISM

SFC

reset de BITS

reset de SoftwareDistribution

reset de catroot2

DNS flush

Winsock reset.

Se funcionar:

qual deles resolveu?

Você não sabe.

Se piorar:

qual deles causou?

Também não sabe.

Troubleshooting controlado

Faça:

uma hipótese

↓

um teste

↓

um resultado.

Quando resetar Windows Update?

Reset pode ser apropriado quando existe evidência de:

estado local inconsistente;
cache problemático;
metadados locais quebrados.

Mas não é solução para:

driver incompatível;
EFI sem espaço;
source ausente;
certificado raiz;
hardware;
atualização não aplicável.

Quando DISM faz sentido?

Quando existe evidência de problema em:

servicing;
Component Store;
componentes.

Quando DISM não é prioridade?

Exemplo:

0x80072EE2.

Nesse caso, comece por:

comunicação.

Quando SFC faz sentido?

Quando existe suspeita/evidência relacionada a arquivos protegidos do Windows.

Não use SFC como teste de internet.

Quando CHKDSK faz sentido?

Quando existe evidência de problema no:

filesystem;
armazenamento.

Não execute reparos pesados no disco apenas porque Windows Update falhou.

Quando PnPUtil faz sentido?

Quando existe:

driver;
dispositivo;
rollback 0xC1900101.

Quando CAPI2 faz sentido?

Quando existe:

assinatura;
certificado;
trust.

Quando SetupDiag faz sentido?

Quando existe:

Windows Setup/upgrade/rollback.

Quando CBS.log faz sentido?

Quando existe:

servicing.

Quando WindowsUpdate.log faz sentido?

Quando queremos entender:

detecção;
agente;
download;
resultado.

Mapa mental final

Qual é o erro?

↓

0x80072…

Rede

0x802000…

BITS

0x8024…

Windows Update Agent

0x800F…

Servicing

0x800737…

Component Store

0x800960 / 0x800B…

Assinatura/certificados

0xC190…

Upgrade

↓

confirmar com logs

↓

não reparar apenas pelo prefixo.

Tabela “não faça isso”

Erro	Evite assumir
`0x80070002`	“SoftwareDistribution”
`0x80070005`	“preciso liberar Everything/Everyone”
`0x80070070`	“só C: está cheio”
`0x80072EE2`	“troque DNS”
`0x80240034`	“BITS está corrompido”
`0x800F081F`	“Windows precisa ser formatado”
`0x800F0922`	“EFI está cheia”
`0x80073712`	“apague WinSxS”
`0x800B0109`	“instale qualquer certificado”
`0xC1900101`	“é o driver de vídeo”

O código é uma pista, não uma sentença

Essa talvez seja a principal conclusão da tabela.

O mesmo código pode aparecer em ambientes diferentes.

A solução correta depende de:

componente;
operação;
objeto;
momento.

Fluxograma Universal de Diagnóstico do Windows Update: do primeiro erro ao reparo avançado

Chegamos ao ponto em que podemos transformar todo este guia em um método prático.

O usuário não precisa começar sabendo:

o significado do código;
qual serviço falhou;
qual log abrir;
se o problema está no BITS;
se existe corrupção no Component Store.

Podemos começar simplesmente com:

“Windows Update não funciona.”

A partir daí, seguimos uma sequência.

O objetivo é evitar o método:

erro

↓

pesquisa na internet

↓

dez comandos copiados

↓

vários componentes resetados

↓

ninguém sabe o que resolveu.

O método correto é:

sintoma

↓

fase

↓

código

↓

camada

↓

evidência

↓

hipótese

↓

teste

↓

correção

↓

validação.

Regra zero — não comece reparando

Antes de executar qualquer comando de reparo, registre o estado atual.

Anote:

mensagem exibida;
código;
KB;
horário;
percentual;
comportamento após reinicialização.

Faça uma captura de tela

Se existe código na interface, registre-o.

Não dependa da memória.

Existe uma enorme diferença entre:

0x80070002

0x80070020.

Consulte o Histórico

Abra:

Configurações → Windows Update → Histórico de atualizações

Procure a tentativa.

Anote:

nome;
KB;
resultado;
data.

Descubra a versão do Windows

Execute:

winver

Agora começa o fluxograma

ETAPA 1 — Existe um código?

Sim

Copie o código completo.

Depois identifique a família.

`0x80072...`

Prioridade:

comunicação.

`0x802000...`

Prioridade:

BITS/transferência.

`0x8024...`

Prioridade:

Windows Update Agent.

`0x800F...`

Prioridade:

servicing/CBS.

`0x800737...`

Prioridade:

Component Store/Side-by-Side.

`0x800960...` ou `0x800B...`

Prioridade:

assinatura/certificados.

`0xC190...`

Prioridade:

Windows Setup/upgrade.

Mas lembre-se:

família é ponto de partida, não diagnóstico final.

Não existe código?

Então a próxima pergunta é:

em qual fase está parado?

ETAPA 2 — Qual é a fase?

A — Procurando atualizações

Se permanece indefinidamente em:

Procurando atualizações

investigue:

agente;
serviço;
comunicação;
política;
fonte de atualização.

B — Baixando

Se está:

Baixando — 0%

ou outro percentual:

investigue:

rede;
BITS;
Delivery Optimization;
proxy;
VPN;
conexão limitada.

C — Instalando

Se o download terminou e aparece:

Instalando

a prioridade muda para:

servicing;
CBS;
Component Store;
espaço.

D — Aguardando reinicialização

Se aparece:

Reinicialização necessária

faça uma reinicialização normal quando apropriado.

Se o aviso permanece:

investigue estado pendente.

E — Reinicia e desfaz

Se aparece algo equivalente a:

Desfazendo alterações

temos:

rollback.

Agora precisamos descobrir:

atualização cumulativa?
driver?
Feature Update?

F — Upgrade de versão

Se está tentando mudar de uma versão do Windows para outra e volta para a anterior:

prioridade:

SetupDiag + Setup logs.

ETAPA 3 — Qual tipo de atualização?

Isso muda completamente o diagnóstico.

Atualização cumulativa

Exemplo:

atualização mensal do Windows.

Se download funciona e instalação falha:

CBS.log ganha prioridade.

Atualização do .NET Framework

Consulte:

CBS.log;
servicing;
Component Store;
source quando aplicável.

Driver

Consulte:

setupapi.dev.log

pnputil.

Feature Update

Consulte:

SetupDiag;
setupact.log;
setuperr.log.

Firmware

Considere:

fabricante;
energia;
BIOS/UEFI;
BitLocker.

Feature on Demand

Exemplo:

.NET Framework 3.5.

Considere:

source;
política;
Features on Demand;
CBS/DISM.

ETAPA 4 — Nível 1: observação

Este é o nível mais seguro.

Ainda não alteramos nada.

Observe recursos

Abra:

taskmgr

resmon

Veja:

CPU;
disco;
rede.

Pergunta

O Windows Update realmente está parado?

Ou existe atividade?

Exemplo

Interface:

Instalando — 0%

Mas:

TiWorker ativo;
disco ativo;
CBS.log crescendo.

Isso sugere:

servicing em andamento.

Não reinicie serviços.

Outro exemplo

Interface:

Baixando — 0%

Mas existe tráfego constante.

Talvez o sistema esteja transferindo conteúdo mesmo que o percentual visual ainda não tenha mudado.

Nível 1 também inclui histórico

Veja:

Histórico de Atualizações.

Talvez a KB já tenha instalado.

ETAPA 5 — Nível 2: diagnóstico sem reparo

Agora coletamos evidências.

WindowsUpdate.log

Execute:

Get-WindowsUpdateLog

Ou:

Get-WindowsUpdateLog -LogPath C:\DiagnosticoWU\WindowsUpdate.log

Serviços

PowerShell:

Get-Service wuauserv,bits,cryptsvc,trustedinstaller,usosvc,dosvc

Não mude StartupType ainda

Estamos observando.

Espaço

Execute:

Get-Volume

Proxy

netsh winhttp show proxy

Rede

ipconfig /all

Políticas

Em ambiente gerenciado:

gpresult /r

CBS

Se a instalação já chegou ao servicing:

C:\Windows\Logs\CBS\CBS.log

DISM

Se existe operação DISM:

C:\Windows\Logs\DISM\dism.log

Driver

C:\Windows\INF\setupapi.dev.log

Upgrade

C:\$WINDOWS.~BT\Sources\Panther

ETAPA 6 — Existe evidência de problema de rede?

Exemplos:

0x80072EE2;
0x80072EFE;
0x80072EFD;
funciona em outra rede;
proxy incorreto.

Se sim:

corrija rede.

Não Component Store.

Testes possíveis

Conforme o cenário:

netsh winhttp show proxy

ipconfig /all

comparação em outra rede confiável.

VPN

Faça teste controlado quando permitido.

DNS

Investigue resolução se houver evidência.

Não troque DNS como ritual.

ETAPA 7 — Evidência de problema BITS?

Exemplos:

0x802000xx

ou job BITS com erro.

Use:

Get-Service bits

Get-BitsTransfer

Não limpe todos os jobs

Descubra qual trabalho apresenta problema.

ETAPA 8 — Evidência de problema de servicing?

Exemplos:

0x800F081F

0x800F0831

0x80073712

ou CBS registra falha.

Agora DISM pode fazer sentido.

Nível 3 — verificações de integridade

Comece com:

DISM /Online /Cleanup-Image /CheckHealth

Depois:

DISM /Online /Cleanup-Image /ScanHealth

CheckHealth e ScanHealth não são iguais

CheckHealth

é uma consulta rápida do estado registrado.

ScanHealth

realiza uma verificação mais profunda.

Se corrupção reparável for identificada

Use:

DISM /Online /Cleanup-Image /RestoreHealth

Depois

Quando apropriado:

sfc /scannow

Não execute essa sequência para timeout de rede

Se o erro é:

0x80072EE2

DISM não é a primeira ferramenta.

ETAPA 9 — RestoreHealth falhou?

Agora o código do próprio DISM importa.

Se retorna 0x800F081F

Precisamos investigar:

source.

Não execute RestoreHealth vinte vezes

Se falta fonte, repetir não cria a fonte.

Fonte compatível

Podemos precisar de:

mídia compatível;
WIM/ESD apropriado;
índice correto.

Nível 4 — reparo direcionado de componentes

Somente agora entramos em ações que modificam mais o estado.

SoftwareDistribution

Se existe evidência de:

cache inconsistente;
download preso;
metadata local problemática;

podemos considerar reconstrução.

Procedimento

net stop wuauserv

net stop bits

ren C:\Windows\SoftwareDistribution SoftwareDistribution.old

net start bits

net start wuauserv

Não faça isso durante servicing ativo

Confirme primeiro que não existe instalação importante em andamento.

catroot2

Se existe evidência relacionada a:

catálogos;
assinatura;
validação;

pode ser considerada reconstrução controlada.

Não junte os dois por hábito

SoftwareDistribution e catroot2 têm funções diferentes.

ETAPA 10 — Problema de certificado?

Se temos:

0x800B0109

0x80096010

ou erros semelhantes:

investigue:

CAPI2;
hora;
cadeia;
assinatura.

Verifique horário

Get-Date

w32tm /query /status

Não instale certificado desconhecido

Nem desative verificação criptográfica.

ETAPA 11 — Problema de espaço?

Se:

0x80070070

ou logs indicam falta de espaço:

execute:

Get-Volume

Em upgrade

Adicione:

Get-Partition

Get-Disk

reagentc /info

Não olhe somente C:

Pode existir problema em:

EFI;
System Reserved;
Recovery;

quando o contexto da atualização realmente envolve essas partições.

Não redimensione por tentativa

Partições são nível avançado.

ETAPA 12 — Problema de driver?

Se temos:

driver falhando;
dispositivo parou;
0xC1900101;

use:

pnputil /enum-drivers

C:\Windows\INF\setupapi.dev.log

Inventário

driverquery /v

Get-CimInstance Win32_PnPSignedDriver | Select-Object DeviceName,DriverVersion,DriverProviderName,InfName

Não atualize todos os drivers

Identifique o suspeito.

ETAPA 13 — Feature Update fez rollback?

Agora entramos em:

Windows Setup.

Use:

SetupDiag

C:\$WINDOWS.~BT\Sources\Panther

Preserve $WINDOWS.~BT

Não use limpadores antes de analisar.

Procure combinação completa

Exemplo:

0xC1900101-0x30018

é muito mais útil que:

0xC1900101.

ETAPA 14 — Computador corporativo?

Se sim, pare antes de remover:

políticas;
WSUS;
proxy;
certificados;
configurações de segurança.

Consulte

gpresult /r

ou:

gpresult /h "%userprofile%\Desktop\gpresult.html"

Pergunta fundamental

O problema acontece:

em um computador

ou:

em muitos computadores?

Muitos computadores

Priorize:

infraestrutura;
WSUS;
proxy;
política;
rede.

Um computador

Priorize:

estado local;
serviço;
cache;
driver;
servicing.

ETAPA 15 — Nível 5: reparo avançado

Agora entramos em procedimentos que exigem maior cuidado.

Exemplos:

DISM com source;
reparo de WinRE;
redimensionamento de partição;
driver específico;
remoção controlada de pacote;
correção de política;
reparo de boot.

Backup antes

Antes de alterações estruturais, tenha:

backup dos dados;
chave BitLocker;
informações do sistema.

BitLocker

Execute:

manage-bde -status

Chave de recuperação

Tenha acesso à chave antes de mudanças envolvendo:

firmware;
TPM;
boot;
partições.

Nunca descubra depois que precisava dela

Esse cuidado evita transformar um problema de Windows Update em um problema de acesso ao computador.

ETAPA 16 — O Windows está muito danificado?

Existem casos em que:

Component Store não repara;
serviços possuem problemas estruturais;
múltiplos componentes do Windows falham;
Windows Update é apenas um dos sintomas.

Agora precisamos considerar reparo mais amplo.

Nível 6 — reparo do Windows mantendo dados e aplicativos

Um:

in-place repair

pode reinstalar componentes do Windows preservando, conforme o método e condições apropriadas:

arquivos pessoais;
aplicativos;
configurações.

Isso não é a mesma coisa que instalação limpa

Essa diferença é essencial.

Quando considerar reparo in-place?

Quando existem evidências de corrupção sistêmica que não foram corrigidas por métodos suportados mais específicos.

Não use como primeiro passo

Se o único problema é:

0x80072EE2

reinstalar Windows é desproporcional.

Nível 7 — instalação limpa

A instalação limpa é a opção mais invasiva.

Ela não deve ser a resposta automática para:

Windows Update apresentou erro.

Quando pode ser considerada?

Quando:

reparos suportados falharam;
corrupção é extensa;
sistema possui múltiplos problemas;
usuário deseja reconstrução limpa;
backup foi realizado.

Formatar não ensina a causa

Mesmo quando resolve, talvez nunca saibamos:

qual componente falhou;
se problema era política;
se problema era rede;
se driver causará novamente.

Por isso diagnóstico continua valioso

Especialmente para técnicos.

Fluxograma completo resumido

Windows Update falhou

↓

registrar KB + código + horário

↓

winver

↓

Existe código?

Sim → identificar família

Não → identificar fase

↓

Busca?

WindowsUpdate.log / comunicação / política.

Download?

BITS / DO / rede / proxy.

Instalação?

CBS / servicing / Component Store.

Reinicialização?

Pending state / CBS.

Rollback cumulativo?

CBS.

Rollback Feature Update?

SetupDiag / Panther.

Driver?

SetupAPI / PnPUtil.

Certificado?

CAPI2.

Espaço?

Volumes/partições.

↓

coletar evidência

↓

formular hipótese

↓

corrigir somente a camada

↓

reiniciar quando necessário

↓

tentar novamente

↓

validar.

Escada de intervenção

Nível 1 — Observar

percentual;
atividade;
Histórico;
horário.

Nível 2 — Diagnosticar

logs;
serviços;
rede;
espaço;
políticas.

Nível 3 — Verificar integridade

DISM CheckHealth;
DISM ScanHealth;
SFC quando apropriado.

Nível 4 — Reparar componentes específicos

RestoreHealth;
SoftwareDistribution;
catroot2 quando justificado.

Nível 5 — Reparos avançados

source DISM;
drivers;
partições;
WinRE;
políticas.

Nível 6 — Repair install

Reparo do Windows preservando dados/aplicativos quando suportado.

Nível 7 — Instalação limpa

Última opção ou escolha deliberada.

Quando parar?

Troubleshooting também exige saber quando não continuar modificando o sistema.

Pare quando:

atualização instalou;
Histórico mostra sucesso;
erro não retorna;
build está correta;
reinicialização pendente desapareceu.

Não continue “otimizando”

Depois que o problema foi resolvido, não execute mais cinco resets:

“só para garantir”.

Isso pode criar um novo problema.

Como validar uma correção?

Atualização cumulativa

Verifique:

Histórico de Atualizações.

Feature Update

Execute:

winver

Confirme a versão/build.

Driver

Verifique:

dispositivo;
versão;
funcionamento.

.NET Framework

Confirme:

KB;
recurso;
aplicação dependente.

Erro de download

Confirme que:

download conclui;
instalação começa;
atualização termina.

A KB não aparece novamente?

Isso também pode ajudar a validar.

Mas verifique o Histórico.

Reinicie e teste novamente

Algumas correções só se confirmam depois da reinicialização.

O código mudou?

Como explicado anteriormente, isso pode significar que o processo avançou.

Exemplo

Antes:

0x80072EE2

Depois:

0x800F081F.

Isso pode representar:

rede corrigida

novo problema encontrado no servicing.

Continue a partir da nova camada.

Não volte ao início automaticamente

A investigação é progressiva.

Método VMIA resumido

1. Sintoma

O que exatamente acontece?

2. Código

Qual código completo?

3. KB

Qual atualização?

4. Horário

Quando ocorreu?

5. Fase

Busca, download, instalação, reboot ou upgrade?

6. Família

Qual camada o código sugere?

7. Log

Qual fonte registra aquela camada?

8. Evidência

O que o log realmente mostra?

9. Hipótese

Qual causa explica os dados?

10. Teste

Qual é a menor mudança capaz de testar a hipótese?

11. Correção

Aplique somente o necessário.

12. Validação

Confirme o resultado.

O que esse método evita?

Evita:

formatar sem necessidade;
resetar Windows Update sem motivo;
apagar caches úteis;
destruir logs;
alterar permissões;
remover certificados;
modificar partições;
trocar drivers aleatoriamente;
desativar segurança.

Kit de comandos para diagnosticar e reparar erros do Windows Update

Ao pesquisar problemas do Windows Update, é comum encontrar blocos enormes de comandos para copiar e executar de uma vez.

Esse método possui um problema:

mistura diagnóstico com reparo.

Alguns comandos apenas consultam informações.

Outros modificam configurações.

Outros reiniciam serviços.

Alguns alteram caches.

E existem comandos capazes de modificar drivers, partições e componentes críticos.

Por isso, vamos separar tudo.

A regra será:

consultar → interpretar → reparar somente quando necessário.

Antes de começar: Terminal como administrador

Muitos comandos deste capítulo exigem privilégios administrativos.

No Windows 11, abra:

Terminal (Administrador)

ou PowerShell/Prompt de Comando elevado, conforme a operação.

1. Identificar a versão do Windows

O primeiro comando continua sendo um dos mais simples:

winver

Ele ajuda a identificar:

versão;
edição;
build.

PowerShell

Para informações adicionais:

Get-ComputerInfo | Select-Object WindowsProductName,WindowsVersion,OsBuildNumber,OsArchitecture

Isso ajuda principalmente quando precisamos comparar:

KB;
build;
arquitetura;
compatibilidade.

systeminfo

Outra opção:

systeminfo

Para salvar:

systeminfo > "%userprofile%\Desktop\systeminfo.txt"

2. Criar pasta de diagnóstico

Antes de coletar informações:

mkdir C:\DiagnosticoWU

Se a pasta já existir, utilize-a com cuidado para não confundir logs antigos com a investigação atual.

Uma alternativa profissional é criar subpastas por data.

Por exemplo:

C:\DiagnosticoWU\2026-09-19

3. Gerar WindowsUpdate.log

No PowerShell:

Get-WindowsUpdateLog

Para especificar destino:

Get-WindowsUpdateLog -LogPath C:\DiagnosticoWU\WindowsUpdate.log

Para que serve?

Ajuda a investigar:

detecção;
Windows Update Agent;
download;
comunicação;
códigos relacionados à operação.

Não confunda com CBS.log

Se o pacote já chegou ao servicing, CBS pode ser mais importante.

4. Copiar CBS.log

Caminho original:

C:\Windows\Logs\CBS\CBS.log

Copie:

copy C:\Windows\Logs\CBS\CBS.log C:\DiagnosticoWU\CBS.txt

CBS.log é especialmente importante para

0x800Fxxxx;
0x800737xx;
atualizações cumulativas;
.NET Framework;
Component Store;
Features on Demand.

5. Copiar DISM.log

Caminho:

C:\Windows\Logs\DISM\dism.log

Copie:

copy C:\Windows\Logs\DISM\dism.log C:\DiagnosticoWU\DISM.txt

Quando é útil?

Principalmente quando executamos operações com:

DISM.

6. Pesquisar código dentro de log

PowerShell:

Select-String -Path C:\DiagnosticoWU\CBS.txt -Pattern "0x800F081F"

Procurar KB

Select-String -Path C:\DiagnosticoWU\WindowsUpdate.log -Pattern "KBxxxxxxx"

Procurar mais de um padrão

Select-String -Path C:\DiagnosticoWU\CBS.txt -Pattern "0x800F081F","0x80073712"

Cuidado com “error”

Pesquisar apenas:

error

pode produzir centenas ou milhares de resultados.

Código + horário costuma ser muito mais eficiente.

7. Consultar serviços do Windows Update

PowerShell:

Get-Service wuauserv,bits,cryptsvc,trustedinstaller,usosvc,dosvc

Prompt de Comando

Individualmente:

sc query wuauserv

sc query bits

sc query cryptsvc

sc query trustedinstaller

Consultar configuração

sc qc wuauserv

sc qc bits

sc qc cryptsvc

sc qc trustedinstaller

Atenção

Um serviço:

STOPPED

não significa automaticamente:

serviço quebrado.

Alguns serviços funcionam sob demanda e por gatilhos.

8. Não coloque todos os serviços em Automatic

Essa é uma prática muito comum em tutoriais.

Ela pode alterar o comportamento esperado do Windows.

Antes de modificar:

descubra a configuração e o motivo.

9. BITS

Consultar:

Get-Service bits

Jobs BITS

PowerShell:

Get-BitsTransfer

Em contexto administrativo apropriado:

Get-BitsTransfer -AllUsers

O que observar?

estado;
arquivos;
bytes;
progresso;
erro.

Não apague todos os jobs

BITS pode ser utilizado por outras aplicações.

Identifique primeiro.

10. Delivery Optimization

Consultar serviço:

sc query dosvc

PowerShell:

Get-Service dosvc

Diagnóstico adicional

Em versões compatíveis do Windows/PowerShell, comandos do módulo Delivery Optimization podem fornecer informações sobre transferências.

A disponibilidade e saída podem variar conforme a versão do Windows.

11. Configuração IP

Execute:

ipconfig /all

O que observar?

IPv4;
IPv6;
gateway;
DNS;
DHCP;
adaptador utilizado.

Não procure somente endereço IPv4

Windows Update pode depender de uma pilha de rede muito mais ampla.

12. Limpar cache DNS

Comando:

ipconfig /flushdns

Mas use quando existir motivo para suspeitar de cache DNS.

Não é reparo universal

flushdns

não corrige:

Component Store;
driver;
certificado;
espaço;
servicing.

13. Proxy WinHTTP

Consulte primeiro:

netsh winhttp show proxy

Isso é extremamente importante

Um navegador funcionando não prova que WinHTTP e Windows Update estão utilizando exatamente a mesma configuração.

Resetar proxy

Existe:

netsh winhttp reset proxy

Mas não execute antes de saber se o proxy é necessário.

Em empresa, você pode remover uma configuração legítima.

14. Winsock

Existe:

netsh winsock reset

Esse comando é frequentemente incluído em scripts genéricos.

Não deve ser usado automaticamente em qualquer falha do Windows Update.

Use quando a investigação realmente indicar problema relacionado à pilha Winsock.

15. Testar resolução DNS

Podemos usar:

nslookup

com um nome relevante ao problema.

Mas lembre-se:

DNS resolvendo não prova que HTTPS funciona.

16. Ping

ping

é útil para determinados diagnósticos de conectividade.

Mas:

ping não é teste do Windows Update.

Um servidor pode não responder ICMP e continuar funcionando normalmente por HTTPS.

17. Test-NetConnection

PowerShell oferece:

Test-NetConnection

Ele pode testar conectividade para host/porta quando existe um endpoint específico relevante.

Novamente:

não invente um servidor aleatório para “testar Windows Update”.

18. Políticas

Para resumo:

gpresult /r

Relatório HTML

gpresult /h "%userprofile%\Desktop\gpresult.html"

Ou:

gpresult /h C:\DiagnosticoWU\gpresult.html

Quando isso é importante?

Principalmente em:

empresas;
escolas;
computadores gerenciados;
WSUS;
políticas de Windows Update;
Features on Demand.

19. DISM CheckHealth

Execute:

DISM /Online /Cleanup-Image /CheckHealth

Função

Consulta rapidamente se o Windows registrou corrupção no Component Store.

20. DISM ScanHealth

DISM /Online /Cleanup-Image /ScanHealth

Faz uma análise mais profunda.

Pode levar algum tempo.

21. DISM RestoreHealth

Quando existe motivo para reparar:

DISM /Online /Cleanup-Image /RestoreHealth

Não execute sem interpretar

Se retorna:

0x800F081F

não adianta repetir infinitamente.

Pode existir problema de:

source.

22. DISM com source

Quando existe fonte compatível e necessidade real, a sintaxe pode envolver algo como:

DISM /Online /Cleanup-Image /RestoreHealth /Source:wim:D:\sources\install.wim:INDICE /LimitAccess

ou:

DISM /Online /Cleanup-Image /RestoreHealth /Source:esd:D:\sources\install.esd:INDICE /LimitAccess

INDICE não é texto literal

É necessário descobrir o índice correto.

23. Descobrir índices de WIM

DISM /Get-WimInfo /WimFile:D:\sources\install.wim

ESD

DISM /Get-WimInfo /WimFile:D:\sources\install.esd

Não escolha índice aleatório

Confirme a edição correspondente.

24. SFC

Comando:

sfc /scannow

Para que serve?

Verifica arquivos protegidos do Windows e tenta reparar problemas quando possível.

Não confunda com DISM

SFC e DISM não fazem exatamente a mesma coisa.

25. SFC apenas para verificação

Existe:

sfc /verifyonly

Isso permite verificar sem realizar reparos.

26. Consultar pacotes do Windows

DISM /Online /Get-Packages

Para que serve?

Pode ajudar a investigar:

pacotes;
estado;
servicing;
KBs.

Não remova pacote por tentativa

Não transforme:

/Get-Packages

automaticamente em:

/Remove-Package.

Remoção exige identificação e justificativa.

27. Component Store

Para análise:

DISM /Online /Cleanup-Image /AnalyzeComponentStore

Isso ajuda a entender

estado;
tamanho;
possibilidade de limpeza recomendada.

28. Limpeza suportada

Quando apropriado:

DISM /Online /Cleanup-Image /StartComponentCleanup

Limpeza não é reparo

Esse comando não deve ser apresentado como solução universal para corrupção.

29. ResetBase

Existem opções avançadas relacionadas à limpeza de componentes.

Mas:

não utilize indiscriminadamente.

Algumas opções podem reduzir possibilidades de reversão de componentes/updates.

30. CHKDSK

Para verificação online:

chkdsk C: /scan

Quando faz sentido?

Quando existe evidência relacionada a:

filesystem;
leitura;
corrupção;
armazenamento.

Não use CHKDSK como ritual do Windows Update

Erro de proxy não exige CHKDSK.

31. Ver volumes

PowerShell:

Get-Volume

32. Ver discos

Get-Disk

33. Ver partições

Get-Partition

Salvar informações

Get-Disk | Format-Table -AutoSize | Out-File C:\DiagnosticoWU\discos.txt

Get-Partition | Format-Table -AutoSize | Out-File C:\DiagnosticoWU\particoes.txt

Get-Volume | Format-Table -AutoSize | Out-File C:\DiagnosticoWU\volumes.txt

34. WinRE

Execute:

reagentc /info

Salvar

reagentc /info > C:\DiagnosticoWU\winre.txt

Isso ajuda a identificar

se WinRE está habilitado;
localização do ambiente de recuperação.

Não execute reagentc /disable sem motivo

Desativar e reativar WinRE faz parte de alguns procedimentos específicos.

Não é manutenção comum do Windows Update.

35. BitLocker

Execute:

manage-bde -status

Salvar

manage-bde -status > C:\DiagnosticoWU\bitlocker.txt

Por que isso está em um guia de Windows Update?

Porque algumas correções avançadas podem envolver:

firmware;
TPM;
boot;
partições.

Nesses casos, BitLocker importa.

36. PnPUtil

Listar pacotes de driver:

pnputil /enum-drivers

Salvar

pnputil /enum-drivers > C:\DiagnosticoWU\drivers.txt

Dispositivos conectados

Em versões compatíveis:

pnputil /enum-devices /connected

Dispositivos problemáticos

Em versões compatíveis:

pnputil /enum-devices /problem

Não remova drivers indiscriminadamente

Comandos de remoção do PnPUtil podem afetar dispositivos essenciais.

37. driverquery

Execute:

driverquery /v

Salvar

driverquery /v > C:\DiagnosticoWU\driverquery.txt

38. Inventário PowerShell de drivers

Get-CimInstance Win32_PnPSignedDriver | Select-Object DeviceName,DriverVersion,DriverDate,DriverProviderName,InfName

Salvar

Get-CimInstance Win32_PnPSignedDriver | Select-Object DeviceName,DriverVersion,DriverDate,DriverProviderName,InfName | Out-File C:\DiagnosticoWU\pnp-drivers.txt

39. SetupAPI

Log:

C:\Windows\INF\setupapi.dev.log

Copie para diagnóstico quando necessário.

40. Setup logs

Para upgrade:

C:\$WINDOWS.~BT\Sources\Panther

Procure:

setupact.log

setuperr.log

Não apague $WINDOWS.~BT antes de analisar

Limpeza pode remover informações úteis.

41. Monitor de Confiabilidade

Execute:

perfmon /rel

Excelente para linha do tempo

Ele pode mostrar:

instalação;
falha;
aplicativo;
driver.

42. Visualizador de Eventos

Execute:

eventvwr.msc

Use horário

Não navegue milhares de eventos sem filtro.

43. Gerenciador de Dispositivos

Execute:

devmgmt.msc

44. Gerenciamento de Disco

Execute:

diskmgmt.msc

Não modifique partições imediatamente

Use primeiro para:

visualizar.

45. Informações do Sistema

Execute:

msinfo32

Útil para:

BIOS;
modo BIOS;
hardware;
sistema.

Kit VMIA de coleta — sem reparo agressivo

Agora podemos criar uma sequência destinada principalmente a:

coletar informações.

Crie a pasta:

mkdir C:\DiagnosticoWU

Windows

systeminfo > C:\DiagnosticoWU\systeminfo.txt

Windows Update

PowerShell:

Get-WindowsUpdateLog -LogPath C:\DiagnosticoWU\WindowsUpdate.log

CBS

copy C:\Windows\Logs\CBS\CBS.log C:\DiagnosticoWU\CBS.txt

DISM

copy C:\Windows\Logs\DISM\dism.log C:\DiagnosticoWU\DISM.txt

Serviços

PowerShell:

Get-Service wuauserv,bits,cryptsvc,trustedinstaller,usosvc,dosvc | Format-Table -AutoSize | Out-File C:\DiagnosticoWU\servicos.txt

Rede

ipconfig /all > C:\DiagnosticoWU\ipconfig.txt

Proxy

netsh winhttp show proxy > C:\DiagnosticoWU\proxy.txt

Políticas

gpresult /h C:\DiagnosticoWU\gpresult.html

Drivers

pnputil /enum-drivers > C:\DiagnosticoWU\drivers.txt

Discos

PowerShell:

Get-Disk | Format-Table -AutoSize | Out-File C:\DiagnosticoWU\discos.txt

Partições

Get-Partition | Format-Table -AutoSize | Out-File C:\DiagnosticoWU\particoes.txt

Volumes

Get-Volume | Format-Table -AutoSize | Out-File C:\DiagnosticoWU\volumes.txt

WinRE

reagentc /info > C:\DiagnosticoWU\winre.txt

BitLocker

manage-bde -status > C:\DiagnosticoWU\bitlocker.txt

Esse kit não “conserta” Windows Update

E isso é proposital.

Ele coleta informações para que o reparo seja decidido depois.

Kit mínimo para usuário doméstico

Nem sempre precisamos de tudo.

Uma versão simples seria:

winver
Histórico do Windows Update
código do erro
KB
horário
Get-WindowsUpdateLog
CBS.log se a instalação falhou.

Com isso já conseguimos avançar bastante.

Kit para erro de rede

Use:

ipconfig /all

netsh winhttp show proxy

Get-WindowsUpdateLog

e comparação controlada de rede quando apropriado.

Kit para servicing

Use:

Get-WindowsUpdateLog

CBS.log

DISM /Online /Cleanup-Image /CheckHealth

DISM /Online /Cleanup-Image /ScanHealth

Kit para driver

Use:

pnputil /enum-drivers

driverquery /v

setupapi.dev.log

Kit para upgrade

Use:

código completo;
SetupDiag;
setupact.log;
setuperr.log;
setupapi.dev.log;
inventário de drivers.

Kit para espaço/partição

Use:

Get-Disk

Get-Partition

Get-Volume

reagentc /info

manage-bde -status

Kit para certificados

Use:

código;
horário;
CAPI2;
Get-Date;
w32tm /query /status.

Agora os comandos que exigem mais cuidado

A partir daqui entramos em comandos que podem modificar o sistema.

Reiniciar serviços

Exemplo:

net stop wuauserv

net stop bits

net start bits

net start wuauserv

Isso pode ser apropriado em procedimento específico.

Não faça durante uma instalação ativa sem entender o estado.

Reconstruir SoftwareDistribution

Quando existe evidência:

net stop wuauserv

net stop bits

ren C:\Windows\SoftwareDistribution SoftwareDistribution.old

net start bits

net start wuauserv

Por que renomear?

Porque:

SoftwareDistribution.old

preserva temporariamente o conteúdo anterior.

Isso é melhor para diagnóstico do que apagar imediatamente.

catroot2

Quando tecnicamente justificado:

net stop cryptsvc

ren %windir%\System32\catroot2 catroot2.old

net start cryptsvc

Não confunda catroot com catroot2

Não saia apagando pastas com nomes parecidos.

Não execute os dois resets automaticamente

Cada um possui função diferente.

DISM RestoreHealth

Modifica o estado ao reparar componentes.

Execute quando a investigação justificar.

SFC /scannow

Também pode reparar arquivos.

Se você quer apenas verificar primeiro:

sfc /verifyonly

A diferença entre consultar e reparar

Esse é um conceito essencial.

Consulta

Get-Volume

Modificação

redimensionar partição.

Consulta

pnputil /enum-drivers

Modificação

remover pacote de driver.

Consulta

netsh winhttp show proxy

Modificação

netsh winhttp reset proxy.

Consulta

DISM /ScanHealth

Reparação

DISM /RestoreHealth.

Sempre saiba de qual lado está

Isso reduz riscos.

Comandos que não devem entrar em um “script mágico”

Evite scripts que executem indiscriminadamente:

reset de Winsock;
reset de proxy;
limpeza de DNS;
reset de SoftwareDistribution;
reset de catroot2;
SFC;
DISM;
alteração de serviços;
Registro;
permissões;

tudo em uma única execução.

O problema dos scripts gigantes

Se resolver:

não sabemos por quê.

Se não resolver:

destruímos várias pistas.

Se causar novo problema:

fica difícil descobrir qual alteração provocou.

Diagnóstico profissional é reproduzível

O ideal é conseguir dizer:

“o erro acontecia por X; confirmei através de Y; alterei Z; depois validei com W.”

“rodei um script e voltou.”

Isso é muito melhor do que:

O que não fazer ao reparar o Windows Update: comandos perigosos, scripts milagrosos e soluções que podem piorar o problema

Quando o Windows Update falha, uma pesquisa rápida costuma retornar procedimentos como:

“Execute estes 20 comandos e resolva qualquer erro do Windows Update.”

Normalmente aparecem juntos:

parar serviços;
apagar caches;
registrar DLLs;
resetar Winsock;
resetar proxy;
alterar Registro;
executar SFC;
executar DISM;
apagar pastas;
mudar permissões.

Alguns desses procedimentos são legítimos.

O problema é:

eles não corrigem todos os tipos de erro.

Pior:

algumas alterações podem remover justamente as evidências necessárias para descobrir a causa.

Regra principal: não existe “reset universal” do Windows Update

Windows Update pode falhar por:

rede;
proxy;
BITS;
Delivery Optimization;
Windows Update Agent;
certificados;
assinatura;
Component Store;
servicing;
drivers;
espaço;
EFI;
Recovery;
WinRE;
política;
WSUS;
Windows Setup;
hardware.

Portanto, um único script dificilmente consegue corrigir adequadamente todas essas possibilidades.

1. Apagar SoftwareDistribution imediatamente

Uma das recomendações mais conhecidas é excluir:

C:\Windows\SoftwareDistribution

A reconstrução dessa estrutura pode ser útil em alguns cenários.

Mas não deve ser o primeiro passo de qualquer diagnóstico.

Quando pode fazer sentido?

Quando existem evidências relacionadas a:

cache local;
download inconsistente;
metadados locais;
conteúdo de atualização problemático.

Quando provavelmente não resolve?

Por exemplo:

0x800F081F

por source ausente.

Ou:

0x80070070

por falta de espaço.

Ou:

0xC1900101

relacionado ao upgrade/driver.

Ou:

0x800B0109

relacionado à confiança/certificados.

Prefira renomear quando o procedimento for justificado

Em vez de destruir imediatamente:

ren C:\Windows\SoftwareDistribution SoftwareDistribution.old

Isso mantém temporariamente o estado anterior disponível.

Não faça durante servicing ativo

Se Windows está:

instalando;
processando;
finalizando atualização;

interromper componentes pode criar mais inconsistência.

2. Apagar catroot2 em qualquer erro

Outra receita comum é reconstruir:

catroot2.

Isso pode ter utilidade em determinados problemas relacionados a catálogos e validação.

Mas:

catroot2 não é sinônimo de Windows Update inteiro.

SoftwareDistribution e catroot2 não são a mesma coisa

Não trate os dois diretórios como:

“duas pastas de cache que sempre devem ser apagadas juntas”.

Nunca confunda catroot e catroot2

Alterar diretórios errados do sistema pode criar problemas adicionais.

3. Apagar pending.xml

Alguns tutoriais recomendam localizar arquivos relacionados a operações pendentes e simplesmente excluí-los.

Isso é uma abordagem perigosa.

Por quê?

Estado pendente pode representar:

operação de servicing;
atualização aguardando reinicialização;
componente aguardando conclusão.

Apagar arquivos internos para “forçar” o Windows a esquecer o estado não corrige necessariamente a causa.

Pode apenas quebrar a continuidade do servicing.

Se o Windows insiste em pedir reinicialização

Primeiro investigue:

CBS.log;
Histórico;
atualização pendente;
erro original.

Não comece removendo arquivos internos.

4. Apagar chaves PendingFileRenameOperations

Outro exemplo de abordagem agressiva:

apagar estados pendentes do Registro porque existe reinicialização pendente.

Um valor pendente pode existir porque alguma operação realmente precisa ser concluída.

A pergunta correta é:

quem criou esse estado e por quê?

5. Tomar posse do WinSxS

Evite tutoriais que mandam:

assumir propriedade;
conceder controle total;
apagar componentes.

O diretório:

C:\Windows\WinSxS

faz parte da infraestrutura de componentes do Windows.

WinSxS não é uma pasta de “arquivos duplicados inúteis”

A forma como o Windows contabiliza espaço nessa área também pode envolver hard links.

Por isso, o tamanho aparente pode ser mal interpretado.

Use ferramentas suportadas

Para analisar:

DISM /Online /Cleanup-Image /AnalyzeComponentStore

Quando apropriado:

DISM /Online /Cleanup-Image /StartComponentCleanup

Não faça limpeza manual

Nunca transforme:

“Component Store grande”

em:

“vou apagar WinSxS”.

6. Alterar permissões do TrustedInstaller

TrustedInstaller existe por uma razão.

Ele participa da proteção e manutenção de componentes do Windows.

“Access denied” não significa que devemos tomar posse de tudo

Se recebemos:

0x80070005

precisamos descobrir:

acesso negado a quê?

Não conceda Everyone Full Control

Especialmente em:

Windows;
System32;
WinSxS;
DriverStore;
Registro do sistema.

Isso pode enfraquecer segurança e quebrar o modelo de servicing.

7. Matar TrustedInstaller ou TiWorker

Durante atualizações, processos relacionados ao servicing podem consumir:

CPU;
disco.

Isso não significa que estejam travados.

TiWorker com CPU alta pode ser normal

Observe:

tempo;
atividade;
CBS.log.

Não use Finalizar Tarefa como primeira solução

Interromper servicing no momento errado pode deixar operação incompleta.

8. Apagar DriverStore

Nunca tente corrigir Windows Update excluindo manualmente:

C:\Windows\System32\DriverStore

FileRepository

Também evite limpeza manual de:

FileRepository.

Pacotes presentes ali podem ser necessários por dispositivos atuais ou futuras operações PnP.

Use PnPUtil

Para consultar:

pnputil /enum-drivers

Remover pacote exige identificação

Antes de qualquer remoção, precisamos saber:

qual INF;
qual dispositivo;
qual versão;
se o pacote está em uso;
qual alternativa existe.

9. Apagar arquivos .sys manualmente

Um driver não é apenas um .sys.

Excluir um arquivo pode deixar:

serviço registrado;
INF;
catálogo;
dependências;

em estado inconsistente.

10. Baixar SYS ou DLL de sites desconhecidos

Se um log aponta arquivo ausente, não pesquise:

nome-do-arquivo.dll download

e copie o primeiro resultado para System32.

Por quê?

Você não conhece:

origem;
versão;
arquitetura;
assinatura;
integridade.

Use mecanismos suportados de reparo e fontes confiáveis.

11. Usar programas “Driver Updater”

Evite ferramentas genéricas que prometem:

“encontramos 37 drivers desatualizados”.

Mais novo não significa automaticamente:

melhor para aquele hardware.

Drivers OEM podem possuir personalizações

Especialmente em:

notebooks;
áudio;
gráficos híbridos;
energia;
touchpad;
sensores.

12. Atualizar todos os drivers para corrigir 0xC1900101

0xC1900101

pode direcionar a investigação para drivers durante upgrades.

Mas isso não significa:

atualize absolutamente todos.

Melhor abordagem

Use:

SetupDiag;
Setup logs;
SetupAPI;
inventário de drivers.

Encontre o suspeito.

13. Alterar AHCI/RAID na BIOS por tentativa

Essa alteração pode impedir o Windows de iniciar.

Um possível resultado é:

INACCESSIBLE_BOOT_DEVICE.

Não altere modo de armazenamento sem plano

Principalmente em sistemas com:

RAID;
Intel RST;
controladores específicos;
BitLocker.

14. Atualizar BIOS porque Windows Update falhou

Firmware pode ser relevante em determinados casos.

Mas:

Windows Update falhou

não significa automaticamente:

BIOS desatualizada.

Se firmware for realmente necessário

Use:

fabricante;
modelo exato;
energia estável;
procedimento oficial.

E verifique BitLocker.

15. Redimensionar EFI porque apareceu 0x800F0922

Esse é um dos mitos mais perigosos.

0x800F0922

não deve ser traduzido automaticamente como:

EFI cheia.

Primeiro

Consulte:

CBS.log.

Depois, se houver evidência relacionada a partições, analise:

Get-Disk

Get-Partition

Get-Volume

Só então considere alteração estrutural

Particionamento não deve ser troubleshooting por tentativa.

16. Excluir partição Recovery

O usuário vê várias partições e pensa:

“não uso isso”.

Mas uma delas pode conter WinRE.

Consulte

reagentc /info

antes de qualquer decisão.

Recovery pequena não significa inútil

E múltiplas partições Recovery podem existir por histórico de upgrades/OEM.

Descubra qual está em uso.

17. Formatar a EFI

Nunca formate a EFI como teste para Windows Update.

Ela contém elementos essenciais do processo de inicialização em sistemas UEFI.

Um problema de atualização pode virar:

Windows não inicia.

18. DiskPart clean

O comando:

clean

no DiskPart é destrutivo para a estrutura de particionamento selecionada.

Não existe motivo para utilizá-lo como reparo comum do Windows Update.

Cuidado extremo com tutoriais de DiskPart

Antes de executar qualquer comando:

confirme:

disco;
volume;
partição.

19. Converter GPT/MBR apenas porque update falhou

Não altere estilo de partição sem uma razão técnica clara.

Windows Update comum não exige que você fique convertendo o disco.

20. Desabilitar IPv6

Outra receita recorrente:

“Windows Update não funciona? Desative IPv6.”

Não faça isso como primeira tentativa.

IPv6 não é um erro

Se existe evidência específica relacionada à conectividade IPv6, investigue.

Caso contrário, preserve a configuração normal.

21. Alterar MTU aleatoriamente

MTU pode causar problemas reais em determinados cenários.

Mas escolher:

1400;
1450;
1472;

porque alguém usou esse número em outro roteador não é diagnóstico.

Se suspeitar de MTU

Teste e meça.

Não adivinhe.

22. Trocar DNS por 8.8.8.8 automaticamente

Google DNS ou outro resolvedor pode ser excelente.

Mas:

Windows Update falhou ≠ DNS ruim.

Primeiro confirme

Existe problema de resolução?

Em rede corporativa

Trocar DNS pode quebrar:

domínio;
nomes internos;
políticas;
serviços locais.

23. Executar Winsock reset em qualquer erro

netsh winsock reset

é uma ferramenta válida em contextos específicos.

Não corrige:

Component Store;
assinatura;
driver incompatível;
falta de espaço.

24. Resetar WinHTTP proxy sem olhar

Primeiro:

netsh winhttp show proxy

Depois decida.

Empresa

Proxy pode ser necessário.

Resetá-lo pode criar:

um novo problema de conectividade.

25. Desativar firewall permanentemente

Se existe suspeita de filtragem, diagnostique.

Não transforme:

teste controlado

em:

proteção permanentemente desativada.

26. Desativar antivírus indiscriminadamente

Produtos de segurança podem interferir em determinadas situações.

Mas não presuma isso sem evidência.

Prefira

logs;
documentação;
teste controlado;
desinstalação suportada quando realmente necessária.

27. Instalar certificado raiz aleatório

Especialmente perigoso.

Se aparece:

0x800B0109

investigue a cadeia.

Não instale certificados encontrados em fóruns para fazer o erro desaparecer.

Um root certificate concede confiança

Adicionar uma raiz não confiável pode afetar a segurança do sistema inteiro.

28. Desabilitar verificação de certificados

Não reduza segurança para fazer uma atualização instalar.

Corrija a cadeia ou causa legítima.

29. Ativar protocolos criptográficos antigos

Se existe erro TLS, não conclua:

“ative tudo”.

Protocolos antigos podem ter sido desativados por segurança.

Diagnóstico correto

Descubra:

cliente;
servidor;
proxy;
TLS;
política;
certificados.

30. Remover WSUS de computador corporativo

Não altere políticas corporativas para fazer o PC acessar diretamente Windows Update.

Pode existir uma arquitetura intencional.

Consulte

gpresult /r

e a administração responsável.

31. Apagar chaves do Registro do Windows Update

Muitos scripts removem grandes blocos de configuração.

Isso pode destruir:

política;
histórico de configuração;
estado necessário.

Registro não é cache descartável

Faça alterações apenas quando souber:

chave;
valor;
efeito;
origem da configuração.

32. Desabilitar Windows Update permanentemente

Alguns “otimizadores” prometem:

“pare de ter problemas desativando atualizações”.

Isso não corrige Windows Update.

Apenas impede o mecanismo de funcionar normalmente.

Atualizações possuem função de segurança

Desabilitação permanente pode deixar correções importantes ausentes.

33. Desabilitar WaaSMedicSvc à força

Windows Update Medic participa da manutenção de componentes relacionados ao Windows Update.

Modificar permissões para impedir seu funcionamento não é troubleshooting normal.

34. Desabilitar Update Orchestrator

Mesma lógica.

O Windows utiliza orquestração para coordenar atualizações.

Desabilitar tarefas e serviços pode criar sintomas adicionais.

35. Colocar todos os serviços em Automatic

Isso também é errado.

Windows utiliza:

Manual;
trigger start;
automático;
outros comportamentos;

conforme o serviço.

“STOPPED” não significa “Disabled”

Essa diferença é fundamental.

36. Registrar dezenas de DLLs com regsvr32

Tutoriais antigos podem listar dezenas de DLLs:

regsvr32 ...

Isso não é um reset universal moderno do Windows Update.

DLL existe ≠ precisa ser registrada

Nem todo componente funciona através desse mecanismo.

37. Usar ISO modificada como source do DISM

Se DISM precisa de fonte, use mídia confiável e compatível.

Uma ISO modificada pode ter:

componentes removidos;
versões alteradas;
customizações.

Isso prejudica a previsibilidade do reparo.

38. Usar qualquer install.wim

Ter:

install.wim

não basta.

Verifique:

arquitetura;
edição;
versão;
build;
índice.

Consulte

DISM /Get-WimInfo /WimFile:D:\sources\install.wim

39. Usar /LimitAccess sem fonte adequada

Se você diz ao DISM para não procurar conteúdo online e fornece uma origem inadequada, o reparo pode falhar.

Entenda a função do parâmetro.

40. Repetir RestoreHealth infinitamente

Se:

DISM /RestoreHealth

retorna consistentemente:

0x800F081F

a questão provavelmente não é:

quantas vezes executar.

Precisamos investigar a origem.

41. Rodar SFC cinco vezes até “dar certo”

SFC é uma ferramenta de diagnóstico/reparo, não um jogo de repetição.

Leia o resultado.

42. Executar CHKDSK pesado sem evidência

CHKDSK pode ser apropriado quando há suspeita de filesystem.

Mas não é uma correção de:

proxy;
certificado;
política.

43. Usar limpadores de Registro

Windows Update depende de uma infraestrutura complexa.

“Limpar” chaves consideradas desnecessárias por ferramentas genéricas pode introduzir inconsistências.

44. Limpar Event Viewer

Não faça isso antes de diagnosticar.

Você pode apagar justamente:

horário;
erro;
serviço;
sequência.

45. Apagar CBS.log

Mesmo raciocínio.

Logs são evidências.

46. Apagar $WINDOWS.~BT

Depois de um upgrade que fez rollback, essa pasta pode conter logs extremamente importantes.

Não limpe antes de usar:

SetupDiag;
setupact.log;
setuperr.log.

47. Apagar Windows.old imediatamente

Depois de um upgrade, Windows.old pode participar das opções de retorno por um período limitado e conter dados da instalação anterior.

Não elimine apenas para recuperar espaço sem considerar:

rollback;
recuperação;
necessidade de investigação.

48. Forçar Feature Update ignorando bloqueio de compatibilidade

Se determinada versão não está sendo oferecida, pode existir:

implantação gradual;
política;
requisito;
safeguard relacionado à compatibilidade.

“Não apareceu” não significa “Windows Update está quebrado”

Antes de forçar, descubra o motivo.

49. Contornar requisitos sem avaliar consequências

Instalar uma versão do Windows em hardware fora dos requisitos é uma decisão diferente de reparar Windows Update.

Não misture os dois problemas.

50. Reinstalar Windows imediatamente

Formatação pode eliminar muitos problemas locais.

Mas isso não significa que seja a solução correta.

Exemplo

Problema real:

proxy corporativo.

Você formata.

Computador volta para a mesma rede.

Política volta.

Erro volta.

A formatação não tratou a causa.

Outro exemplo

Problema:

driver incompatível distribuído novamente.

Depois da instalação limpa, Windows Update baixa o mesmo driver.

Problema reaparece.

Formatar deve ser uma decisão, não reflexo

Antes, avalie:

causa;
reparabilidade;
backup;
custo;
tempo.

51. Fazer dez mudanças de uma vez

Esse é talvez o erro mais importante.

Imagine:

resetar rede;
trocar DNS;
apagar SoftwareDistribution;
apagar catroot2;
rodar SFC;
rodar DISM;
atualizar drivers;
alterar serviços.

Depois funciona.

Qual era a causa?

Não sabemos.

Faça uma alteração por hipótese

Exemplo:

Hipótese: WinHTTP proxy está incorreto.

Evidência: log mostra falha de comunicação e configuração inesperada.

Teste: corrigir proxy.

Resultado: Windows Update consegue baixar.

Agora temos diagnóstico reproduzível.

Reversibilidade

Prefira inicialmente ações que possam ser revertidas.

Exemplo:

renomear:

SoftwareDistribution

em vez de apagar imediatamente.

Preserve o estado anterior

Isso ajuda tanto em:

diagnóstico;
recuperação.

Matriz de risco

Procedimento	Risco se usado cegamente
`ipconfig /flushdns`	Baixo, mas pode ser inútil
Reiniciar serviço	Baixo/médio conforme estado
Reset Winsock	Médio
Reset WinHTTP proxy	Médio/alto em empresa
Renomear SoftwareDistribution	Médio
Renomear catroot2	Médio
DISM RestoreHealth	Normalmente controlado, mas exige interpretação
Remover driver	Médio/alto
Alterar Registro	Variável/alto
Redimensionar partição	Alto
Alterar EFI	Muito alto
Alterar boot	Muito alto
`diskpart clean`	Destrutivo

Uma ferramenta pode ser segura em um contexto e perigosa em outro

Esse é o ponto central.

pnputil

é excelente.

Mas:

pnputil /enum-drivers

é consulta.

Remover um pacote é outra coisa.

DISM é excelente

Mas:

DISM /ScanHealth

não é equivalente a remover pacotes.

DiskPart é excelente

Mas:

list disk

não é equivalente a:

clean.

PowerShell é excelente

Mas um script baixado da internet pode executar qualquer alteração permitida pelos privilégios concedidos.

Leia scripts antes de executar como administrador

Não execute:

.bat

.cmd

.ps1

como administrador sem saber o que fazem.

“Código aberto” não significa que você leu

Mesmo quando o script está disponível, confira os comandos relevantes antes de executá-lo.

Cuidado com scripts que desativam proteção

Se o script pede para:

desligar Defender;
desabilitar SmartScreen;
reduzir política de execução;
desabilitar firewall;

sem uma justificativa clara, pare e investigue.

Princípio da menor alteração

A melhor correção normalmente é:

a menor alteração capaz de corrigir a causa confirmada.

Exemplo

Erro:

0x80070070

Causa confirmada:

falta de espaço em volume necessário.

Correção:

liberar/ajustar espaço apropriado.

Não:

resetar BITS + DNS + certificados + drivers.

Outro exemplo

Erro:

0x80072EE2

Causa:

proxy incorreto.

Correção:

proxy.

Não:

DISM + SFC + WinSxS.

Outro exemplo

Erro:

0x80073712

CBS e DISM confirmam Component Store.

Agora:

DISM é coerente.

Outro exemplo

Erro:

0xC1900101

SetupDiag aponta driver específico.

Agora:

driver é o alvo.

Não:

catroot2.

Regra profissional

Antes de executar qualquer reparo, consiga completar a frase:

“Estou fazendo isso porque…”

Se a resposta for:

“porque um vídeo mandou”

ainda falta diagnóstico.

Checklist antes de qualquer alteração importante

Pergunte:

Tenho o código?
Tenho a KB?
Sei a fase?
Tenho o horário?
Preservei os logs?
Sei qual componente quero alterar?
Tenho evidência contra esse componente?
A alteração é reversível?
Existe backup?
Existe BitLocker?
Preciso da chave de recuperação?
Sei como validar depois?

Se várias respostas forem:

não

provavelmente ainda é cedo para uma intervenção avançada.

FAQ: principais dúvidas sobre erros do Windows Update no Windows 10 e Windows 11

Depois de analisar códigos, serviços, logs, rede, BITS, Component Store, DISM, drivers, certificados e Windows Setup, podemos responder algumas das dúvidas mais frequentes sobre erros do Windows Update.

Esta FAQ também funciona como consulta rápida para quem chegou ao artigo procurando um problema específico.

Por que o Windows Update apresenta erro mesmo quando a internet funciona normalmente?

Porque navegar na internet e utilizar Windows Update não são exatamente a mesma operação.

O navegador pode funcionar enquanto o Windows Update enfrenta problemas relacionados a:

proxy;
WinHTTP;
TLS;
certificados;
firewall;
VPN;
políticas;
BITS;
Delivery Optimization;
servidores de atualização;
filtros de segurança.

Por isso, abrir um site não prova que todo o caminho utilizado pelo Windows Update está funcionando.

Se aparecer um erro da família:

0x80072xxx

a investigação de comunicação ganha importância.

Um exemplo é:

0x80072EE2

associado a timeout.

Antes de alterar DNS ou resetar a rede inteira, investigue o código e o WindowsUpdate.log.

Por que o Windows Update encontra a atualização, mas não consegue baixar?

Encontrar uma atualização e baixar seu conteúdo são etapas diferentes.

O Windows pode conseguir:

consultar atualizações;
receber metadados;
determinar aplicabilidade;

e falhar depois durante a transferência.

Nesse caso, investigue:

WindowsUpdate.log;
BITS;
Delivery Optimization;
proxy;
VPN;
rede;
espaço disponível;
códigos anteriores à mensagem final.

Um:

0x80240034

por exemplo, pode indicar falha no download, mas outro código registrado anteriormente pode explicar por que o download falhou.

Windows Update fica em “Baixando — 0%”. Significa que o BITS está quebrado?

Não.

O percentual exibido pela interface não representa necessariamente toda a atividade interna naquele instante.

Antes de concluir que o BITS está quebrado, observe:

rede;
disco;
WindowsUpdate.log;
estado dos serviços;
jobs BITS quando aplicável.

Use:

Get-Service bits

e, quando apropriado:

Get-BitsTransfer

O problema também pode estar em:

comunicação;
proxy;
Delivery Optimization;
preparação;
validação;
política.

Windows Update fica em “Instalando — 0%”. Está travado?

Não necessariamente.

Depois do download, o Windows pode estar:

preparando pacotes;
verificando aplicabilidade;
processando componentes;
executando servicing.

Observe:

CPU;
disco;
TrustedInstaller;
TiWorker;
CBS.log.

Se existe atividade e o CBS.log continua recebendo registros relacionados à instalação, interromper serviços pode ser pior do que aguardar.

Existe um tempo máximo normal para uma atualização?

Não existe um número universal que funcione para todos os computadores e todas as atualizações.

O tempo depende de fatores como:

tamanho da atualização;
SSD ou HDD;
CPU;
quantidade de componentes;
estado do Windows;
espaço;
velocidade da conexão;
etapa da atualização.

Em vez de considerar somente o relógio, observe:

tempo + atividade + logs + erros.

Por que a atualização chega a 100% e continua demorando?

Porque 100% em determinada fase não significa necessariamente que todo o processo terminou.

Depois do download, ainda podem existir:

validação;
preparação;
servicing;
commit;
operações pendentes;
preparação para reinicialização.

O mesmo vale para uma instalação que visualmente chegou a 100%.

Por que o Windows Update chega a 100% e depois dá erro?

Isso pode acontecer porque o download foi concluído, mas uma etapa posterior falhou.

Exemplos:

assinatura;
servicing;
Component Store;
dependência;
espaço;
driver;
reinicialização.

Por isso:

100% de download não significa 100% da atualização.

Por que o Windows mostra “Desfazendo alterações”?

Isso geralmente indica que a atualização não conseguiu concluir e o Windows iniciou um rollback.

Depois que o sistema voltar a funcionar, registre:

KB;
código;
horário;
tipo da atualização.

Para uma atualização cumulativa, CBS.log pode ser fundamental.

Para um upgrade de versão, SetupDiag e os logs do Windows Setup ganham importância.

Devo desligar o computador quando aparece “Desfazendo alterações”?

Evite interromper deliberadamente um rollback em andamento.

O Windows pode estar restaurando o estado anterior justamente para voltar a uma condição inicializável.

Depois que o processo terminar, investigue a causa.

Por que o Windows pede para reiniciar várias vezes?

Uma reinicialização pode ser necessária para concluir operações de servicing.

Mas se:

Reinicialização necessária

permanece indefinidamente depois de reinicializações normais, investigue:

Histórico;
CBS.log;
operações pendentes;
atualização que não concluiu.

Não comece apagando pending.xml ou estados do Registro.

Reiniciar e desligar/ligar são exatamente iguais?

Não necessariamente em todos os cenários.

Recursos como Inicialização Rápida podem fazer com que desligamento e inicialização tenham comportamento diferente de uma reinicialização completa.

Para concluir determinadas operações do Windows Update, use a opção:

Reiniciar

quando o próprio Windows solicitar.

Por que a mesma KB aparece novamente?

Existem várias possibilidades:

instalação não concluiu;
rollback;
detecção voltou a considerar a atualização aplicável;
estado de servicing não foi confirmado;
pacote relacionado mudou;
histórico mostra tentativa, mas não instalação efetiva.

Confira:

Histórico de Atualizações

e, quando necessário:

DISM /Online /Get-Packages

Posso usar Get-HotFix para confirmar todas as atualizações?

Não trate Get-HotFix como inventário universal de absolutamente todo conteúdo instalado pelo Windows Update.

Dependendo do tipo de pacote, outras fontes podem ser mais apropriadas.

Use também:

Histórico de Atualizações;
DISM;
build do Windows;
informações específicas do pacote.

Por que o Windows diz “Você está atualizado” quando existe uma versão mais nova?

Porque existir uma versão mais nova não significa automaticamente que ela está sendo oferecida naquele momento para aquele computador.

Podem existir fatores como:

canal;
implantação gradual;
política;
compatibilidade;
requisitos;
safeguard;
gerenciamento corporativo.

Primeiro descubra a versão instalada:

winver

Depois investigue por que a versão desejada não está sendo oferecida.

Devo forçar uma Feature Update que ainda não apareceu?

Não automaticamente.

Primeiro descubra se existe:

incompatibilidade conhecida;
bloqueio de segurança;
requisito não atendido;
política;
implantação gradual.

Forçar sem entender a razão pode transformar uma atualização adiada em um rollback ou problema de compatibilidade.

O que significa 0x80070002?

Em termos gerais, está relacionado a:

arquivo não encontrado.

Mas isso não responde:

qual arquivo?

É necessário descobrir:

fase;
componente;
log;
objeto ausente.

Não transforme 0x80070002 automaticamente em:

“apague SoftwareDistribution”.

O que significa 0x80070005?

É um código relacionado a:

acesso negado.

A pergunta mais importante é:

acesso negado a quê?

Não conceda controle total em pastas do sistema como solução genérica.

O que significa 0x8007000D?

Está associado a dados inválidos.

Dependendo do contexto, investigue:

pacote;
metadados;
manifesto;
conteúdo;
servicing.

O que significa 0x80070070?

Está relacionado a espaço insuficiente.

Mas não presuma que:

C:

é necessariamente o único volume relevante.

Em alguns cenários de upgrade, outras partições podem participar.

Use:

Get-Volume

e, quando necessário:

Get-Partition

Quanto espaço livre o Windows Update precisa?

Não existe um único número correto para qualquer atualização.

A necessidade varia conforme:

tipo de update;
build;
arquivos temporários;
rollback;
Feature Update;
configuração de armazenamento.

O ideal é verificar o espaço exigido pelo cenário específico em vez de aplicar um número mágico.

0x800F0922 significa que a partição EFI está cheia?

Não automaticamente.

Esse código pode aparecer em diferentes contextos de servicing.

Antes de redimensionar qualquer partição, consulte:

CBS.log

e procure evidência que realmente direcione a investigação para armazenamento ou partições.

Modificar EFI sem necessidade é uma intervenção de alto risco.

Posso excluir a partição Recovery para ganhar espaço?

Não como solução genérica.

Primeiro verifique:

reagentc /info

A partição pode estar associada ao Windows Recovery Environment.

Se houver necessidade real de redimensionamento, faça planejamento, backup e identificação correta das partições.

Por que existem duas partições Recovery?

Isso pode acontecer após:

upgrades;
alterações no layout;
histórico do equipamento;
configuração OEM.

A presença de duas partições não significa automaticamente que uma pode ser apagada.

Use:

reagentc /info

para ajudar a identificar a configuração ativa.

O que significa 0x800F081F?

Em contexto de servicing, esse código é associado à ausência de uma fonte/componente necessário para a operação.

Isso pode aparecer em:

DISM;
Windows Update;
Features on Demand;
.NET Framework 3.5.

O passo correto é descobrir:

qual source está faltando e por quê.

Devo executar DISM quando aparece 0x800F081F?

DISM pode fazer parte do diagnóstico e reparo.

Mas se:

DISM /Online /Cleanup-Image /RestoreHealth

também retorna:

0x800F081F

repetir o mesmo comando indefinidamente provavelmente não resolverá.

Pode ser necessário fornecer uma fonte compatível.

Posso usar qualquer ISO como fonte do DISM?

Não é recomendável.

A fonte precisa ser apropriada para o sistema que está sendo reparado.

Verifique:

edição;
arquitetura;
versão;
build;
índice;
tipo de imagem.

Como descubro o índice do install.wim?

Use:

DISM /Get-WimInfo /WimFile:D:\sources\install.wim

Se a mídia utiliza ESD:

DISM /Get-WimInfo /WimFile:D:\sources\install.esd

O que significa /LimitAccess no DISM?

Esse parâmetro altera a forma como o DISM procura conteúdo de reparo, impedindo o uso do Windows Update como origem naquela operação.

Por isso, ele deve ser utilizado entendendo qual fonte será fornecida.

DISM resolve qualquer erro do Windows Update?

Não.

DISM é especialmente útil em problemas relacionados ao servicing e Component Store.

Ele não é a ferramenta principal para:

timeout de rede;
proxy;
certificado raiz;
driver incompatível;
falta de espaço;
política.

Qual a diferença entre SFC e DISM?

Eles trabalham em áreas relacionadas, mas não são equivalentes.

SFC verifica e pode reparar arquivos protegidos do sistema.

DISM pode verificar e reparar a imagem/component store utilizada pelo Windows.

Por isso, em determinados casos, reparar o Component Store com DISM antes de executar SFC pode fazer sentido.

Preciso executar SFC depois de todo erro do Windows Update?

Não.

Se o problema é claramente:

proxy;
timeout;
atualização não aplicável;

SFC provavelmente não é a primeira ferramenta.

Posso executar sfc /scannow várias vezes?

O mais importante é interpretar o resultado.

Repetir comandos sem entender o que ocorreu não substitui diagnóstico.

O que significa 0x80073712?

Esse código direciona fortemente a investigação para problemas no Component Store.

Use:

DISM /Online /Cleanup-Image /CheckHealth

DISM /Online /Cleanup-Image /ScanHealth

Além de analisar:

CBS.log.

Posso apagar WinSxS?

Não.

Não faça limpeza manual em:

C:\Windows\WinSxS

Para análise e manutenção suportada, use DISM.

Por que WinSxS parece tão grande?

O tamanho aparente pode ser influenciado pela forma como o Windows utiliza hard links e mantém componentes necessários para servicing.

Use:

DISM /Online /Cleanup-Image /AnalyzeComponentStore

para uma avaliação mais apropriada.

Posso apagar SoftwareDistribution?

Reconstruir SoftwareDistribution pode ser útil em determinados problemas de cache/download/metadata.

Mas não deve ser a primeira solução para qualquer erro.

Quando tecnicamente justificado, prefira inicialmente renomear a pasta depois de parar os serviços necessários.

Apagar SoftwareDistribution remove minhas atualizações instaladas?

A pasta está relacionada à infraestrutura local do Windows Update e seu conteúdo não equivale simplesmente a “desinstalar todas as atualizações”.

Mesmo assim, reconstruí-la altera estado/cache local e pode afetar informações exibidas pela interface.

Por isso, não faça sem necessidade.

Posso apagar catroot2?

A reconstrução de catroot2 pode fazer parte de procedimentos específicos.

Não deve ser usada como ritual para todo erro.

E nunca confunda:

catroot

com:

catroot2.

SoftwareDistribution e catroot2 devem sempre ser resetadas juntas?

Não.

Elas participam de funções diferentes.

A decisão deve depender da camada problemática.

O que significa 0x80072EE2?

Está associado a timeout.

Investigue:

rede;
proxy;
VPN;
caminho de comunicação;
infraestrutura.

Não conclua automaticamente que é DNS.

Trocar DNS resolve Windows Update?

Pode resolver um problema que realmente seja de resolução DNS.

Mas não é solução universal.

Antes de trocar, confirme se DNS está relacionado ao erro.

Desativar IPv6 pode resolver?

Existem problemas específicos em que investigar IPv6 faz sentido.

Mas desabilitá-lo indiscriminadamente não é uma boa prática.

Primeiro identifique a falha.

Resetar Winsock resolve?

Pode ser útil para determinados problemas da pilha de rede.

Não corrige:

Component Store;
driver;
espaço;
certificado;
servicing.

Por que navegador funciona e Windows Update não?

Porque podem existir diferenças em:

proxy;
contexto;
serviço;
APIs;
autenticação;
filtros;
políticas.

“Google abre” não elimina uma falha específica de comunicação do Windows Update.

O que significa 0x80240034?

Indica falha relacionada ao download da atualização.

Mas procure códigos anteriores.

Se antes aparece:

0x80072EE2

por exemplo, o timeout pode explicar por que o download falhou.

O que significa 0x80240017?

Indica que a atualização não é aplicável ao sistema naquele contexto.

Verifique:

versão;
build;
edição;
arquitetura;
pré-requisitos;
supersedência.

Não force a instalação antes de confirmar a aplicabilidade.

Por que o Windows Update oferece drivers?

O Windows Update também pode distribuir pacotes de drivers compatíveis com dispositivos do computador.

Eles podem ser:

automáticos;
opcionais;
parte de processos de atualização.

Windows Update pode instalar um driver diferente do fabricante?

Sim, dependendo da aplicabilidade e do pacote disponível.

Mas “mais novo” e “melhor” não são sinônimos.

Fabricantes de computadores também podem fornecer drivers personalizados para determinados modelos.

Devo instalar todos os drivers opcionais?

Não necessariamente.

Um driver opcional pode ser útil quando existe um problema que ele resolve.

Não é obrigatório instalar tudo apenas porque está listado.

O que significa 0xC1900101?

Em upgrades de versão, essa família é frequentemente associada a rollback envolvendo drivers.

Mas não conclua:

“é o driver de vídeo”.

Use:

SetupDiag;
Setup logs;
setupapi.dev.log;
inventário de drivers.

Preciso atualizar todos os drivers quando aparece 0xC1900101?

Não.

Tente identificar o dispositivo ou driver relacionado à falha.

Atualizar tudo de uma vez dificulta o diagnóstico e pode introduzir novos problemas.

Devo usar programas de atualização automática de drivers?

Prefira fontes confiáveis e identificação específica do hardware.

Ferramentas genéricas podem sugerir pacotes inadequados ou desnecessários.

Posso apagar DriverStore?

Não manualmente.

Use ferramentas suportadas como PnPUtil quando existir necessidade real de administrar pacotes de drivers.

O que é setupapi.dev.log?

É um log importante para instalação e configuração de dispositivos e drivers.

Caminho:

C:\Windows\INF\setupapi.dev.log

Ele é especialmente útil quando Windows Update ou Windows Setup encontra problemas relacionados a hardware e drivers.

O que é CBS.log?

CBS.log registra informações do Component-Based Servicing.

Caminho:

C:\Windows\Logs\CBS\CBS.log

É um dos logs mais importantes para:

atualizações cumulativas;
servicing;
Component Store;
.NET Framework;
Features on Demand.

O que é DISM.log?

É o log associado às operações executadas pelo DISM.

Caminho:

C:\Windows\Logs\DISM\dism.log

Quando DISM falha, ele deve ser analisado em conjunto com o contexto e, muitas vezes, CBS.log.

O que é WindowsUpdate.log?

É uma representação legível de eventos relacionados ao Windows Update que pode ser gerada em versões modernas do Windows usando:

Get-WindowsUpdateLog

Ele ajuda a investigar:

detecção;
download;
agente;
resultados.

Qual log devo abrir primeiro?

Depende da fase.

Busca/download

WindowsUpdate.log.

Instalação cumulativa

CBS.log.

DISM

DISM.log + CBS.log.

Feature Update

SetupDiag + Setup logs.

Driver

setupapi.dev.log.

Certificado

CAPI2.

Como descobrir o erro real quando só aparece “Falha na instalação”?

Anote o horário exato da falha.

Depois identifique:

KB;
fase;
log correspondente.

Procure os eventos próximos daquele horário.

O erro exibido pela interface pode ser apenas o resultado final de uma falha anterior.

O primeiro “Error” do log é sempre a causa?

Não.

Logs podem conter:

tentativas;
falhas recuperáveis;
erros secundários;
eventos de outras operações.

Correlacione:

horário + atualização + componente + código.

O último erro do log é sempre a causa?

Também não.

Durante rollback, por exemplo, novos erros podem aparecer depois da falha original.

A causa pode estar alguns segundos ou minutos antes.

O que é SetupDiag?

SetupDiag é utilizado para analisar informações do Windows Setup e ajudar a identificar motivos de falhas em upgrades.

É particularmente útil quando uma atualização de versão:

instala;
reinicia;
falha;
volta para a versão anterior.

Posso apagar $WINDOWS.~BT?

Não faça isso antes de concluir a investigação de uma falha de upgrade.

A pasta pode conter logs importantes do Windows Setup.

Posso apagar Windows.old?

Antes de remover, considere:

necessidade de rollback;
arquivos;
investigação;
espaço.

Não trate Windows.old apenas como “lixo”.

O que significa 0x800B0109?

Esse código está associado a uma cadeia de certificados que termina em uma raiz não confiável.

Investigue:

certificados;
cadeia;
CAPI2;
ambiente corporativo;
inspeção HTTPS.

Não instale certificados aleatórios.

O que significa 0x80096010?

Está relacionado à falha de verificação de digest/assinatura.

Investigue qual arquivo ou pacote não passou pela validação.

Data e hora erradas podem impedir atualizações?

Podem interferir em determinados processos de comunicação segura e validação.

Confira:

Get-Date

w32tm /query /status

Mas não atribua todo erro de certificado automaticamente ao relógio.

Posso desativar verificação de certificados para instalar a atualização?

Não é uma boa solução.

O correto é identificar por que a validação falhou.

Reduzir a segurança pode criar um problema muito maior.

O que significa 0x800F0954 ao instalar .NET Framework 3.5?

Esse código aparece com frequência em cenários nos quais a obtenção do conteúdo necessário é afetada pela origem/política do sistema, especialmente em ambientes gerenciados.

Investigue:

Features on Demand;
source;
políticas;
WSUS;
CBS.

Não comece apagando chaves de Registro.

Instalar o .NET moderno corrige o .NET Framework?

Não necessariamente.

.NET moderno e .NET Framework são tecnologias relacionadas historicamente, mas não são substitutos diretos em todos os cenários.

Uma aplicação que exige determinado componente do .NET Framework pode continuar dependendo dele.

Por que o .NET Framework 3.5 pede arquivos da mídia do Windows?

Porque ele pode depender de conteúdo de recurso opcional que não esteja completamente disponível localmente.

Uma fonte compatível pode ser necessária dependendo da configuração.

O Windows Update pode falhar por causa do SSD?

Pode existir problema de armazenamento, mas um erro do Windows Update sozinho não prova defeito físico no SSD.

Procure evidências adicionais:

erros de leitura;
filesystem;
SMART;
eventos;
comportamento geral do sistema.

Disco em 100% significa SSD cheio?

Não.

100% de atividade

100% de capacidade ocupada

são conceitos diferentes.

Um disco pode ter bastante espaço livre e estar em 100% de tempo ativo.

CHKDSK resolve Windows Update?

CHKDSK pode ajudar quando existe problema relacionado ao filesystem.

Não é solução para todos os erros do Windows Update.

Preciso formatar o computador?

Na maioria dos erros isolados, formatação não deve ser o primeiro passo.

Antes, investigue:

código;
fase;
logs;
rede;
servicing;
drivers;
espaço.

Quando considerar reparo in-place?

Quando existe corrupção sistêmica significativa que não foi corrigida por procedimentos suportados mais específicos.

Um reparo in-place pode ser uma alternativa intermediária entre pequenos reparos e instalação limpa.

Repair install e formatação são a mesma coisa?

Não.

Uma instalação de reparo pode, dependendo do método e das condições, preservar aplicativos, arquivos e configurações.

Uma instalação limpa reconstrói o Windows de forma muito mais ampla.

Quando uma instalação limpa faz sentido?

Pode ser considerada quando:

corrupção é extensa;
reparos suportados falharam;
existem múltiplos problemas;
o usuário deseja reconstruir o sistema;
backup foi realizado.

Mesmo assim, tente compreender se a causa pode reaparecer depois.

É seguro usar scripts de “Reset Windows Update”?

Depende exatamente do que o script faz.

Nunca execute um script administrativo apenas porque o nome diz:

Windows Update Repair.

Leia os comandos.

Verifique se ele:

altera serviços;
remove arquivos;
muda Registro;
redefine rede;
altera permissões;
desabilita segurança.

Quanto mais alterações simultâneas, mais difícil fica entender o resultado.

Qual é a melhor forma de diagnosticar Windows Update?

Use uma sequência consistente:

registre o sintoma;
copie o código;
identifique a KB;
anote o horário;
determine a fase;
identifique a família do erro;
escolha o log correto;
encontre a evidência;
formule uma hipótese;
faça a menor alteração necessária;
tente novamente;
valide o resultado.

Conclusão: Windows Update não deve ser diagnosticado por tentativa e erro

Depois de percorrer todas as famílias deste guia, fica claro por que não existe um único comando capaz de corrigir todos os problemas do Windows Update.

Um computador pode apresentar:

0x80072EE2

porque a comunicação sofreu timeout.

Outro pode apresentar:

0x800F081F

porque o servicing não encontrou o conteúdo necessário.

Outro:

0x80073712

por problema no Component Store.

Outro:

0xC1900101

durante um upgrade envolvendo driver.

E outro pode simplesmente estar sem espaço no volume necessário.

Todos aparecem para o usuário como:

“Windows Update não funciona”.

Tecnicamente, porém, são problemas completamente diferentes.

A melhor estratégia é abandonar a lógica:

“qual comando corrige Windows Update?”

e substituí-la por:

“em qual camada a atualização falhou?”

Quando encontramos essa resposta, ferramentas como:

WindowsUpdate.log;
CBS.log;
DISM.log;
SetupDiag;
SetupAPI;
Event Viewer;
PnPUtil;
BITS;
DISM;

deixam de ser uma coleção de comandos e passam a formar um processo de diagnóstico.

Precisa de ajuda com erros do Windows Update em São Paulo?

A VMIA – Manutenção e Configuração realiza diagnóstico de computadores e notebooks Windows, incluindo problemas relacionados a:

Windows Update;
erros de atualização;
Windows 10 e Windows 11;
drivers;
Component Store;
DISM e SFC;
atualizações que não instalam;
atualizações que fazem rollback;
problemas de rede;
Wi-Fi;
impressoras;
lentidão;
vírus e adware;
backup e recuperação de dados sem dano físico;
configuração e manutenção de computadores.

O atendimento pode ser realizado por acesso remoto quando o problema permitir ou por visita técnica agendada.

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

O objetivo do diagnóstico não é executar o maior número possível de comandos.

É descobrir:

onde a falha começou, por que aconteceu e qual é a menor correção necessária para fazer o Windows Update funcionar novamente.

VMIA - MANUTENÇÃO E CONFIGURAÇÃO

57 avaliações no Google

Escreva sua avaliação

Sophie Helena Moussa Ianni Assumpção

Excelente profissional e atencioso

Vinicius Nery

Competente, honesto e rapido.

Lauren Baggio

Excelente profissional, atende rapidamente ao chamado e entende profundamente o assunto!

Luzia Bacheschi

O Victor é muito profissional, explica tudo em detalhes e foi super resolutivo na ajuda remota que me prestou. Recomendo seus serviços e certamente já se tornou meu técnico de confiança para qualquer futura eventualidade.

Jaime Albuquerque

Excelente atendimento, rápido e atencioso. Recomendo os serviços.

Felipe Caldeira Goncalez

"Quero parabenizar a VMIA por seu grande desempenho em todos os projetos realizados. É uma satisfação estar aqui dando depoimento sobre uma empresa tão séria como a VMIA. Qualidade, profissionalismo, confiabilidade, seriedade e muito, muito mais. Agradeço a excelência do trabalho desempenhado. É por isso que sempre buscamos e confiamos na VMIA, ela está muito a frente dos novos avanços e sempre caminha proativamente. Mais uma vez, muito obrigado. Sucesso!"

Marcio Assumpção

Excelente serviço com ótimos profissionais!