Se a primeira atualização do Windows Server 2019 parece “congelar” em 17 % enquanto o disco trabalha sem parar, a causa costuma ser lentidão no processo de manutenção (servicing) e não necessariamente um erro. Abaixo está um guia prático, seguro e completo para diagnosticar, corrigir e concluir a atualização.
Visão geral do problema
Logo após a instalação limpa do Windows Server 2019, é comum que a primeira atualização cumulativa seja bem grande. Nessa etapa, o sistema precisa:
- Atualizar a Servicing Stack (SSU), que é quem instala as outras atualizações;
- Preparar e aplicar a cumulative update (LCU), substituindo componentes protegidos;
- Reindexar catálogos e limpar componentes antigos.
O indicador visual pode permanecer longo tempo em 17 %, mas o serviço TrustedInstaller continua trabalhando em segundo plano. Em discos HDD ou VMs com I/O limitado, isso pode levar de dezenas de minutos a algumas horas, especialmente na primeira atualização após a instalação.
Solução passo a passo
- Verifique a Servicing Stack Update No Histórico de Atualizações, confirme se o SSU KB5005112 está instalado. Se não estiver, instale-o antes da cumulativa. Em ambientes sem Internet, utilize a mídia offline (ver mais adiante) para aplicar o pacote do SSU primeiro. Como checar via linha de comando:
dism /online /get-packages /format:table | findstr /i "Servicing Stack" wmic qfe | find "KB5005112" - Execute o Solucionador de Problemas do Windows Update Caminho: Configurações ▸ Atualização e Segurança ▸ Solucionar problemas ▸ Solucionadores adicionais ▸ Windows Update. Deixe que ele corrija automaticamente permissões, serviços e cache corrompido.
- Repare arquivos de sistema e a imagem do Windows Abra um Prompt de Comando (Admin) e execute:
sfc /scannow DISM /Online /Cleanup-Image /RestoreHealthOsfcrestaura arquivos protegidos; oDISMrepara a imagem do sistema e componentes de atualização. - Atualize de forma offline Se o Windows Update continuar falhando, aplique a cumulativa manualmente:
- Crie as pastas de trabalho:
mkdir C:\temp && mkdir C:\temp\cab - Baixe o pacote
.msuda atualização cumulativa paraC:\temp. - Extraia o
.cabde dentro do.msu:expand -F:* C:\temp<nome>.msu C:\temp\cab - Instale o
.cabcom o DISM:DISM /Online /Add-Package /PackagePath:C:\temp\cab<nome>.cab
- Crie as pastas de trabalho:
- Se nada indicar erro crítico, aguarde Sem mensagens de erro e com LED/indicador de disco ativo, a melhor ação é aguardar. Em VMs, discos HDD ou hosts com snapshots/checkpoints, a aplicação de LCUs grandes pode levar bem mais que 30 minutos. No caso relatado, o processo finalizou sozinho após um longo tempo, confirmando que a causa principal era lentidão de I/O e não um defeito.
Boas práticas antes de atualizar
| Verificação | Por quê | Como agir |
|---|---|---|
| Espaço em disco | Menos de 10 GB livres pode atrasar ou falhar a atualização. | Limpe temporários, desinstale recursos não usados ou amplie o volume do SO. |
| Snapshots/Checkpoints | Penalizam I/O e aumentam o tempo de commit de blocos. | Evite atualizar com snapshots ativos; consolide antes. |
| Antivírus | Alguns interceptam operações de patching. | Desative temporariamente ou crie exceções para C:\Windows\SoftwareDistribution e C:\Windows\WinSxS. |
| Integridade do sistema | Arquivos corrompidos causam falhas silenciosas e loops de tentativa. | Execute sfc e DISM /RestoreHealth antes da LCU. |
| Energia e janelas de manutenção | Interrupções causam reversões demoradas. | Programe janela adequada e use shutdown controlado. |
Como confirmar que não está realmente travado
- Monitor de Recursos: verifique acesso contínuo a
C:\Windows\WinSxS,\Servicing\e\SoftwareDistribution\. Tráfego frequente indica progresso. - Gerenciador de Tarefas: o processo
TiWorker.exe(Windows Modules Installer Worker) com uso de CPU/disco variável é sinal de atividade. - Visualizador de Eventos: veja Aplicativo e Serviços ▸ Microsoft ▸ Windows ▸ Servicing e Setup. Novos eventos = andamento.
Reinicialização e tempo seguro de espera
Se houver hora sem qualquer atividade de CPU/disco e nenhum evento recente de servicing, considere reiniciar apenas se houver janela de manutenção e backup/snapshot prévio. Na maioria dos casos, aguardar conclui a atualização sem riscos.
Reset do Windows Update (cache e serviços)
Se houver falhas repetidas (códigos 0x8… ou loop em “Preparando atualizações”), faça um reset controlado do cache:
net stop wuauserv
net stop cryptSvc
net stop bits
net stop msiserver
ren C:\Windows\SoftwareDistribution SoftwareDistribution.old
ren C:\Windows\System32\catroot2 catroot2.old
net start msiserver
net start bits
net start cryptSvc
net start wuauservDepois, tente novamente pelo Windows Update ou aplique a cumulativa manualmente via DISM /Add-Package.
Diagnóstico por logs
- CBS.log:
C:\Windows\Logs\CBS\CBS.log— procura por “error”, “0x800f” ou “servicing”. - DISM.log:
C:\Windows\Logs\DISM\dism.log— útil para falhas no/Add-Package. - WindowsUpdate.log (consolidado): gere com PowerShell:
Get-WindowsUpdateLog -LogPath "$env:USERPROFILE\Desktop\WindowsUpdate.log"
Erros comuns e como tratar
| Código | Indicação | Correção recomendada |
|---|---|---|
| 0x800f081f | Fonte de componentes ausente. | Monte a ISO do Windows Server 2019 e aponte o DISM para o install.wim correto: DISM /Online /Cleanup-Image /RestoreHealth /Source:D:\sources\install.wim:2 /LimitAccess (ajuste a letra da unidade e o índice de edição). |
| 0x800f0922 | Partição reservada pequena ou falha de conexão com endpoints de atualização. | Amplie a partição reservada do sistema e confirme rotas/firewall. Atualize offline se necessário. |
| 0x8024000b | Catálogo do Windows Update inconsistente. | Faça o reset de cache (SoftwareDistribution/catroot2) e rode o solucionador. |
| 0x80248007 | Metadados de atualização corrompidos. | Reset de cache + DISM /RestoreHealth; depois aplique a LCU manualmente. |
Considerações para ambientes com WSUS/SCCM
- Garanta a classificação e os produtos corretos para Windows Server 2019.
- Se suspeitar de metadados do WSUS, altere temporariamente a política UseWUServer para permitir atualização direta, teste, e então restaure a política.
- Prefira grupos de teste antes de aprovar para produção, reduzindo a chance de travamentos em massa.
Prevenção para as próximas atualizações
- Mantenha imagens de referência com SSU atual e cumulativa mais recente já aplicadas.
- Programe maintenance windows amplas em VMs com disco mecânico ou armazenamento compartilhado congestionado.
- Evite executar tarefas pesadas de backup, antivírus e jobs de banco de dados durante o patch window.
- Monitore saúde de disco (SMART/latência) — I/O ruim gera tempos de patch altíssimos.
Perguntas frequentes
É normal parar em 17 %? Em muitos cenários, sim. O percentual representa fases, não tempo. A etapa de component servicing pode concentrar grande parte do trabalho.
Posso desligar o servidor? Evite. Interromper pode causar reversões demoradas e corrupção de componentes. Somente considere reiniciar quando não houver atividade mensurável e após backup/snapshot.
Devo matar o TrustedInstaller? Não. Encerrar o TiWorker.exe durante a aplicação é arriscado e pode exigir reparos manuais extensos.
Como saber se realmente travou? Falta total de atividade de disco/CPU por longos períodos e ausência de novos eventos de servicing. Caso contrário, é apenas lento.
Comandos rápidos para copiar e colar
:: Verificar SSU
dism /online /get-packages /format:table | findstr /i "Servicing Stack"
wmic qfe | find "KB5005112"
:: Solucionar Update
ms-settings:troubleshoot
:: Reparar imagem e arquivos
sfc /scannow
DISM /Online /Cleanup-Image /RestoreHealth
:: Reset do cache do Windows Update
net stop wuauserv & net stop cryptSvc & net stop bits & net stop msiserver
ren C:\Windows\SoftwareDistribution SoftwareDistribution.old
ren C:\Windows\System32\catroot2 catroot2.old
net start msiserver & net start bits & net start cryptSvc & net start wuauserv
:: Instalação offline da LCU (.cab extraído de .msu)
mkdir C:\temp && mkdir C:\temp\cab
expand -F:* C:\temp<nome>.msu C:\temp\cab
DISM /Online /Add-Package /PackagePath:C:\temp\cab<nome>.cabChecklist rápido de diagnóstico
| Item | Estado desejado | Ação se fora do padrão |
|---|---|---|
| SSU presente | KB5005112 (ou SSU atual) instalado | Aplicar SSU manualmente antes da LCU |
| Espaço livre | > 10 GB (recomendado 20 GB) | Limpar/expandir volume do SO |
| Snapshots | Sem checkpoints ativos | Consolidar antes de atualizar |
| Antivírus | Exceções aplicadas | Adicionar exclusões ou desativar temporariamente |
| Logs | Sem erros 0x800f/0x8024 | Usar CBS/DISM/WindowsUpdate.log para corrigir |
| Atividade de disco | WinSxS/Servicing ativos durante a LCU | Aguardar conclusão se há progresso |
Resumo do caso real
No cenário que motivou este guia, a primeira atualização pós-instalação do Windows Server 2019 permaneceu muito tempo em 17 % com atividade constante de disco. Após verificar SSU, rodar o solucionador, reparar a imagem e confirmar ausência de erros críticos, optou-se por aguardar. O processo concluiu sem intervenção adicional, reforçando que o gargalo era desempenho de I/O e não falha de atualização.
Conclusão
Quando uma atualização do Windows Server 2019 fica aparente e persistentemente em 17 %, não assuma falha de imediato. Valide SSU, repare o sistema, utilize a instalação offline quando necessário e acompanhe logs e I/O. Na maioria dos casos, a combinação de higiene de sistema + paciência resolve de forma segura e previsível.