Windows Update problemas de solução de problemas
Aplica-se a: Windows 10
Experimente nosso Agente Virtual – ele pode ajudá-lo a identificar e corrigir problemas comuns de Windows Update
Se você tiver problemas ao usar Windows Update, comece com as seguintes etapas:
Execute a solução de problemas Windows Update interna para corrigir problemas comuns. Navegue até Configurações>Atualizar &solução>de problemas de segurança > Windows Update.
Instale a atualização de pilha de manutenção mais recente que corresponde à sua versão do Windows do Catálogo de Atualizações da Microsoft. Para obter mais informações sobre atualizações de pilha de manutenção, consulte Atualizações de pilha de manutenção.
Verifique se você instala as atualizações mais recentes do Windows, atualizações cumulativas e atualizações de roll-up. Para verificar o status de atualização, consulte o histórico de atualizações apropriado para seu sistema:
- Windows 10, versão 2004 e Windows Server, versão 2004
- Windows 10, versão 1909 e Windows Server, versão 1909
- Windows 10, versão 1903 e Windows Server, versão 1903
- Windows 10, versão 1809 e Windows Server 2019
- Windows 10, versão 1803
- Windows 10, versão 1709
- Windows 10, versão 1703
- Windows 10 e Windows Server 2016
- Windows 8.1 and Windows Server 2012 R2
- Windows Server 2012
- Windows 7 SP1 e Windows Server 2008 R2 SP1
Usuários avançados também podem se referir ao log gerado por Windows Update para uma investigação mais aprofundada.
Você pode encontrar os seguintes cenários ao usar Windows Update.
Por que me ofereceram uma atualização mais antiga?
A atualização oferecida a um dispositivo depende de vários fatores. A seguir estão alguns dos atributos mais comuns:
- Compilação do sistema operacional
- Branch do sistema operacional
- Localidade do sistema operacional
- Arquitetura do sistema operacional
- Configuração de gerenciamento de atualização de dispositivo
Se a atualização oferecida não for a mais atual disponível, pode ser porque seu dispositivo está sendo gerenciado por um servidor WSUS e você está sendo oferecido as atualizações disponíveis nesse servidor. Também é possível, se o dispositivo faz parte de um grupo de implantação, que o administrador esteja atrasando intencionalmente a distribuição de atualizações. Como a implantação é lenta e medida para começar, todos os dispositivos não receberão a atualização no mesmo dia.
Meu dispositivo está congelado na verificação. Por quê?
A interface do usuário configurações se comunica com o serviço Do Orquestrador de Atualizações com o qual, por sua vez, se comunica com Windows Update serviço. Se esses serviços pararem inesperadamente, você poderá ver esse comportamento. Nesses casos, siga estas etapas:
Feche o aplicativo Configurações e reabra-o.
Inicie Services.msc e marcar se os seguintes serviços estiverem em execução:
- Atualizar o Orquestrador de Estado
- Windows Update
Atualizações de recursos não estão sendo oferecidas enquanto outras atualizações são
Dispositivos que executam Windows 10, versão 1709 até Windows 10, versão 1803 que estão configurados para atualizar de Windows Update (incluindo Windows Update for Business) são capazes de instalar atualizações de manutenção e definição, mas nunca são oferecidas atualizações de recursos.
Verificar o WindowsUpdate.log revela o seguinte erro:
YYYY/MM/DD HH:mm:ss:SSS PID TID Agent * START * Finding updates CallerId = Update;taskhostw Id = 25
YYYY/MM/DD HH:mm:ss:SSS PID TID Agent Online = Yes; Interactive = No; AllowCachedResults = No; Ignore download priority = No
YYYY/MM/DD HH:mm:ss:SSS PID TID Agent ServiceID = {855E8A7C-ECB4-4CA3-B045-1DFA50104289} Third party service
YYYY/MM/DD HH:mm:ss:SSS PID TID Agent Search Scope = {Current User}
YYYY/MM/DD HH:mm:ss:SSS PID TID Agent Caller SID for Applicability: S-1-12-1-2933642503-1247987907-1399130510-4207851353
YYYY/MM/DD HH:mm:ss:SSS PID TID Misc Got 855E8A7C-ECB4-4CA3-B045-1DFA50104289 redir Client/Server URL: https://fe3.delivery.mp.microsoft.com/ClientWebService/client.asmx""
YYYY/MM/DD HH:mm:ss:SSS PID TID Misc Token Requested with 0 category IDs.
YYYY/MM/DD HH:mm:ss:SSS PID TID Misc GetUserTickets: No user tickets found. Returning WU_E_NO_USERTOKEN.
YYYY/MM/DD HH:mm:ss:SSS PID TID Misc *FAILED* [80070426] Method failed [AuthTicketHelper::GetDeviceTickets:570]
YYYY/MM/DD HH:mm:ss:SSS PID TID Misc *FAILED* [80070426] Method failed [AuthTicketHelper::GetDeviceTickets:570]
YYYY/MM/DD HH:mm:ss:SSS PID TID Misc *FAILED* [80070426] GetDeviceTickets
YYYY/MM/DD HH:mm:ss:SSS PID TID Misc *FAILED* [80070426] Method failed [AuthTicketHelper::AddTickets:1092]
YYYY/MM/DD HH:mm:ss:SSS PID TID Misc *FAILED* [80070426] Method failed [CUpdateEndpointProvider::GenerateSecurityTokenWithAuthTickets:1587]
YYYY/MM/DD HH:mm:ss:SSS PID TID Misc *FAILED* [80070426] GetAgentTokenFromServer
YYYY/MM/DD HH:mm:ss:SSS PID TID Misc *FAILED* [80070426] GetAgentToken
YYYY/MM/DD HH:mm:ss:SSS PID TID Misc *FAILED* [80070426] EP:Call to GetEndpointToken
YYYY/MM/DD HH:mm:ss:SSS PID TID Misc *FAILED* [80070426] Failed to obtain service 855E8A7C-ECB4-4CA3-B045-1DFA50104289 plugin Client/Server auth token of type 0x00000001
YYYY/MM/DD HH:mm:ss:SSS PID TID ProtocolTalker *FAILED* [80070426] Method failed [CAgentProtocolTalkerContext::DetermineServiceEndpoint:377]
YYYY/MM/DD HH:mm:ss:SSS PID TID ProtocolTalker *FAILED* [80070426] Initialization failed for Protocol Talker Context
YYYY/MM/DD HH:mm:ss:SSS PID TID Agent Exit code = 0x80070426
YYYY/MM/DD HH:mm:ss:SSS PID TID Agent * END * Finding updates CallerId = Update;taskhostw Id = 25
O código de erro 0x80070426 se traduz em:
ERROR_SERVICE_NOT_ACTIVE - # The service has not been started.
O Assistente de Entrada da Conta da Microsoft (MSA ou wlidsvc) é o serviço em questão. O serviço DCAT Flighting (ServiceId: 855E8A7C-ECB4-4CA3-B045-1DFA50104289) depende do MSA para obter a ID do dispositivo global para o dispositivo. Sem o serviço MSA em execução, a ID global do dispositivo não será gerada e enviada pelo cliente e a pesquisa por atualizações de recursos nunca é concluída com êxito.
Para resolve esse problema, reinicie o serviço MSA para o StartType padrão de "manual".
Problemas relacionados ao HTTP/Proxy
Windows Update usa o WinHttp com solicitações de Intervalo Parcial (RFC 7233) para baixar atualizações e aplicativos de servidores Windows Update ou servidores WSUS locais. Portanto, os servidores proxy na rede devem dar suporte a solicitações DE INTERVALO HTTP. Se um proxy foi configurado na Internet Explorer (nível de usuário), mas não no WinHTTP (nível do sistema), as conexões com Windows Update falharão.
Para corrigir esse problema, configure um proxy no WinHTTP usando o seguinte comando netsh:
netsh winhttp set proxy ProxyServerName:PortNumber
Observação
Você também pode importar as configurações de proxy da Internet Explorer usando o seguinte comando: netsh winhttp import proxy source=ie.
Se os downloads por meio de um servidor proxy falharem com um erro de 0x80d05001 DO_E_HTTP_BLOCKSIZE_MISMATCH ou se você notar o alto uso da CPU durante o download das atualizações, marcar a configuração do proxy para permitir que as solicitações DE INTERVALO HTTP sejam executadas.
Você pode optar por aplicar uma regra para permitir solicitações DE INTERVALO HTTP para as seguintes URLs:
*.download.windowsupdate.com*.dl.delivery.mp.microsoft.com*.delivery.mp.microsoft.com
Se você não puder permitir solicitações range, você estará baixando mais conteúdo do que o necessário em atualizações (já que o patch delta não funcionará).
A atualização não é aplicável ao seu computador
Os motivos mais comuns para esse erro são descritos na tabela a seguir:
| Motivo | Explicação | Resolução |
|---|---|---|
| A atualização é substituída | À medida que as atualizações de um componente são lançadas, o componente atualizado substituirá um componente mais antigo que já está no sistema. Quando esse problema ocorre, a atualização anterior é marcada como substituída. Se a atualização que você está tentando instalar já tiver uma versão mais recente da carga em seu sistema, você poderá receber essa mensagem de erro. | Verifique se o pacote que você está instalando contém versões mais recentes dos binários. Ou, marcar que o pacote seja substituído por outro novo pacote. |
| A atualização já está instalada | Se a atualização que você está tentando instalar tiver sido instalada anteriormente, por exemplo, por outra atualização que tenha carregado a mesma carga, você poderá encontrar essa mensagem de erro. | Verifique se o pacote que você está tentando instalar não foi instalado anteriormente. |
| Atualização errada para arquitetura | Atualizações são publicados pela arquitetura da CPU. Se a atualização que você está tentando instalar não corresponder à arquitetura da sua CPU, você poderá encontrar essa mensagem de erro. | Verifique se o pacote que você está tentando instalar corresponde à versão do Windows que você está usando. As informações da versão do Windows podem ser encontradas na seção "Aplica-se" do artigo para cada atualização. Por exemplo, as atualizações somente Windows Server 2012 não podem ser instaladas em Windows Server 2012 computadores baseados em R2. Além disso, verifique se o pacote que você está instalando corresponde à arquitetura do processador da versão do Windows que você está usando. Por exemplo, uma atualização baseada em x86 não pode ser instalada em instalações baseadas em x64 do Windows. |
| Atualização de pré-requisito ausente | Algumas atualizações exigem uma atualização de pré-requisito para que possam ser aplicadas a um sistema. Se você estiver perdendo uma atualização de pré-requisito, poderá encontrar essa mensagem de erro. Por exemplo, o 2919355 KB deve ser instalado em computadores Windows 8.1 e Windows Server 2012 R2 antes que muitas das atualizações lançadas após abril de 2014 possam ser instaladas. | Verifique os artigos relacionados sobre o pacote na KB (Base de Conhecimento da Microsoft) para verificar se você tem as atualizações de pré-requisito instaladas. Por exemplo, se você encontrar a mensagem de erro no Windows 8.1 ou Windows Server 2012 R2, talvez seja necessário instalar a atualização de abril de 2014 2919355 como um pré-requisito e uma ou mais atualizações de manutenção de pré-requisito (2919442 de KB e 3173424 de KB). Para determinar se essas atualizações de pré-requisito estão instaladas, execute o seguinte comando do PowerShell: get-hotfix KB3173424,KB2919355, KB2919442. Se as atualizações forem instaladas, o comando retornará a data instalada na InstalledOn seção da saída. |
Problemas relacionados à configuração de firewall
Erro que você pode ver em logs de Windows Update:
DownloadManager Error 0x800706d9 occurred while downloading update; notifying dependent calls.
Ou
[DownloadManager] BITS job {A4AC06DD-D6E6-4420-8720-7407734FDAF2} hit a transient error, updateId = {D053C08A-6250-4C43-A111-56C5198FE142}.200 <NULL>, error = 0x800706D9
Ou
DownloadManager [0]12F4.1FE8::09/29/2017-13:45:08.530 [agent]DO job {C6E2F6DC-5B78-4608-B6F1-0678C23614BD} hit a transient error, updateId = 5537BD35-BB74-40B2-A8C3-B696D3C97CBA.201 <NULL>, error = 0x80D0000A
Acesse Services.msc e verifique se o Serviço de Firewall do Windows está habilitado. A interrupção do serviço associado ao Firewall do Windows com a Segurança Avançada não tem suporte da Microsoft. Para obter mais informações, consulte Preciso desabilitar o Firewall do Windows.
Problemas decorrentes da configuração de políticas conflitantes
Windows Update fornece uma política de configuração de amplo alcance para controlar o comportamento do serviço de Windows Update em um ambiente gerenciado. Embora essas políticas permitem configurar as configurações em um nível granular, a configuração incorreta ou a configuração de políticas conflitantes podem levar a comportamentos inesperados.
Para obter mais informações, consulte Como configurar atualizações automáticas usando Política de Grupo ou configurações de registro.
O dispositivo não pode acessar arquivos de atualização
Verifique se os dispositivos podem alcançar os pontos de extremidade necessários Windows Update por meio do firewall. Por exemplo, para Windows 10, versão 2004, os seguintes protocolos devem ser capazes de alcançar esses respectivos pontos de extremidade:
| Protocolo | URL de ponto de extremidade |
|---|---|
| TLS 1.2 | *.prod.do.dsp.mp.microsoft.com |
| HTTP | emdl.ws.microsoft.com |
| HTTP | *.dl.delivery.mp.microsoft.com |
| HTTP | *.windowsupdate.com |
| HTTPS | *.delivery.mp.microsoft.com |
| TLS 1.2 | *.update.microsoft.com |
| TLS 1.2 | tsfe.trafficshaping.dsp.mp.microsoft.com |
Observação
Não use HTTPS para os pontos de extremidade que especificam HTTP e vice-versa. A conexão falhará.
Os pontos de extremidade específicos podem variar entre as versões do cliente do Windows. Consulte, por exemplo, Windows 10 pontos de extremidade de conexão enterprise 2004. Artigos semelhantes para outras versões de cliente do Windows estão disponíveis na tabela de conteúdo nas proximidades.
Atualizações não estão baixando do ponto de extremidade da intranet (WSUS ou Configuration Manager)
Os dispositivos cliente Windows podem receber atualizações de várias fontes, incluindo Windows Update online, um servidor Windows Server Update Services e outros. Para determinar a origem do Windows Atualizações que está sendo usado atualmente em um dispositivo, siga estas etapas:
Inicie Windows PowerShell como administrador.
Execute o cmdlet:
$MUSM = New-Object -ComObject "Microsoft.Update.ServiceManager"Execute o cmdlet:
$MUSM.Services
Verifique a saída dos parâmetros Name e OffersWindowsUPdates, que você pode interpretar de acordo com esta tabela.
Você tem uma configuração ruim no ambiente
Neste exemplo, de acordo com o Política de Grupo definido por meio do registro, o sistema é configurado para usar o WSUS para baixar atualizações (observe a segunda linha):
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU]
"UseWUServer"=dword:00000001
De logs de Windows Update:
2018-08-06 09:33:31:085 480 1118 Agent ** START ** Agent: Finding updates [CallerId = OperationalInsight Id = 49]
2018-08-06 09:33:31:085 480 1118 Agent *********
2018-08-06 09:33:31:085 480 1118 Agent * Include potentially superseded updates
2018-08-06 09:33:31:085 480 1118 Agent * Online = No; Ignore download priority = No
2018-08-06 09:33:31:085 480 1118 Agent * Criteria = "IsHidden = 0 AND DeploymentAction=*"
2018-08-06 09:33:31:085 480 1118 Agent * ServiceID = {00000000-0000-0000-0000-000000000000} Third party service
2018-08-06 09:33:31:085 480 1118 Agent * Search Scope = {Machine}
2018-08-06 09:33:32:554 480 1118 Agent * Found 83 updates and 83 categories in search; evaluated appl. rules of 517 out of 1473 deployed entities
2018-08-06 09:33:32:554 480 1118 Agent *********
2018-08-06 09:33:32:554 480 1118 Agent ** END ** Agent: Finding updates [CallerId = OperationalInsight Id = 49]
No snippet de log acima, vemos que o Criteria = "IsHidden = 0 AND DeploymentAction=*". "*" significa que não há nada especificado do servidor. Portanto, a verificação acontece, mas não há direção para baixar ou instalar no agente. Portanto, ele apenas examina a atualização e fornece os resultados.
Conforme mostrado nos logs a seguir, a atualização automática executa a verificação e não encontra nenhuma atualização aprovada para ela. Portanto, ele informa que não há atualizações para instalar ou baixar. Isso ocorre devido a uma configuração incorreta. O lado do WSUS deve aprovar as atualizações para Windows Update para que ele busque as atualizações e as instale no momento especificado de acordo com a política. Como esse cenário não inclui Configuration Manager, não há como instalar atualizações não aprovadas. Você espera que o agente de insights operacionais faça a verificação e acione automaticamente o download e a instalação, mas isso não acontecerá com essa configuração.
2018-08-06 10:58:45:992 480 5d8 Agent ** START ** Agent: Finding updates [CallerId = AutomaticUpdates Id = 57]
2018-08-06 10:58:45:992 480 5d8 Agent *********
2018-08-06 10:58:45:992 480 5d8 Agent * Online = Yes; Ignore download priority = No
2018-08-06 10:58:45:992 480 5d8 Agent * Criteria = "IsInstalled=0 and DeploymentAction='Installation' or IsPresent=1 and DeploymentAction='Uninstallation' or IsInstalled=1 and DeploymentAction='Installation' and RebootRequired=1 or IsInstalled=0 and DeploymentAction='Uninstallation' and RebootRequired=1"
2018-08-06 10:58:46:617 480 5d8 PT + SyncUpdates round trips: 2
2018-08-06 10:58:47:383 480 5d8 Agent * Found 0 updates and 83 categories in search; evaluated appl. rules of 617 out of 1473 deployed entities
2018-08-06 10:58:47:383 480 5d8 Agent Reporting status event with 0 installable, 83 installed, 0 installed pending, 0 failed and 0 downloaded updates
2018-08-06 10:58:47:383 480 5d8 Agent *********
2018-08-06 10:58:47:383 480 5d8 Agent ** END ** Agent: Finding updates [CallerId = AutomaticUpdates Id = 57]
Alto uso de largura de banda no cliente Windows por Windows Update
Os usuários podem ver que o Windows está consumindo toda a largura de banda nos diferentes escritórios no contexto do sistema. Este é o comportamento padrão. Componentes que podem consumir largura de banda expandem além de componentes Windows Update.
As seguintes políticas de grupo podem ajudar a atenuar essa situação:
- Bloquear o acesso a servidores Windows Update: Política Desativar o acesso a todos os recursos de Windows Update (Definido como habilitado)
- Pesquisa de driver: Política Especificar ordem de pesquisa para locais de origem do driver de dispositivo (Definido como "Não pesquise Windows Update")
- Atualização automática da Windows Store: Política Desativar Download Automático e Instalação de atualizações (Definido como habilitado)
Outros componentes que se conectam à Internet:
- Destaque do Windows: Política Configurar os holofotes do Windows na tela de bloqueio (Definido como desabilitado)
- Experiências do consumidor: Política Desativar experiências do consumidor da Microsoft (Definida como habilitada)
- Tráfego em segundo plano de aplicativos windows: política Permitir que aplicativos Windows sejam executados em segundo plano
Erros transitórios causados por carga pesada ou congestionamento de rede
Os usuários podem receber os seguintes erros de Windows Update. Esses erros são erros transitórios, ocorrendo quando o serviço está temporariamente sob carga pesada ou quando as redes estão congestionadas. Os usuários não precisam tomar nenhuma ação porque o dispositivo tentará novamente a operação mais tarde.
| Código de erro | Valor de erro | Detalhes |
|---|---|---|
| WU_S_SEARCH_LOAD_SHEDDING | 0x248001 | A operação de pesquisa foi concluída com êxito, mas um ou mais serviços estavam perdendo carga. |
| WU_E_PT_LOAD_SHEDDING | 0x8024402d | O servidor está perdendo carga. |
Nesses casos, os usuários que programaticamente chamam a API do agente Windows Update para recuperar o resultado de uma operação de pesquisa obteriam orcFailed ou orcSucceededWithErrors. Espera-se que novamente a operação seja bem-sucedida.
Coleta de dados
Se você precisar de ajuda do suporte da Microsoft, recomendamos coletar as informações seguindo as etapas mencionadas em Coletar informações usando o TSS para problemas relacionados à implantação.