Você abre:
Configurações → Windows Update
O Windows encontra uma atualização.
O download aparentemente acontece normalmente.
Depois, a tela muda para algo semelhante a:
Instalando — 0%
Você espera.
Cinco minutos.
Dez minutos.
Vinte minutos.
A porcentagem continua:
0%.
Nesse momento surge uma pergunta bastante comum:
o Windows Update travou?
A resposta não deve ser dada olhando apenas para a porcentagem.
Uma atualização aparentemente parada em 0% pode representar situações completamente diferentes.
O Windows pode estar:
- processando arquivos;
- verificando pacotes;
- preparando componentes;
- trabalhando no Component Store;
- aguardando outra operação;
- executando tarefas de servicing;
- utilizando CPU e disco intensamente;
- ou realmente enfrentando uma falha.
Por isso, o objetivo deste guia não será ensinar um “comando mágico” para fazer a porcentagem sair de zero.
Vamos responder a uma pergunta mais importante:
o que o Windows está fazendo enquanto a interface mostra 0%?
Essa diferença muda completamente o diagnóstico.
0% não significa necessariamente ausência de atividade
Esse é o conceito mais importante deste artigo.
A porcentagem apresentada pelo Windows Update é uma representação simplificada do processo.
Ela não deve ser interpretada como um medidor perfeito de cada operação interna.
Podemos ter:
Instalando — 0%
enquanto o computador apresenta:
- atividade de CPU;
- leitura e gravação no SSD;
- atividade de
TiWorker.exe; - atividade relacionada ao Windows Modules Installer;
- alterações nos logs;
- processamento de pacotes.
Portanto:
porcentagem parada ≠ sistema necessariamente parado.
O erro de diagnóstico mais comum
Imagine o seguinte cenário:
Windows Update:
Instalando — 0%
Usuário:
“Travou.”
Então começa uma sequência:
- reinicia o computador;
- encerra processos;
- para serviços;
- apaga SoftwareDistribution;
- renomeia catroot2;
- executa DISM;
- executa SFC;
- instala a KB manualmente.
Tudo isso antes de descobrir se realmente existia um problema.
Essa abordagem pode destruir justamente as evidências que ajudariam a entender o comportamento.
Primeiro classifique o seu 0%
Neste artigo vamos dividir o problema em três grandes cenários.
Cenário A — 0% com atividade
A interface não avança, mas:
- CPU trabalha;
- SSD trabalha;
- logs continuam recebendo registros;
- processos de servicing aparecem ativos.
Aqui pode existir processamento legítimo.
Cenário B — 0% praticamente sem atividade
A porcentagem não muda e:
- CPU está praticamente ociosa;
- disco não apresenta atividade relevante;
- logs não mostram progressão relacionada;
- estado permanece igual durante longo período.
Agora a hipótese de bloqueio ou falha ganha importância.
Cenário C — 0% acompanhado de erro
O Windows:
- permanece em 0%;
- depois apresenta código;
- volta para tentar novamente;
- registra falha;
- ou apresenta comportamento repetitivo.
Esse é o cenário mais interessante para diagnóstico por logs.
Antes de qualquer comando, identifique a atualização
Abra:
Configurações → Windows Update
Veja qual atualização está sendo instalada.
Anote:
- nome;
- KB, quando disponível;
- tipo;
- horário;
- porcentagem.
Exemplo:
KBxxxxxxx
Não precisamos adivinhar depois.
Registre o horário
Exemplo:
14:05 — download terminou
14:06 — apareceu Instalando 0%
14:16 — continua em 0%
14:26 — continua em 0%
Essa pequena linha do tempo será extremamente útil.
Por que o horário importa?
Porque posteriormente podemos comparar esse período com:
- WindowsUpdate.log;
- CBS.log;
- Gerenciador de Tarefas;
- Monitor de Recursos;
- Visualizador de Eventos.
Sem uma janela temporal, podemos acabar analisando erros antigos sem qualquer relação com a atualização atual.
Não determine um tempo universal para declarar travamento
Evite regras como:
“se ficar dez minutos em 0%, travou”.
ou:
“depois de meia hora pode reiniciar”.
O tempo necessário depende de vários fatores.
Entre eles:
- atualização;
- desempenho do processador;
- velocidade do armazenamento;
- estado do Windows;
- quantidade de componentes envolvidos;
- operações concorrentes;
- condição do sistema.
O relógio sozinho não diagnostica o problema.
O comportamento do computador importa mais que o cronômetro
Compare:
Computador A
Está há 20 minutos em 0%.
Mas:
- CPU apresenta atividade;
- SSD trabalha;
- TiWorker está ativo;
- CBS.log continua mudando.
Computador B
Está há 20 minutos em 0%.
Mas:
- CPU ociosa;
- SSD ocioso;
- nenhuma progressão aparente;
- mesmo erro reaparece nos logs.
Os dois mostram:
0%.
Mas tecnicamente são situações diferentes.
Primeiro diagnóstico: Gerenciador de Tarefas
Pressione:
Ctrl + Shift + Esc
Abra:
Gerenciador de Tarefas
Observe:
- CPU;
- Disco;
- Memória;
- Rede.
Não procure apenas um número alto.
Queremos observar o comportamento ao longo de alguns minutos.
O disco está trabalhando?
Se existe atividade significativa de leitura ou gravação, pergunte:
qual processo está realizando essa atividade?
Não conclua automaticamente que é Windows Update.
CPU está trabalhando?
Observe os processos.
Podem aparecer componentes relacionados ao servicing.
Um deles pode ser:
TiWorker.exe
O que é TiWorker.exe?
TiWorker.exe está associado ao Windows Modules Installer Worker.
Ele pode participar de operações relacionadas à manutenção e servicing de componentes do Windows.
Durante atualizações, sua atividade pode ser legítima.
TiWorker usando CPU significa que o Windows Update está funcionando?
Não necessariamente.
É uma pista.
Precisamos correlacionar:
- horário;
- atividade;
- logs;
- atualização;
- progressão.
Não encerre TiWorker
Se ele participa de uma operação legítima de servicing, finalizar o processo à força não constitui reparação.
Primeiro descubra o que está acontecendo.
TrustedInstaller também pode aparecer
O serviço:
Windows Modules Installer
também participa de operações de componentes.
Podemos consultar:
sc query trustedinstaller
O resultado isolado não define se existe problema.
Ele apenas acrescenta contexto.
TrustedInstaller parado significa falha?
Não.
TrustedInstaller rodando significa que está tudo normal?
Também não.
Precisamos interpretar junto com o restante do diagnóstico.
Use o Monitor de Recursos
Pressione:
Windows + R
Digite:
resmon
Abra a seção relacionada ao disco.
Agora podemos observar com mais detalhes:
- processos;
- leitura;
- gravação;
- arquivos acessados.
O SSD está ativo enquanto a porcentagem continua em zero?
Essa informação é muito mais útil do que simplesmente olhar para:
Instalando — 0%.
Se existe atividade constante, o sistema pode continuar processando a atualização.
Cuidado com SSD rápido
Em computadores modernos, a atividade pode acontecer em rajadas.
Você pode observar:
atividade → pausa → atividade → pausa.
Não espere necessariamente uso constante de 100%.
Disco em 100% também não significa progresso
Outro erro é pensar:
“disco está em 100%, então está instalando normalmente”.
Pode existir:
- antivírus;
- indexação;
- paginação;
- outro programa;
- erro de armazenamento;
- outra tarefa.
Descubra qual processo está gerando a atividade.
E a rede?
Se o Windows já está mostrando:
Instalando
não significa que toda atividade de rede obrigatoriamente terminou.
O processo de atualização possui diferentes etapas e pode ainda precisar realizar operações adicionais.
Mas novamente:
rede ativa não prova progresso da instalação.
Download e instalação não são a mesma coisa
Para o usuário, a sequência parece:
baixou → instala.
Internamente, existem etapas adicionais.
Podemos pensar de maneira simplificada:
detecção
↓
download
↓
verificação
↓
preparação
↓
staging/processamento
↓
servicing
↓
instalação
↓
reinicialização quando necessária
↓
conclusão.
A interface não precisa mostrar uma porcentagem independente para cada etapa.
O que é staging?
De maneira simplificada, podemos pensar no staging como uma etapa em que componentes e pacotes são preparados para que o servicing possa trabalhar com eles.
Não devemos imaginar que:
arquivo baixado = arquivo imediatamente colocado em seu estado final.
Existe processamento entre essas etapas.
Por isso o 0% pode enganar
A interface pode continuar em:
Instalando — 0%
enquanto existe preparação que ainda não se traduz em avanço visível da barra.
É exatamente por isso que não devemos usar a porcentagem como única fonte.
Vamos consultar os logs
Agora começamos a sair da interface gráfica.
Abra o PowerShell.
Execute:
Get-WindowsUpdateLog
O Windows gera uma representação do Windows Update log que pode ser analisada.
Quando gerar o log?
Depois de reproduzir o comportamento.
Por exemplo:
15:10 — começou Instalando 0%
15:25 — ainda 0%
Agora gere:
Get-WindowsUpdateLog
Procure o período correspondente.
Não pesquise somente por “Error”
Esse é um erro frequente.
Um log precisa ser lido como sequência.
Pergunte:
o que aconteceu antes?
qual operação começou?
qual atualização estava envolvida?
o que aconteceu depois?
WindowsUpdate.log responde tudo?
Não.
Quando o diagnóstico entra no servicing de componentes, outro registro se torna extremamente importante.
CBS.log
O arquivo fica em:
C:\Windows\Logs\CBS\CBS.log
CBS significa:
Component-Based Servicing.
Esse registro pode ajudar a compreender operações envolvendo componentes e pacotes.
CBS.log pode continuar mudando enquanto a tela mostra 0%
Essa é uma excelente pista.
Imagine:
Windows Update: 0%
mas:
CBS.log continua registrando novas operações.
Isso mostra que a interface parada não significa necessariamente ausência completa de processamento.
Como acompanhar o log sem se perder?
Use o horário que registramos.
Se o problema começou às:
15:10
não comece analisando mensagens de três dias atrás.
Concentre-se no período relevante.
Procure sequência, não palavras soltas
Uma mensagem contendo:
error
não é automaticamente a causa.
Da mesma maneira:
pending
não significa automaticamente corrupção.
Precisamos identificar:
- pacote;
- horário;
- operação;
- resultado.
Existe código de erro?
Se encontrar algo como:
0xXXXXXXXX
anote exatamente.
Também registre o contexto.
Não pesquise apenas o código sem saber qual operação o produziu.
Consulte os pacotes
Abra o Terminal como administrador.
Execute:
DISM /Online /Get-Packages
Para salvar:
DISM /Online /Get-Packages > "%userprofile%\Desktop\pacotes.txt"
Por que fazer isso enquanto está em 0%?
Queremos construir um retrato do estado do servicing.
Se posteriormente a situação mudar, poderemos comparar.
Não remova pacotes
Neste momento estamos diagnosticando.
Não execute:
DISM /Remove-Package
como tentativa de fazer a porcentagem avançar.
O Histórico de Atualizações também ajuda
Abra:
Configurações → Windows Update → Histórico de atualizações
Veja se existe:
- falha anterior;
- tentativa repetida;
- atualização semelhante;
- driver instalado;
- atualização que exige reinicialização.
Existe reinicialização pendente?
Essa é outra pergunta importante.
Talvez a atualização esteja aguardando a conclusão de uma operação anterior.
Se o Windows já pede reboot por outro motivo, registre isso.
Não reinicie imediatamente
Se existe atividade legítima e não temos evidência de falha, interromper o processo pode ser contraproducente.
Primeiro determine se existe progressão.
Como saber se existe progressão sem porcentagem?
Observe em conjunto:
- CPU;
- disco;
- processos;
- logs;
- estado dos pacotes;
- mudança de mensagens.
Nenhum indicador isolado é perfeito.
Juntos, eles formam um diagnóstico muito melhor.
Crie um pequeno relatório
Exemplo:
Atualização: KBxxxxxxx
Início do 0%: 15:10
15:15: TiWorker ativo
15:20: disco continua com atividade
15:25: CBS.log recebeu novos registros
15:30: ainda 0%
Esse computador não está necessariamente “congelado”.
Agora outro exemplo
Atualização: KBxxxxxxx
Início do 0%: 15:10
15:20: praticamente nenhuma atividade relacionada
15:30: estado igual
15:40: WindowsUpdate.log mostra falha repetida
15:50: mesma operação continua falhando
Aqui temos evidência muito mais forte de problema.
O que não fazer nesta primeira etapa
Enquanto ainda não sabemos se o 0% representa demora ou falha:
Não apague SoftwareDistribution
Ela não deve ser a primeira resposta.
Não renomeie catroot2
Ainda não sabemos se essa camada participa do problema.
Não execute RestoreHealth automaticamente
DISM /Online /Cleanup-Image /RestoreHealth
é uma ferramenta de reparação, não um botão universal de “destravar Windows Update”.
Não execute SFC esperando aumentar a porcentagem
sfc /scannow
tem finalidade específica.
Use quando a hipótese justificar.
Não reinicie compulsivamente
Primeiro determine se existe atividade.
Não encerre TiWorker
Pode existir servicing em andamento.
Não finalize TrustedInstaller
Pelo mesmo motivo.
Não instale a KB manualmente ainda
Primeiro descubra por que o fluxo automático está parado.
Não execute script de “Reset Windows Update”
Principalmente scripts que modificam várias camadas ao mesmo tempo.
O diagnóstico correto começa com três perguntas
Quando Windows Update mostra:
Instalando — 0%
pergunte:
1. Existe atividade?
CPU, disco, processos e logs.
2. Existe progressão?
Mesmo que a porcentagem não mude, os registros e estados estão avançando?
3. Existe erro?
Há uma falha reproduzível, código ou operação que se repete?
Essas três perguntas determinam o próximo passo.
Primeiro mapa de decisão
Instalando — 0%
↓
Existe atividade relacionada?
Sim
↓
Observe progressão e logs antes de interferir.
Não
↓
Verifique logs, estados e possíveis bloqueios.
Existe erro?
Sim
↓
Investigue o código e a operação correspondente.
Não
↓
Não invente uma falha apenas porque a porcentagem não mudou.
Windows Update em 0% com atividade: como saber se a atualização ainda está trabalhando?
Na Parte 1 estabelecemos uma regra importante:
Windows Update em 0% não significa automaticamente Windows Update travado.
Agora vamos analisar um cenário bastante comum:
Windows Update: Instalando — 0%
mas o computador apresenta:
- CPU em atividade;
- SSD trabalhando;
- TiWorker.exe ativo;
- TrustedInstaller aparecendo;
- CBS.log recebendo registros;
- alterações no estado dos pacotes.
A pergunta passa a ser:
essa atividade pertence realmente à atualização?
Porque simplesmente encontrar CPU ou disco em uso também não prova que o Windows Update está avançando.
Atividade não é sinônimo de progresso
Precisamos separar dois conceitos.
Atividade
Algum processo está utilizando recursos.
Progresso
A operação que estamos investigando está avançando para um novo estado.
Essa diferença é fundamental.
Um computador pode permanecer muito ocupado e, mesmo assim, a atualização continuar repetindo a mesma operação.
Um exemplo
Imagine:
16:00 — Instalando 0%
16:10 — TiWorker usando CPU
16:20 — TiWorker continua usando CPU
16:30 — TiWorker continua usando CPU
Isso prova que houve progresso?
Não.
Precisamos descobrir se o servicing:
- avançou;
- processou novos componentes;
- mudou estados;
- ou repetiu a mesma falha.
Precisamos observar mudanças ao longo do tempo
Em vez de tirar uma fotografia do sistema, crie uma sequência.
Por exemplo:
Momento A
16:05
Momento B
16:15
Momento C
16:25
Compare o comportamento.
Comece pelo Gerenciador de Tarefas
Pressione:
Ctrl + Shift + Esc
Observe:
- CPU;
- Disco;
- Memória;
- Rede.
Não fique olhando apenas a porcentagem total.
Expanda os processos e identifique quem está consumindo recursos.
TiWorker.exe está ativo?
TiWorker.exe pode aparecer durante operações de servicing.
Mas precisamos responder:
ele está realmente trabalhando ou apenas aparece na lista?
Observe o consumo ao longo de alguns minutos.
TiWorker usando CPU em rajadas
Pode ocorrer:
12% → 2% → 18% → 0% → 9%
Esse comportamento pode ser compatível com processamento em etapas.
Não espere necessariamente uma carga constante.
TiWorker parado por alguns segundos não significa travamento
Operações de servicing podem alternar:
- CPU;
- disco;
- espera;
- leitura;
- processamento.
Por isso, uma observação de cinco segundos é insuficiente.
Use o Monitor de Recursos
Execute:
resmon
Abra a seção:
Disco
Localize processos relacionados ao período investigado.
Observe:
- leitura;
- gravação;
- arquivos acessados;
- atividade ao longo do tempo.
O que queremos descobrir?
Não precisamos interpretar cada acesso.
Queremos responder:
há atividade relacionada ao Windows e ao servicing durante o período em que a atualização está em 0%?
O disco pode mostrar 100%
Mas cuidado.
100% de tempo ativo não significa necessariamente alta taxa de transferência.
Um armazenamento pode apresentar alta latência e baixo desempenho enquanto aparece muito ocupado.
Isso muda o diagnóstico
Imagine dois computadores.
Computador A
SSD rápido.
Windows Update permanece 0% por alguns minutos.
CBS continua avançando.
Depois a porcentagem começa a subir.
Computador B
Armazenamento apresenta latência elevada.
Servicing demora muito para processar componentes.
Windows Update permanece em 0% por período maior.
Nesse segundo caso, a interface pode parecer travada, mas a causa pode estar no desempenho da camada de armazenamento.
Não condene o SSD ainda
Uma atualização lenta não é diagnóstico de SSD defeituoso.
Precisamos de evidências adicionais.
Observe a fila e a latência
O Monitor de Recursos pode ajudar a perceber comportamento anormal de armazenamento.
Mas os números precisam ser interpretados no contexto.
Também podem existir:
- Defender;
- indexação;
- paginação;
- backup;
- sincronização;
- outros processos.
Defender pode estar trabalhando junto
Durante mudanças significativas de arquivos, mecanismos de segurança também podem gerar atividade.
Isso pode aumentar:
- CPU;
- disco;
- tempo total.
Não desative o Microsoft Defender apenas para fazer a barra andar.
Desativar segurança não é nosso teste inicial
Se houver evidência concreta de interferência de software de segurança, investigaremos posteriormente.
Mas:
Windows Update em 0% ≠ desative o antivírus.
Verifique o CBS.log em dois momentos
Agora vamos procurar progressão real.
Abra:
C:\Windows\Logs\CBS\CBS.log
Anote o final relevante do arquivo.
Espere alguns minutos.
Consulte novamente.
Existem novas entradas relacionadas?
Se o log continua registrando operações associadas ao período e ao servicing, temos evidência de atividade interna.
Mas ainda precisamos verificar se existe progresso ou repetição.
Progressão no log
Conceitualmente, queremos encontrar algo como:
componente A
↓
componente B
↓
nova etapa
↓
novo pacote
↓
conclusão parcial
Isso sugere avanço.
Repetição no log
Agora imagine:
operação X
↓
erro 0xXXXXXXXX
↓
nova tentativa
↓
operação X
↓
mesmo erro
↓
nova tentativa.
Existe atividade.
Mas talvez não exista progresso.
Esse é o motivo pelo qual CPU alta não basta
O computador pode estar trabalhando intensamente para repetir uma operação que nunca consegue concluir.
Por isso:
atividade + mudança de estado
é muito mais relevante que:
atividade isolada.
Registre códigos de erro
Se houver um código:
0xXXXXXXXX
anote:
- horário;
- código;
- pacote;
- contexto;
- operação.
Não copie apenas o hexadecimal.
Consulte WindowsUpdate.log
No PowerShell:
Get-WindowsUpdateLog
Compare com a mesma janela temporal.
WindowsUpdate.log e CBS.log juntos
Podemos pensar de forma simplificada:
WindowsUpdate.log
ajuda a entender aspectos do fluxo do Windows Update.
CBS.log
ajuda a aprofundar operações do Component-Based Servicing.
Quando o problema ocorre na transição entre interface e servicing, utilizar os dois pode ser muito mais esclarecedor.
Não tente fazer os dois logs dizerem a mesma coisa
Eles possuem finalidades diferentes.
Uma informação pode aparecer com maior detalhe em um deles.
Identifique a KB
Se ainda não registrou, faça isso agora.
Abra:
Windows Update
Anote:
KBxxxxxxx
Quando disponível.
Consulte o Histórico
Abra:
Histórico de atualizações
Veja se já existiram tentativas anteriores da mesma atualização.
A mesma KB falhou ontem?
Essa informação muda bastante o diagnóstico.
Talvez o problema não tenha começado hoje.
Pode existir uma sequência:
tentativa
↓
falha
↓
nova detecção
↓
nova tentativa
↓
0%.
Consulte os pacotes novamente
Terminal como administrador:
DISM /Online /Get-Packages > "%userprofile%\Desktop\pacotes-momento1.txt"
Espere um período razoável enquanto observa a atualização.
Depois:
DISM /Online /Get-Packages > "%userprofile%\Desktop\pacotes-momento2.txt"
Por que duas capturas?
Porque queremos procurar mudança.
Não estamos interessados apenas em:
qual é o estado agora?
Queremos:
o estado está avançando?
Não force uma comparação apenas por tamanho do arquivo
O importante é identificar pacotes relevantes e estados correspondentes.
Existe reinicialização pendente anterior?
Agora precisamos verificar outro cenário.
Talvez a atualização atual não consiga avançar porque outra operação precisa ser finalizada primeiro.
Windows Update já mostrava “Reinicialização necessária”?
Se sim, isso precisa entrar na linha do tempo.
Talvez estejamos tentando instalar:
Atualização B
enquanto:
Atualização A
ainda precisa concluir uma etapa.
Nesse caso, reiniciar pode ser apropriado
Mas faça uma reinicialização normal e controlada.
Antes, salve o trabalho.
Use:
Iniciar → Energia → Reiniciar
Não reinicie no meio de atividade intensa sem necessidade
Se não existe indicação de reboot e os logs mostram progressão, aguarde o processo.
Nosso objetivo não é interromper uma operação legítima apenas porque a interface continua em 0%.
Depois do reboot, compare
Execute:
winver
Abra Windows Update.
Verifique:
- mesma KB?
- mesma porcentagem?
- novo estado?
- erro?
- nova atualização?
Staging pode consumir tempo
Como discutimos anteriormente, o pacote baixado ainda precisa passar por processamento.
O sistema pode preparar componentes antes que a interface represente progresso significativo.
Component Store
O armazenamento de componentes do Windows participa do servicing.
Por isso, quando a instalação permanece em 0% por muito tempo, precisamos considerar o estado dessa estrutura.
Mas ainda não significa corrupção.
Primeiro verifique, depois repare
Comece com:
DISM /Online /Cleanup-Image /CheckHealth
Resultado saudável
Se o mecanismo informa que não existe corrupção detectada nesse estado, registre.
Não execute RestoreHealth apenas para “garantir”.
Quando aprofundar
Se existem indícios de problemas de servicing, execute:
DISM /Online /Cleanup-Image /ScanHealth
Esse processo pode levar algum tempo.
Cuidado com dois processos pesados ao mesmo tempo
Se o Windows Update está ativamente processando uma grande atualização, iniciar outras operações intensivas sem necessidade pode tornar o ambiente mais difícil de interpretar.
Sempre que possível, faça testes de forma controlada.
Não execute todos os comandos simultaneamente
Evite abrir vários terminais e executar ao mesmo tempo:
DISM /ScanHealth
sfc /scannow
chkdsk
e outros procedimentos.
Você quer diagnóstico, não competição por recursos.
Se ScanHealth encontra corrupção
Agora temos evidência.
Podemos considerar:
DISM /Online /Cleanup-Image /RestoreHealth
Depois confirme novamente o estado.
RestoreHealth não é acelerador de Windows Update
Ele não existe para fazer:
0% → 10%.
Sua função é outra.
Só entra quando a hipótese de integridade justifica.
SFC também não é acelerador
sfc /scannow
pode ser útil para verificar arquivos protegidos do sistema.
Mas não o execute apenas porque a barra parece lenta.
E se Component Store estiver saudável?
Excelente.
Eliminamos ou enfraquecemos uma hipótese.
Agora continue procurando:
- dependência;
- atualização anterior;
- driver;
- espaço;
- armazenamento;
- erro específico;
- cache/estado local;
- software interferindo.
Espaço livre merece verificação
Abra:
Configurações → Sistema → Armazenamento
Ou no PowerShell:
Get-Volume
Observe o volume do sistema.
Não existe um número mágico universal
Evite:
“se tiver menos de X GB, Windows Update trava em 0%”.
O espaço necessário depende da atualização e do estado do sistema.
Mas um volume quase cheio merece atenção.
O Windows pode precisar de espaço temporário
A atualização não precisa apenas guardar o arquivo baixado.
Existem operações temporárias e de servicing.
Por isso, o tamanho informado de uma atualização não deve ser interpretado como todo o espaço que o processo poderá utilizar.
Libere espaço de maneira segura
Utilize:
Configurações → Sistema → Armazenamento → Arquivos temporários
Revise cuidadosamente as categorias.
Não marque itens pessoais sem entender o que será removido.
Não apague WinSxS
Nunca tente liberar espaço apagando manualmente:
C:\Windows\WinSxS
Não apague arquivos do Windows Update manualmente enquanto há atividade
Se o sistema está processando uma atualização, não comece a remover arquivos de suas estruturas internas.
Drivers também podem participar
Algumas atualizações de driver aparecem pelo Windows Update.
Veja o Histórico de Atualizações.
Se existe driver envolvido, anote:
- dispositivo;
- versão;
- data;
- resultado.
PnPUtil pode ajudar
Execute:
pnputil /enum-drivers
Para salvar:
pnputil /enum-drivers > "%userprofile%\Desktop\drivers.txt"
Não atualize todos os drivers para “destravar”
Isso adiciona novas variáveis.
Se existe um driver suspeito, investigue aquele driver.
Atualizações concorrentes
O Windows Update pode estar lidando com mais de um item.
Observe se aparecem:
- cumulativa;
- .NET;
- Defender;
- driver;
- componente;
- atualização opcional.
Qual deles está em 0%?
Não assuma que todos pertencem à mesma operação.
Registre cada item.
Uma atualização pode depender de outra etapa
Por isso, um item aparentemente parado pode estar aguardando a conclusão de outra operação.
A fila precisa ser analisada como conjunto.
O serviço Windows Update
Podemos consultar:
sc query wuauserv
Também:
sc query bits
e:
sc query cryptsvc
Serviço parado significa problema?
Não automaticamente.
Alguns serviços podem iniciar conforme a necessidade.
Não mude todos para:
Automático
apenas porque encontrou um deles parado.
Não existe receita “todos os serviços precisam estar Running”
O estado precisa ser interpretado no momento da operação.
E SoftwareDistribution?
Ainda não chegamos à conclusão de que precisamos reconstruí-la.
Se os logs mostram progressão, não mexa.
Se mais tarde identificarmos inconsistência no estado local do Windows Update, ela entrará na árvore de reparação.
E catroot2?
Mesma regra.
Não transforme procedimentos específicos em ritual.
Como classificar o 0% com atividade
Depois dessa investigação, podemos separar:
Tipo 1 — 0% com progressão
- logs avançam;
- operações mudam;
- disco/CPU trabalham;
- não existe erro repetitivo.
Conduta: aguardar e acompanhar.
Tipo 2 — 0% com atividade, mas sem progressão
- CPU/disco trabalham;
- mesma operação se repete;
- mesmo erro reaparece;
- estado relevante não muda.
Conduta: investigar a falha repetitiva.
Tipo 3 — 0% com gargalo de recursos
- armazenamento muito ocupado;
- outros processos competem;
- servicing avança lentamente.
Conduta: identificar o gargalo antes de interferir no Windows Update.
Tipo 4 — 0% aguardando outra operação
- reboot pendente;
- outro pacote em processamento;
- atualização anterior ainda precisa finalizar.
Conduta: resolver a dependência identificada.
Tipo 5 — 0% com Component Store problemático
- DISM detecta corrupção;
- CBS apresenta evidências compatíveis.
Conduta: reparar a camada correta.
Um método simples de observação
Crie uma tabela:
| Horário | Windows Update | CPU | Disco | TiWorker | CBS | Erro |
|---|---|---|---|---|---|---|
| 16:00 | 0% | ativo | ativo | sim | avançando | não |
| 16:10 | 0% | ativo | ativo | sim | avançando | não |
| 16:20 | 0% | moderado | ativo | sim | avançando | não |
| 16:30 | 8% | ativo | ativo | sim | avançando | não |
Nesse caso, ficou evidente que:
a interface ficou em 0%, mas o processo não estava parado.
Agora compare:
| Horário | Windows Update | CPU | Disco | TiWorker | CBS | Erro |
|---|---|---|---|---|---|---|
| 16:00 | 0% | ativo | ativo | sim | operação X | 0xXXXXXXXX |
| 16:10 | 0% | ativo | ativo | sim | operação X | 0xXXXXXXXX |
| 16:20 | 0% | ativo | ativo | sim | operação X | 0xXXXXXXXX |
| 16:30 | 0% | ativo | ativo | sim | operação X | 0xXXXXXXXX |
Agora temos:
atividade sem progressão.
Essa diferença é o centro do diagnóstico.
Windows Update em “Instalando — 0%” sem progresso: onde procurar o bloqueio?
Nas duas primeiras partes fizemos uma distinção fundamental.
Um Windows Update mostrando:
Instalando — 0%
pode estar trabalhando normalmente por trás da interface.
Por isso verificamos:
- CPU;
- disco;
- TiWorker.exe;
- TrustedInstaller;
- CBS.log;
- WindowsUpdate.log;
- pacotes;
- Component Store;
- espaço disponível.
Agora vamos considerar outro cenário.
A atualização permanece em:
0%
e as evidências sugerem que a operação deixou de progredir.
Não estamos falando simplesmente de uma barra que demorou alguns minutos para mudar.
Temos um comportamento reproduzível:
- mesma atualização;
- mesma etapa;
- pouca ou nenhuma progressão;
- logs sem avanço útil ou com falha repetitiva;
- estado que permanece igual.
Agora podemos procurar o bloqueio.
Primeiro: não resete nada ainda
Mesmo neste ponto, não devemos começar apagando componentes.
Antes, precisamos responder:
em qual camada o processo parou?
Podemos dividir a investigação em:
- serviço;
- estado local;
- pacote;
- conectividade;
- política;
- servicing;
- integridade;
- armazenamento;
- interferência externa.
Vamos testar uma camada de cada vez.
Etapa 1 — Verifique o serviço Windows Update
Abra o Terminal como administrador.
Execute:
sc query wuauserv
Esse comando consulta o serviço relacionado ao Windows Update.
O serviço está parado?
Isso sozinho não prova defeito.
O Windows utiliza diferentes comportamentos de inicialização de serviços.
Não transforme:
STOPPED
em:
“achei o problema”.
O serviço apresenta erro ao iniciar?
Agora temos algo mais interessante.
Se houver uma falha reproduzível ao tentar executar uma operação necessária, registre o erro.
Não altere automaticamente para “Automático”
Existem muitos tutoriais que recomendam:
services.msc → Windows Update → Automático
como solução universal.
Não faça isso sem necessidade.
O Windows moderno gerencia diferentes serviços de acordo com o funcionamento previsto do sistema.
Consulte BITS
Execute:
sc query bits
BITS significa:
Background Intelligent Transfer Service.
Ele pode participar de transferências utilizadas por componentes do Windows.
BITS parado também não significa automaticamente falha
Novamente:
estado isolado não basta.
Precisamos saber se existe uma operação tentando utilizá-lo e falhando.
Consulte Cryptographic Services
Execute:
sc query cryptsvc
Esse serviço participa de operações relacionadas à infraestrutura criptográfica utilizada pelo Windows.
O objetivo desses três comandos
Não é exigir:
RUNNING
em todos.
É descobrir se existe:
- falha;
- serviço indisponível;
- comportamento incompatível com a operação;
- erro correspondente nos registros.
Verifique também TrustedInstaller
Execute:
sc query trustedinstaller
Agora temos uma visão inicial de diferentes componentes envolvidos no processo.
Não altere quatro serviços ao mesmo tempo
Se você mudar:
- wuauserv;
- BITS;
- cryptsvc;
- TrustedInstaller;
simultaneamente, perde a capacidade de saber qual alteração realmente teve efeito.
Diagnóstico técnico exige controle de variáveis.
Etapa 2 — Gere novamente WindowsUpdate.log
No PowerShell:
Get-WindowsUpdateLog
Agora queremos olhar especificamente o período em que o sistema permaneceu sem progresso.
Perguntas para o log
Não procure apenas:
Error.
Pergunte:
- a atualização foi detectada?
- o pacote foi obtido?
- existe tentativa repetitiva?
- existe falha?
- existe código?
- existe uma nova tentativa automática?
- a operação chegou a outra camada?
Se houver código de erro
Anote:
0xXXXXXXXX
junto com:
- horário;
- KB;
- operação;
- contexto.
Não procure o código sozinho
Pesquise posteriormente algo mais específico, por exemplo:
código + Windows Update + operação
e não apenas:
0xXXXXXXXX
Isso reduz interpretações erradas.
Etapa 3 — CBS.log
Abra:
C:\Windows\Logs\CBS\CBS.log
Use a mesma janela temporal.
WindowsUpdate.log mostra que o pacote avançou para servicing?
Se sim, o problema pode estar mais abaixo na cadeia.
Agora CBS ganha importância.
CBS repete a mesma falha?
Essa é uma evidência muito útil.
Por exemplo:
tentativa
↓
falha
↓
nova tentativa
↓
mesma falha.
Agora não temos simplesmente:
0%.
Temos uma operação específica que não consegue avançar.
Etapa 4 — Verifique se existe reboot pendente
Antes de resetar componentes, confirme se existe uma operação anterior aguardando reinicialização.
Abra Windows Update.
Observe se existe:
Reinicialização necessária
ou outro aviso relacionado.
Se houver reboot necessário
Salve seu trabalho.
Utilize:
Iniciar → Energia → Reiniciar
Depois retorne ao Windows Update.
A instalação avançou?
Se sim, a operação anterior provavelmente participava do bloqueio.
Registre o resultado.
Continua em 0%?
Agora prossiga.
Etapa 5 — Verifique o espaço disponível
PowerShell:
Get-Volume
Observe o volume do sistema.
Também consulte:
Configurações → Sistema → Armazenamento
O volume está praticamente cheio?
Isso merece correção.
Mas libere espaço utilizando métodos seguros.
Arquivos temporários
Abra:
Configurações → Sistema → Armazenamento → Arquivos temporários
Revise cada categoria.
Não marque itens pessoais sem entender o conteúdo.
Não limpe WinSxS manualmente
Nunca utilize:
C:\Windows\WinSxS
como uma pasta de arquivos temporários.
Etapa 6 — Verifique proxy
No Terminal:
netsh winhttp show proxy
Por que proxy entra aqui?
Em alguns ambientes, configurações de proxy podem influenciar a comunicação utilizada por componentes do sistema.
Mas:
Windows Update em 0% não significa proxy errado.
Estamos apenas verificando quando o restante do diagnóstico sugere problema de comunicação.
Existe proxy configurado?
Se o computador pertence a uma empresa ou ambiente administrado, não altere sem saber por que ele existe.
Pode ser uma configuração intencional.
Computador doméstico com proxy inesperado
Agora vale investigar a origem.
Mas não resete antes de documentar.
Etapa 7 — VPN
Se o computador está conectado a uma VPN, registre.
Um teste controlado pode comparar:
VPN conectada
e:
VPN desconectada
quando isso for apropriado e seguro para o ambiente.
Não desinstale a VPN
Primeiro teste apenas a condição relevante.
Etapa 8 — Outra rede confiável
Se existem indícios de problema de conectividade, testar outra conexão confiável pode ser extremamente útil.
Por exemplo:
rede A → problema
rede B → Windows Update funciona
Isso muda completamente a direção do diagnóstico.
Não culpe a internet apenas porque a barra está em 0%
Se o pacote já foi completamente obtido e a falha está no servicing local, trocar DNS ou roteador provavelmente não resolverá.
Primeiro identifique a etapa.
DNS
Se existe evidência de problema de resolução, podemos verificar:
nslookup
e outros testes adequados.
Mas:
0% ≠ problema de DNS automaticamente.
Ping também não comprova funcionamento do Windows Update
Um:
ping
bem-sucedido mostra conectividade ICMP com determinado destino quando permitido.
Ele não valida sozinho todo o caminho necessário para o Windows Update.
Etapa 9 — Delivery Optimization
O Windows pode utilizar mecanismos de otimização de entrega para conteúdo.
Mas é importante distinguir:
obter conteúdo
de:
instalar/processar conteúdo.
Se a atualização já chegou à fase de servicing, não culpe Delivery Optimization automaticamente.
Etapa 10 — Políticas
Em computadores administrados, políticas podem modificar o comportamento do Windows Update.
Execute:
gpresult /r
Para gerar relatório:
gpresult /h "%userprofile%\Desktop\gpresult.html"
Por que políticas importam?
O computador pode utilizar:
- configurações corporativas;
- gerenciamento centralizado;
- políticas de atualização;
- regras específicas.
Não tente remover essas políticas em equipamento administrado.
Windows doméstico também pode possuir alterações
Ferramentas de otimização, scripts e ajustes manuais podem modificar políticas.
Se isso aconteceu, registre.
Etapa 11 — SoftwareDistribution
Agora chegamos a uma intervenção conhecida.
Se as evidências apontam para inconsistência no estado/cache local do Windows Update, podemos reconstruir a estrutura.
Não comece excluindo a pasta.
Prefira renomeá-la.
Pare os serviços necessários
Terminal como administrador:
net stop wuauserv
net stop bits
Renomeie
Execute:
ren C:\Windows\SoftwareDistribution SoftwareDistribution.old
Inicie novamente
net start bits
net start wuauserv
Reinicie o computador
Use:
Reiniciar
Depois:
Configurações → Windows Update → Verificar se há atualizações
O que observar?
Não queremos apenas:
“saiu de 0%”.
Queremos saber:
- atualização foi detectada?
- download ocorreu?
- instalação começou?
- apareceu erro?
- problema voltou?
Funcionou depois da reconstrução
Isso é uma evidência de que o estado/cache local relacionado ao Windows Update participava do problema.
Não funcionou
Não faça:
SoftwareDistribution.old2
SoftwareDistribution.old3
SoftwareDistribution.old4
Pare.
A hipótese perdeu força.
Etapa 12 — catroot2
Em cenários apropriados, podemos investigar a estrutura relacionada a serviços criptográficos e atualização.
Pare:
net stop cryptsvc
Renomeie:
ren C:\Windows\System32\catroot2 catroot2.old
Inicie:
net start cryptsvc
Depois reinicie e teste.
Atenção
Não confunda:
catroot2
com:
catroot
Não modifique a pasta errada.
Não faça SoftwareDistribution e catroot2 juntos inicialmente
Se possível, altere uma camada por vez.
Isso preserva valor diagnóstico.
Etapa 13 — Component Store
Se a atualização continua sem avançar e existem indícios de problema de servicing:
DISM /Online /Cleanup-Image /CheckHealth
Depois, quando necessário:
DISM /Online /Cleanup-Image /ScanHealth
Corrupção encontrada
Execute:
DISM /Online /Cleanup-Image /RestoreHealth
Aguarde.
Depois:
DISM /Online /Cleanup-Image /ScanHealth
para confirmar.
DISM apresenta erro?
Anote:
0xXXXXXXXX
Consulte:
C:\Windows\Logs\DISM\dism.log
e:
C:\Windows\Logs\CBS\CBS.log
Não execute RestoreHealth repetidamente
Se ele falha sempre da mesma maneira, descubra o motivo.
Talvez exista problema com:
- fonte;
- servicing;
- conectividade;
- imagem;
- corrupção;
- outro componente.
Etapa 14 — SFC
Quando apropriado:
sfc /scannow
Depois analise o resultado.
SFC corrigiu arquivos
Reinicie e teste novamente o Windows Update.
SFC não encontrou problemas
Ótimo.
Não repita dez vezes.
Avance para outra hipótese.
Etapa 15 — A KB manual como diagnóstico
Agora chegamos a um teste interessante.
Se conhecemos exatamente:
- KB;
- versão do Windows;
- arquitetura;
- aplicabilidade;
podemos verificar o pacote correspondente por uma fonte oficial apropriada.
Por que instalação manual pode ajudar?
Ela pode responder:
o problema está apenas no fluxo automático?
ou:
o próprio pacote também não consegue ser aplicado?
Mas confirme aplicabilidade primeiro
Não instale uma KB simplesmente porque o número parece mais novo.
Confirme:
- versão;
- build;
- arquitetura;
- tipo de atualização;
- substituições;
- aplicabilidade.
Pacote informa que não é aplicável
Pare.
Não tente forçar.
Volte e confira:
- versão;
- build;
- arquitetura;
- pré-requisitos;
- pacote correto.
Pacote manual também falha
Agora temos outra evidência.
O problema provavelmente não está apenas na interface gráfica do Windows Update.
Registre o código apresentado.
Pacote manual instala normalmente
Reinicie quando solicitado.
Execute:
winver
Confirme a build.
Depois volte ao Windows Update.
Teste novamente o fluxo automático
Isso é essencial.
Não considere o problema resolvido apenas porque instalamos uma KB manualmente.
Faça:
Verificar se há atualizações
e observe as próximas operações.
Etapa 16 — Armazenamento
Se existem:
- erros de leitura/gravação;
- lentidão extrema;
- corrupção recorrente;
- eventos de disco;
- travamentos;
investigue o armazenamento.
Verificação inicial do sistema de arquivos
chkdsk C: /scan
Analise o resultado.
SMART
Utilize ferramenta confiável para consultar informações SMART do SSD ou HDD.
Mas não diagnostique defeito apenas pela lentidão de uma atualização.
Etapa 17 — Software de segurança
Se existe antivírus de terceiros, firewall avançado ou software de filtragem, registre.
Não desinstale imediatamente.
Procure relação temporal
Pergunte:
o Windows Update funcionava antes da instalação ou atualização desse software?
Essa informação vale mais do que desativar ferramentas aleatoriamente.
Etapa 18 — Ferramentas de otimização e debloat
Scripts podem alterar:
- serviços;
- tarefas;
- políticas;
- componentes;
- Windows Update;
- telemetria;
- permissões.
Se o sistema foi modificado, documente.
Não tente desfazer tudo aleatoriamente
Se possível, descubra exatamente o que foi alterado.
O grande mapa do “0% sem progresso”
Instalando — 0%
↓
Existe progresso nos logs?
Sim
Aguarde e monitore.
Não
↓
Existe código de erro?
Sim
Investigue a operação correspondente.
Não
↓
Existe reboot pendente?
Sim
Conclua a operação anterior.
Não
↓
Serviços apresentam falha?
Sim
Investigue o serviço específico.
Não
↓
Existe problema de espaço?
Sim
Libere espaço com segurança.
Não
↓
Há evidência de conectividade/proxy/VPN/política?
Sim
Teste a camada correspondente.
Não
↓
Estado local do Windows Update parece inconsistente?
Sim
Reconstrua SoftwareDistribution.
↓
Problema persiste e há justificativa criptográfica/update?
Avalie catroot2.
↓
Servicing apresenta corrupção?
Use DISM.
↓
Arquivos protegidos apresentam problemas?
Use SFC.
↓
KB manual também falha?
Investigue o erro do pacote e servicing.
↓
Existem sinais de armazenamento/hardware?
Investigue hardware.
O que não fazer
Não executar 20 comandos de uma vez
Você perde a capacidade de identificar a causa.
Não apagar SoftwareDistribution como primeira tentativa
Colete evidências primeiro.
Não alterar todos os serviços para Automático
Não é uma correção universal.
Não trocar DNS sem evidência
A instalação pode já estar totalmente na camada local.
Não desligar firewall indiscriminadamente
Investigue primeiro.
Não remover antivírus aleatoriamente
Procure evidência de interferência.
Não forçar KB não aplicável
Revise versão, build e arquitetura.
Não remover pacotes do DISM por tentativa
Isso pode criar problemas adicionais.
Não apagar WinSxS
Nunca trate o Component Store como cache comum.
Não formatar o computador ainda
Ainda temos caminhos de reparação antes de chegar a esse ponto.
Diagnóstico definitivo: Windows Update em “Instalando — 0%”
Depois das três primeiras partes, já podemos abandonar uma conclusão muito comum:
“Está em 0%, então travou.”
Não necessariamente.
A porcentagem exibida pelo Windows Update representa apenas parte daquilo que o usuário consegue observar.
Enquanto a interface permanece em:
Instalando — 0%
o Windows pode estar:
- preparando componentes;
- processando pacotes;
- trabalhando no Component Store;
- executando servicing;
- utilizando TiWorker.exe;
- utilizando Windows Modules Installer;
- aguardando outra operação;
- lidando com uma reinicialização pendente;
- ou enfrentando uma falha real.
Por isso, a solução não começa com um reset.
Começa com uma classificação.
Os três estados fundamentais
Todo diagnóstico deste problema deve começar tentando colocar o computador em uma destas três categorias.
Estado A — 0% com atividade e progressão
A porcentagem permanece em zero, mas:
- CPU apresenta atividade relacionada;
- disco trabalha;
- CBS.log recebe novas operações;
- estados mudam;
- não existe erro repetitivo.
Nesse cenário:
aguardar pode ser a decisão tecnicamente correta.
Estado B — 0% com atividade, mas sem progressão
Existe:
- CPU;
- disco;
- TiWorker;
- servicing;
mas o sistema repete:
mesma operação
↓
mesmo erro
↓
nova tentativa
↓
mesmo erro.
Aqui temos atividade, mas não progresso.
É hora de investigar a falha.
Estado C — 0% sem atividade relevante
A interface permanece parada e:
- praticamente nada muda;
- não existe progressão nos registros;
- a operação não avança;
- eventualmente existe código de erro ou bloqueio.
Agora precisamos localizar a camada que impede a continuação.
A árvore definitiva de diagnóstico
Vamos organizar o procedimento completo.
Passo 1 — Identifique a atualização
Abra:
Configurações → Windows Update
Anote:
- nome;
- KB;
- tipo;
- porcentagem;
- horário.
Exemplo:
KBxxxxxxx
Não comece nenhum reparo antes de saber qual atualização está envolvida.
Passo 2 — Registre versão e build
Pressione:
Windows + R
Digite:
winver
Anote:
Versão
e:
Compilação do SO.
Por que registrar a build antes?
Porque depois podemos descobrir se houve progressão mesmo quando a interface pareceu estranha.
Passo 3 — Crie uma linha do tempo
Exemplo:
13:00 — download terminou
13:02 — Instalando 0%
13:12 — continua 0%
13:22 — continua 0%
13:32 — ainda 0%
Agora conseguimos correlacionar logs.
Passo 4 — Observe o Gerenciador de Tarefas
Use:
Ctrl + Shift + Esc
Observe:
- CPU;
- Disco;
- Memória;
- Rede.
Identifique processos relevantes.
Passo 5 — Abra o Monitor de Recursos
Execute:
resmon
Observe principalmente:
- disco;
- processos;
- atividade ao longo do tempo.
Não tire conclusões com base em alguns segundos.
Passo 6 — Observe TiWorker.exe
Se:
TiWorker.exe
estiver ativo, registre.
Não encerre o processo.
A pergunta é:
ele participa de uma operação que está avançando?
Passo 7 — Consulte TrustedInstaller
Execute:
sc query trustedinstaller
Novamente:
RUNNING
ou:
STOPPED
isoladamente não fecha diagnóstico.
Passo 8 — Gere WindowsUpdate.log
PowerShell:
Get-WindowsUpdateLog
Procure o período registrado.
Passo 9 — Analise CBS.log
Consulte:
C:\Windows\Logs\CBS\CBS.log
Concentre-se na janela temporal correta.
Passo 10 — Determine se existe progressão
Compare dois momentos.
Pergunte:
- surgiram novas operações?
- estados mudaram?
- pacotes avançaram?
- apareceu outro componente?
- existe conclusão parcial?
- o mesmo erro está apenas se repetindo?
Essa etapa é mais importante que a porcentagem.
Passo 11 — Registre códigos de erro
Se encontrar:
0xXXXXXXXX
anote junto com:
- KB;
- horário;
- operação;
- contexto.
Não trate o hexadecimal isoladamente.
Passo 12 — Consulte os pacotes
Terminal como administrador:
DISM /Online /Get-Packages
Para salvar:
DISM /Online /Get-Packages > "%userprofile%\Desktop\pacotes.txt"
Passo 13 — Compare pacotes quando necessário
Faça uma captura em outro momento:
DISM /Online /Get-Packages > "%userprofile%\Desktop\pacotes-depois.txt"
Compare estados relevantes.
Passo 14 — Verifique reinicialização pendente
Abra Windows Update.
Se existe uma operação anterior pedindo reinicialização, ela precisa entrar no diagnóstico.
Quando apropriado:
Iniciar → Energia → Reiniciar
Depois teste novamente.
Passo 15 — Veja se existem outras atualizações na fila
Observe se aparecem simultaneamente:
- atualização cumulativa;
- .NET;
- driver;
- Defender;
- atualização opcional;
- componente.
Um item pode estar aguardando outro.
Passo 16 — Consulte serviços
Execute:
sc query wuauserv
sc query bits
sc query cryptsvc
sc query trustedinstaller
Não altere todos os modos de inicialização.
Procure falhas concretas.
Passo 17 — Verifique armazenamento disponível
PowerShell:
Get-Volume
Também abra:
Configurações → Sistema → Armazenamento
Se o volume está extremamente cheio, libere espaço de maneira controlada.
Passo 18 — Não apague WinSxS
Nunca utilize:
C:\Windows\WinSxS
como pasta comum de limpeza.
Passo 19 — Verifique Component Store quando houver indícios
Comece:
DISM /Online /Cleanup-Image /CheckHealth
Quando necessário:
DISM /Online /Cleanup-Image /ScanHealth
Passo 20 — Corrupção encontrada?
Quando houver indicação de reparação:
DISM /Online /Cleanup-Image /RestoreHealth
Depois confirme novamente o estado.
Passo 21 — Use SFC quando apropriado
Execute:
sfc /scannow
Se houver reparações, reinicie e teste novamente.
Passo 22 — Verifique proxy somente quando fizer sentido
Execute:
netsh winhttp show proxy
Não altere configurações corporativas sem autorização e conhecimento do ambiente.
Passo 23 — VPN
Quando houver hipótese de interferência de conectividade, compare de maneira controlada o comportamento com a VPN conectada e desconectada, quando apropriado.
Não desinstale a VPN apenas para testar.
Passo 24 — Outra rede confiável
Quando o problema parece relacionado à comunicação, testar uma segunda rede confiável pode separar:
problema do computador
de:
problema do caminho de rede.
Passo 25 — Verifique políticas
Execute:
gpresult /r
Para relatório:
gpresult /h "%userprofile%\Desktop\gpresult.html"
Em computador corporativo, não remova políticas.
Passo 26 — Reconstrua SoftwareDistribution somente quando justificado
Terminal como administrador:
net stop wuauserv
net stop bits
Depois:
ren C:\Windows\SoftwareDistribution SoftwareDistribution.old
Inicie:
net start bits
net start wuauserv
Reinicie e teste.
Passo 27 — Funcionou?
Ótimo.
Confirme que:
- Windows Update detecta atualizações;
- download funciona;
- instalação progride;
- próxima busca funciona normalmente.
Passo 28 — Não funcionou?
Não repita a mesma reconstrução indefinidamente.
Avance.
Passo 29 — catroot2 quando houver justificativa
Execute:
net stop cryptsvc
Depois:
ren C:\Windows\System32\catroot2 catroot2.old
E:
net start cryptsvc
Reinicie e teste.
Passo 30 — Não altere catroot
A pasta:
catroot
não deve ser confundida com:
catroot2.
Passo 31 — Teste manualmente a KB quando isso produzir informação
Primeiro confirme:
- KB;
- versão;
- arquitetura;
- aplicabilidade;
- pacote correto.
Use somente fonte oficial apropriada.
O pacote manual instala?
Se sim:
- reinicie quando necessário;
- execute
winver; - confirme o resultado;
- teste novamente o Windows Update automático.
Pacote manual também falha?
Registre o código.
Agora sabemos que o problema provavelmente não está apenas na interface gráfica.
Pacote informa que não é aplicável?
Não force.
Volte e confirme:
- versão;
- build;
- arquitetura;
- pacote;
- pré-requisitos;
- tipo da atualização.
Passo 32 — Verifique sistema de arquivos quando houver evidência
Execute:
chkdsk C: /scan
Principalmente se existem outros sintomas relacionados ao armazenamento.
Passo 33 — Analise SSD quando existirem sinais adicionais
Verifique SMART com ferramenta apropriada.
Procure evidências como:
- erros;
- corrupção recorrente;
- travamentos;
- comportamento anormal de leitura/gravação.
Não condene o SSD por causa de uma única atualização lenta.
Passo 34 — Investigue software de segurança
Se existe antivírus de terceiros, firewall avançado ou filtro de rede, procure relação temporal e evidências.
Não desinstale automaticamente.
Passo 35 — Investigue scripts de otimização e debloat
Pergunte se o computador recebeu alterações em:
- serviços;
- políticas;
- tarefas;
- componentes;
- permissões;
- Windows Update.
Se sim, tente identificar exatamente o que foi modificado.
Passo 36 — DISM também falha?
Registre o código.
Consulte:
C:\Windows\Logs\DISM\dism.log
e:
C:\Windows\Logs\CBS\CBS.log
Agora a investigação pode envolver a própria capacidade de servicing/reparação.
Passo 37 — Fonte de reparação
Dependendo do erro, DISM pode precisar de uma fonte adequada.
Uma mídia compatível do Windows pode ser usada em cenários apropriados.
Confirme cuidadosamente:
- edição;
- versão;
- arquitetura;
- imagem;
- índice;
- compatibilidade.
Passo 38 — Considere reparação in-place
Esse procedimento fica muito abaixo na árvore.
Ele começa a fazer sentido quando:
- Windows Update permanece quebrado;
- servicing apresenta problemas persistentes;
- reparações específicas não resolveram;
- a mesma falha é reproduzível;
- causas mais simples foram descartadas.
Faça backup dos arquivos importantes antes de uma intervenção significativa.
Passo 39 — Instalação limpa
A instalação limpa fica no final.
Não transforme:
Instalando — 0%
em:
formatar o computador
sem passar pelo diagnóstico.
Tabela — Sintoma × primeira investigação
| Sintoma | Primeira área para investigar |
|---|---|
| 0% com CPU e disco ativos | verificar progressão |
| 0% com CBS avançando | aguardar e monitorar |
| 0% com TiWorker ativo | servicing |
| 0% com atividade, mas mesmo erro repetido | erro/operação |
| 0% praticamente sem atividade | serviços/estado/logs |
| 0% depois de reboot pendente | concluir operação anterior |
| 0% com pouco espaço | armazenamento |
| 0% e DISM detecta corrupção | Component Store |
| 0% somente em determinada rede | conectividade |
| 0% com VPN e funciona sem ela | investigar caminho da VPN |
| 0% em PC corporativo | políticas/gerenciamento |
| SoftwareDistribution resolve | estado/cache local relacionado |
| SoftwareDistribution não muda nada | abandonar essa hipótese |
| KB manual instala | investigar fluxo automático |
| KB manual também falha | pacote/servicing |
| KB diz não aplicável | versão/build/arquitetura/aplicabilidade |
| DISM falha | DISM.log/CBS.log/fonte |
| corrupção recorrente | investigar causa subjacente |
| SSD apresenta outros erros | armazenamento/hardware |
Sequência curta de comandos para diagnóstico
Versão e build
winver
Windows Update log
Get-WindowsUpdateLog
Pacotes
DISM /Online /Get-Packages
Windows Update Service
sc query wuauserv
BITS
sc query bits
Cryptographic Services
sc query cryptsvc
Windows Modules Installer
sc query trustedinstaller
Component Store — verificação rápida
DISM /Online /Cleanup-Image /CheckHealth
Component Store — análise
DISM /Online /Cleanup-Image /ScanHealth
Reparação quando justificada
DISM /Online /Cleanup-Image /RestoreHealth
Arquivos protegidos
sfc /scannow
Proxy
netsh winhttp show proxy
Políticas
gpresult /r
Volumes
Get-Volume
Sistema de arquivos
chkdsk C: /scan
Não execute essa lista inteira
Ela é um resumo de ferramentas disponíveis ao longo da árvore.
O método correto é:
pergunta
↓
comando
↓
resultado
↓
nova hipótese.
Não:
copiar tudo → colar tudo → esperar algum comando resolver.
Quando simplesmente esperar?
Aguardar é razoável quando existem evidências de progressão.
Por exemplo:
- CBS continua avançando;
- operações mudam;
- disco apresenta atividade relacionada;
- servicing continua processando componentes;
- não existe falha repetitiva;
- estado eventualmente muda.
Quando começar a investigar?
Quando temos:
- ausência prolongada de progressão;
- mesma operação repetitiva;
- código de erro;
- pacote que não muda;
- serviços apresentando falha;
- comportamento reproduzível.
Quando reiniciar?
Quando:
- Windows solicita;
- existe operação pendente que precisa de reboot;
- uma reparação realizada exige nova inicialização;
- o procedimento específico determina essa etapa.
Não utilize reboot como botão genérico para interromper uma instalação que está trabalhando.
Quando usar SoftwareDistribution?
Quando o diagnóstico aponta para inconsistência do estado/cache local do Windows Update e outras verificações sustentam essa hipótese.
Não como primeiro passo.
Quando usar catroot2?
Quando a investigação aponta para uma camada relacionada em que sua reconstrução seja justificável.
Não automaticamente depois de SoftwareDistribution.
Quando usar DISM?
Quando precisamos:
- verificar o Component Store;
- investigar corrupção;
- reparar corrupção detectada dentro do mecanismo apropriado.
Quando usar SFC?
Quando precisamos verificar a integridade dos arquivos protegidos do sistema.
Quando testar a KB manual?
Quando sabemos exatamente qual pacote deveria ser aplicado e queremos separar:
falha do fluxo automático
de:
falha da própria aplicação do pacote.
Quando investigar SSD?
Quando existem outros sinais:
- erros de armazenamento;
- corrupção;
- travamentos;
- desempenho anormal;
- eventos correspondentes.
Quando considerar reparação in-place?
Quando problemas persistentes de servicing/Windows Update sobrevivem aos reparos específicos e já descartamos hipóteses mais simples.
O que nunca deve ser a primeira solução?
Apagar WinSxS
Não faça.
Remover pacotes aleatoriamente
Não faça.
Finalizar TiWorker
Não faça apenas porque está consumindo recursos.
Finalizar TrustedInstaller
Não interrompa servicing sem entender o estado.
Desativar permanentemente o Windows Update
Isso não corrige a causa.
Desativar firewall indiscriminadamente
Investigue antes.
Desinstalar antivírus por tentativa
Procure evidência.
Trocar DNS aleatoriamente
Primeiro confirme que existe problema de comunicação.
Instalar qualquer KB manualmente
Confirme aplicabilidade.
Executar scripts gigantes de reset
Saiba exatamente o que cada comando modifica.
Formatar imediatamente
Deixe para o final da árvore.
FAQ — Windows Update fica em Instalando 0%
Windows Update em 0% significa que travou?
Não necessariamente.
A interface pode permanecer em 0% enquanto existem operações de preparação, staging e servicing em andamento.
Observe atividade e progressão antes de concluir que existe falha.
Quanto tempo devo esperar em 0%?
Não existe um tempo universal que diagnostique travamento.
Observe:
- CPU;
- disco;
- logs;
- processos;
- mudança de estados;
- erros.
Um computador lento e um computador rápido podem levar tempos diferentes.
Como saber se ainda está instalando?
Combine informações do:
- Gerenciador de Tarefas;
- Monitor de Recursos;
- CBS.log;
- WindowsUpdate.log;
- estado dos pacotes.
A presença de progressão é mais importante que a porcentagem da interface.
O que é TiWorker.exe?
TiWorker.exe está associado ao Windows Modules Installer Worker e pode participar de operações de servicing e manutenção de componentes do Windows.
Posso finalizar TiWorker.exe?
Não faça isso simplesmente porque ele está utilizando CPU ou disco.
Primeiro determine se existe servicing legítimo em andamento.
O que é TrustedInstaller?
O Windows Modules Installer participa de operações relacionadas aos componentes do Windows.
Sua atividade pode aparecer durante processos de atualização e manutenção.
Disco em 100% significa que a atualização está funcionando?
Não necessariamente.
Descubra qual processo está utilizando o armazenamento e se existe progressão.
SSD lento pode fazer o Windows Update parecer travado?
O desempenho do armazenamento pode influenciar o tempo de processamento.
Mas uma atualização lenta não diagnostica SSD defeituoso.
Posso reiniciar se estiver em 0%?
Não use reinicialização como tentativa automática se existem evidências de que uma operação legítima está trabalhando.
Se o Windows solicita reinicialização ou o diagnóstico determina essa etapa, faça um reboot normal.
Posso apagar SoftwareDistribution?
Em determinados problemas relacionados ao estado/cache local do Windows Update, uma reconstrução controlada pode ajudar.
Mas não deve ser o primeiro procedimento para todo caso de 0%.
Posso apagar catroot2?
A reconstrução pode ser utilizada em cenários específicos.
Prefira renomear de forma controlada quando houver justificativa e não confunda catroot2 com catroot.
DISM pode destravar o Windows Update?
DISM pode ajudar quando existe problema no Component Store.
Ele não é um comando criado simplesmente para aumentar a porcentagem do Windows Update.
Qual comando DISM executar primeiro?
Para investigação de integridade, podemos começar com:
DISM /Online /Cleanup-Image /CheckHealth
e aprofundar com:
DISM /Online /Cleanup-Image /ScanHealth
quando necessário.
Quando usar RestoreHealth?
Quando existe justificativa para reparar o Component Store.
Use:
DISM /Online /Cleanup-Image /RestoreHealth
dentro de um diagnóstico, e não como ritual.
SFC resolve Windows Update em 0%?
Pode ajudar se existirem arquivos protegidos do sistema danificados relacionados ao problema.
Mas não resolve todas as causas possíveis.
VPN pode impedir Windows Update?
Dependendo do ambiente e da configuração, uma VPN pode alterar o caminho de comunicação.
Se houver suspeita, faça um teste controlado em vez de simplesmente desinstalá-la.
DNS pode causar Windows Update em 0%?
Problemas de resolução podem afetar comunicação em determinados cenários, mas uma atualização já na etapa local de servicing pode não ter qualquer relação com DNS.
Identifique primeiro a etapa da falha.
Pouco espaço pode atrapalhar a atualização?
Sim, espaço disponível pode ser relevante.
Mas não use um limite universal inventado. Verifique o estado real do volume e os registros da operação.
Posso instalar a KB manualmente?
Quando você confirmou versão, build, arquitetura e aplicabilidade, a instalação manual por fonte oficial pode servir como teste diagnóstico.
A KB diz que não é aplicável. O que faço?
Não tente forçar.
Confirme:
- versão;
- build;
- arquitetura;
- pacote;
- pré-requisitos;
- tipo de atualização.
O que fazer se a instalação manual também falhar?
Registre o código de erro.
Isso indica que o problema pode não estar apenas no fluxo automático do Windows Update.
Preciso formatar o Windows?
Não como primeira solução.
Problemas de Windows Update frequentemente podem ser diagnosticados e reparados sem instalação limpa.
Conclusão — Antes de consertar o 0%, descubra se existe algo quebrado
Quando o Windows Update permanece em:
Instalando — 0%
a porcentagem chama toda a atenção.
Mas ela é apenas uma parte do diagnóstico.
O método mais seguro é:
identificar a KB
↓
registrar versão e build
↓
marcar o horário
↓
observar CPU e disco
↓
identificar TiWorker e TrustedInstaller
↓
analisar WindowsUpdate.log
↓
analisar CBS.log
↓
verificar se existe progressão
↓
separar atividade de repetição
↓
verificar pacotes
↓
identificar reboot ou dependências
↓
verificar serviços
↓
investigar espaço e conectividade somente quando relevantes
↓
reconstruir SoftwareDistribution somente quando justificado
↓
avaliar catroot2 quando necessário
↓
verificar Component Store
↓
usar DISM e SFC com propósito
↓
testar a KB manualmente quando isso produzir informação
↓
investigar armazenamento quando existirem evidências
↓
considerar reparação in-place nos casos persistentes.
O principal aprendizado é simples:
0% não significa zero trabalho.
Um Windows Update pode permanecer visualmente parado enquanto o sistema continua processando componentes.
Da mesma maneira, CPU e disco altos também não garantem progresso.
O diagnóstico correto precisa responder:
o estado está mudando?
Se estiver, acompanhe.
Se não estiver, descubra onde a sequência parou.
Só então faça a correção.
VMIA — Diagnóstico de Windows Update e Windows 11
Se o Windows Update permanece em “Instalando — 0%”, a VMIA – Manutenção e Configuração pode ajudar a identificar se o computador está apenas processando a atualização ou se existe uma falha real impedindo a instalação.
O diagnóstico pode incluir:
- Windows Update;
- KBs e builds;
- WindowsUpdate.log;
- CBS.log;
- TiWorker.exe;
- TrustedInstaller;
- Component Store;
- DISM;
- SFC;
- BITS;
- serviços do Windows;
- SoftwareDistribution;
- drivers;
- espaço em disco;
- conectividade;
- políticas;
- falhas de servicing.
Atendimento mediante agendamento, presencial ou por acesso remoto conforme o problema.
VMIA – Manutenção e Configuração
Rua Prof. Sud Menucci, 291
Vila Mariana – São Paulo – SP
CEP 04017-080
Telefone/WhatsApp: (11) 99779-7772
E-mail: suporte@vmia.com.br
Site: https://vmia.site
Blog: https://vmia.com.br
Antes de resetar o Windows Update ou formatar o computador, descubra se 0% realmente significa travamento ou se o Windows ainda está trabalhando nos bastidores.
Faça um comentário