Windows Update 0x800f0831 e 0x800705b4: correcção passo a passo

Dois dos códigos mais incómodos do Windows Update raramente significam a mesma coisa. O 0x800f0831 aponta para uma component store corrompida — a estrutura interna que guarda os manifests de cada pacote do Windows — e bloqueia instalações cumulativas inteiras. O 0x800705b4 é um timeout genérico do sistema e normalmente não guarda relação com a store. Este guia percorre o caminho correcto para um terminal ou servidor PME: confirmar a causa no CBS.log, reparar a store, instalar o payload do update manualmente quando a reparação chega, e só depois reset aos componentes do Windows Update.

O que significam os dois códigos

O 0x800f0831 devolve a mensagem CBS_E_STORE_CORRUPTION. O Component-Based Servicing (CBS) é o serviço que instala e desinstala pacotes do Windows — quando um pacote não consegue resolver o manifest de um pacote anterior, o CBS marca a store como corrompida e a instalação falha. Este erro acontece tipicamente quando o update requer um pacote anterior que está em falta na store ou cujas entradas de registo não foram aplicadas por completo.

O 0x800705b4 é diferente: é o erro de sistema genérico 1460 (0x5B4), ERROR_TIMEOUT, cuja descrição oficial é “This operation returned because the timeout period expired”. Não é um código da CBS e não indica corrupção por si só — indica que a operação deixou de responder dentro do período previsto. No contexto do Windows Update aparece quando o serviço de actualizações arranca mal, fica bloqueado por outro serviço ou perde o tempo de espera durante o scan ou a instalação.

Código Mensagem O que realmente indica
0x800f0831 CBS_E_STORE_CORRUPTION Component store corrompida, manifest de pacote em falta
0x800705b4 ERROR_TIMEOUT (1460) Operação sem resposta dentro do tempo previsto

Erro 0x800f0831 no Windows Update: instalação falhada da actualização cumulativa (screenshot Microsoft)

Primeiro passo: confirmar a causa no CBS.log

Antes de qualquer reparação, obtenha a prova no CBS.log. O log vive em %windir%\logs\cbs\cbs.log e a linha decisiva começa por “Store corruption, manifest missing for package”. Tente instalar de novo o update em causa (para gerar entradas frescas no log) e depois execute numa linha de comandos elevada:


# Procurar manifests em falta no log CBS mais recente
findstr /i "manifest missing" %windir%\logs\cbs\cbs.log

Um resultado típico do log:


Info CBS Store corruption, manifest missing for package: Package_123_for_KB3192392~31bf3856ad364e35~amd64~~6.3.1.4
Error CBS Failed to resolve package 'Package_123_for_KB3192392~31bf3856ad364e35~amd64~~6.3.1.4' [HRESULT = 0x800f0831 - CBS_E_STORE_CORRUPTION]
Info CBS Mark store corruption flag because of package: Package_123_for_KB3192392~31bf3856ad364e35~amd64~~6.3.1.4. [HRESULT = 0x800f0831 - CBS_E_STORE_CORRUPTION]

O que está a ver: o nome do pacote em falta (o KB3192392 do exemplo vem da própria documentação da Microsoft, que ilustra o log com um KB antigo — no teu caso será outro código) (a família KB mais a build exacta) e a marca de corrupção da store. Esse nome identifica o update cujo payload pode ser preciso re-instalar manualmente mais abaixo. Se o findstr não devolver manifest nenhum em falta, o 0x800f0831 está a funcionar como sintoma indirecto — avance na mesma para a reparação da store, porque a flag CBS_E_STORE_CORRUPTION já apareceu no HRESULT da instalação falhada.

Para o 0x800705b4 o log diz outra coisa: não há linhas de corrupção. O que aparece são tentativas que terminam sem resposta do serviço. Nesse caso salte para a secção do timeout mais abaixo.

Correcção 1: reparar a component store com DISM e SFC

A reparação da component store com DISM e SFC é a primeira correcção a tentar para o CBS_E_STORE_CORRUPTION. Num prompt elevado execute os quatro comandos pela ordem:


Dism.exe /Online /Cleanup-Image /ScanHealth
Dism.exe /Online /Cleanup-Image /CheckHealth
Dism.exe /Online /Cleanup-Image /RestoreHealth
sfc /scannow

Terminados os comandos, reinicie o terminal e tente instalar o update outra vez.

Porquê

esta ordem — o ScanHealth analisa a store em busca de corrupção e demora minutos. O CheckHealth só lê a flag da última operação (é rapidíssimo e não repara nada). O RestoreHealth é quem repara: substitui os componentes corrompidos usando a fonte de reparação configurada — o Windows Update por omissão, ou WSUS quando existe política de gestão a meio. O SFC /scannow verifica depois os ficheiros de sistema protegidos e repõe a versão correcta dos ficheiros usando as cópias locais do componente store (a pasta WinSxS).

Saída típica do RestoreHealth na finalização:


[==========================100.0%==========================] The restore operation completed successfully.

Se o RestoreHealth terminar com o erro 0x800f081f (CBS_E_SOURCE_MISSING), o DISM não conseguiu obter os ficheiros de origem de que precisava — o DISM termina a operação a avisar que os ficheiros de origem não foram encontrados e que a localização tem de ser indicada com a opção /Source. Isto acontece em terminais sem acesso ao Microsoft Update, com WSUS a servir só o canal de updates, ou com proxy a bloquear o download. O caminho seguinte é a correcção 2, que não depende de acesso externo.

⚠ Aviso

o RestoreHealth e o SFC escrevem na component store e em ficheiros de sistema. Antes de tratar um servidor de produção, garanta backup ou snapshot da máquina antes de corrigir este erro.

Correcção 2: quando o RestoreHealth falha, instalar o payload do update manualmente

Quando a reparação online não chega, há um caminho directo para o 0x800f0831: instalar o payload fresco do update por comando. A Microsoft nota que o 0x800f0831 é mais provável quando o terminal não tem acesso ao Microsoft Update — por isso este caminho, que dispensa esse acesso, é o que costuma destravar os terminais servidos por WSUS.

Excepção importante: se a máquina for uma VM em Azure, a Microsoft recomenda directamente o in-place upgrade (IPU) em vez deste procedimento manual — reinstala o sistema mantendo a configuração. O fluxo abaixo vale para máquinas físicas e VMs fora de Azure.

Primeiro, identifique o número KB do pacote em falta no CBS.log (repare nas linhas do passo anterior). Abra o Microsoft Update Catalog, procure esse KB e descarregue o pacote que corresponde à versão e arquitectura do sistema. Guarde-o numa pasta temporária, por exemplo C:\temp. A seguir, expanda o .msu para obter o .cab interno:


cd \
cd temp
expand -F:* NOME_DO_PACOTE.msu C:\temp

Nota

— substituindo NOME_DO_PACOTE pelo nome real do ficheiro descarregado (algo do género windows10.0-kb4462937-x64_9e250691ae6d00cdf677707e83435a612c3264ea.msu — o KB4462937 é só o exemplo da documentação, o teu código será o KB identificado no CBS.log). O expandimento gera vários ficheiros — incluindo o .cab que interessa. Nos vários .cab gerados, escolhe o que corresponde à versão e arquitectura do teu sistema (no exemplo, windows10.0-KB4462937-x64.cab).

Se o update aparecer parcial ou completamente instalado no sistema, remova-o primeiro com o .cab obtido:


Dism /online /remove-package /packagepath:C:\temp\NOME_DO_CAB.cab

Reinicie se for pedido, e instale de novo o update a partir do .cab:


Dism /online /add-package /packagepath:C:\temp\NOME_DO_CAB.cab

Reinicie o sistema e experimente instalar o update normalmente. Com o payload fresco aplicado por DISM, o pacote resolve e o scan seguinte do Windows Update já não tropeça no manifest em falta.

0x800705b4: quando o erro é tempo, não ficheiro

Se o CBS.log não revela corrupção e o DISM devolve uma store limpa, o 0x800705b4 normalmente não se resolve com reparações de conteúdo: o código é ERROR_TIMEOUT (1460) e indica que a operação passou do tempo limite — por exemplo uma sessão de instalação lenta num disco quase cheio, um serviço de segurança de terceiros a interagir com o agente ou uma fonte de updates (WSUS ou proxy) lenta no scan. Timeouts do lado do CBS existem também com códigos próprios — o 0x800f0821 (CBS transaction timeout) e o 0x800f0920 (hang CBS detectado) — e a mitigação documentada da Microsoft para essa classe é aumentar os recursos da máquina (em VM, mais vCPU e memória) e ter o KB4493473 ou mais recente instalado.

A sequência com melhor custo-benefício:

  1. Libertar espaço no disco de sistema — se o terminal anda com o disco no limiar, o Windows Update falha antes de começar (ver a secção de limpeza mais abaixo).
  2. Reiniciar a máquina e repetir o update sem abrir outras aplicações durante a instalação — algumas instalações demoram bem mais de uma hora e cancelar o processo devolve exactamente um timeout.
  3. Se após o reinício o erro se repetir, executar uma verificação de arranque limpo (clean boot) para isolar bloqueios de serviços de terceiros, e repetir.
  4. Em rede com WSUS: confirmar que o servidor WSUS responde e que o terminal consegue comunicar com ele antes de seguir para o reset de componentes.

O reset dos componentes do Windows Update (secção seguinte) resolve a classe de timeouts em que é o próprio agente que fica mal configurado ou bloqueado por pastas de download corrompidas.

Última linha: reset dos componentes do Windows Update

Comece pelo Windows Update Troubleshooter (no Windows 11: Definições → Sistema → Resolução de problemas → Outros solucionadores). Se não resolver, faz o reset do agente. O reset mínimo é:


# Reset do Windows Update Agent (mínimo)
net stop wuauserv
net stop bits
rd /s /q %systemroot%\SoftwareDistribution
net start bits
net start wuauserv

O SoftwareDistribution reconstrói vazio a seguir — o Windows regenera a fila de update na próxima pesquisa. Quando o problema persiste, o reset manual completo suspende três serviços e rebaptiza as pastas de trabalho:


# Reset manual completo às pastas de trabalho
net stop bits
net stop wuauserv
net stop cryptsvc
Ren %Systemroot%\SoftwareDistribution\DataStore DataStore.bak
Ren %Systemroot%\SoftwareDistribution\Download Download.bak
Ren %Systemroot%\System32\catroot2 catroot2.bak
net start bits
net start wuauserv
net start cryptsvc

⚠ Atenção

rebaptizar catroot2 exige os três serviços suspensos, ou o rebaptize falha por ficheiros em uso. Depois dos comandos, reinicie o terminal. As pastas .bak podem eliminar-se com segurança após confirmar que o Windows Update volta a funcionar.

Espaço em disco e limpeza da component store

Tanto o timeout como a corrupção agravam-se com o disco de sistema cheio — e a component store (a pasta WinSxS) é um dos pontos que crescem com cada update cumulativo. O DISM mede e limpa sem recorrer a atalhos manuais de eliminação de ficheiros:


Dism.exe /Online /Cleanup-Image /AnalyzeComponentStore

Exemplo de saída:


Component Store (WinSxS) information:
Windows Explorer Reported Size of Component Store : 4.98 GB
Actual Size of Component Store : 4.88 GB
Shared with Windows : 4.38 GB
Backups and Disabled Features : 506.90 MB
Cache and Temporary Data : 279.52 KB
Date of Last Cleanup : 2021-06-24 23:32:22
Number of Reclaimable Packages : 0
Component Store Cleanup Recommended : No

O que interessa é a soma de “Backups and Disabled Features” com “Cache and Temporary Data” (a sobrecarga real da store) e a linha Component Store Cleanup Recommended. Quando a linha indica Yes, execute a limpeza:


Dism.exe /online /Cleanup-Image /StartComponentCleanup

⚠ Aviso

a opção mais agressiva é acrescentar o parâmetro /ResetBase junto do /StartComponentCleanup, num comando único que remove as versões substituídas de todos os componentes. Depois desta operação, os pacotes de update existentes já não podem ser desinstalados (não afecta desinstalações futuras). Num servidor PME, aplique só quando houver backup recente e sem planos de rollback de updates.

Nunca elimine manualmente a pasta WinSxS — isto pode danificar o sistema a ponto de o PC não arrancar e deixar de poder actualizar.

Artigos relacionados

Fontes oficiais