Observação
- Data de publicação original: 19 de março de 2026
- ID da base de dados: 5085046
Neste artigo
- Visão geral
- Como funciona uma manutenção de certificado de Inicialização Segura
- Por onde começar ao solucionar problemas
- Tarefa agendada de Inicialização Segura e Atualização
- Por que uma tarefa agendada é usada
- A máscara de bits do Registro AvailableUpdates
- Integração com firmware OEM
- Cenários e resoluções comuns de falhas
- Referência e internos
- AvailableUpdates bits usados para manutenção de certificado
- Progressão esperada (AvailableUpdates)
- Procedimentos de correção
- Habilitando a Inicialização Segura no firmware
- Tarefa agendada de Inicialização Segura desabilitada ou excluída
Visão geral
Esta página orienta os administradores e profissionais de suporte no diagnóstico e na resolução de problemas relacionados à Inicialização Segura em dispositivos Windows. Os tópicos incluem falhas de atualização de certificado de Inicialização Segura, estados incorretos de Inicialização Segura, prompts de recuperação inesperados do BitLocker e falhas de inicialização após alterações de configuração da Inicialização Segura.
As diretrizes explicam como verificar a manutenção e a configuração do Windows, examinar os valores relevantes do Registro e logs de eventos e identificar quando as limitações de firmware ou plataforma exigem uma atualização de OEM. Este conteúdo destina-se a diagnosticar problemas em dispositivos existentes. Ela não se destina ao planejamento de novas implantações. Este documento será atualizado à medida que novos cenários e diretrizes de solução de problemas forem identificados.
Como funciona a manutenção de certificado de Inicialização Segura
A manutenção de certificado de Inicialização Segura no Windows é um processo coordenado entre o sistema operacional e o firmware UEFI de um dispositivo. O objetivo é atualizar âncoras de confiança críticas, preservando a capacidade de inicialização em cada estágio.
O processo é orientado por uma tarefa agendada do Windows, uma sequência de ações de atualização baseada no registro e um comportamento interno de log e repetição. Juntos, esses componentes garantem que os certificados de Inicialização Segura e o gerenciador de inicialização do Windows sejam atualizados de maneira controlada e ordenada e somente depois que as etapas de pré-requisito forem bem-sucedidas.
Por onde começar ao solucionar problemas
Quando um dispositivo não parece estar fazendo o progresso esperado ao aplicar atualizações de certificado de Inicialização Segura, comece identificando a categoria do problema. A maioria dos problemas se enquadra em uma das quatro áreas: estado de manutenção do Windows, mecanismo de atualização de Inicialização Segura, comportamento do firmware ou uma limitação de plataforma ou OEM.
Comece com as verificações abaixo, em ordem. Em muitos casos, essas etapas são suficientes para explicar o comportamento observado e determinar as próximas ações sem uma investigação mais profunda.
Confirmar a qualificação para a manutenção e a plataforma do Windows
- Verifique se o dispositivo atende aos requisitos básicos para receber atualizações de certificado de Inicialização Segura:
- O dispositivo está executando uma versão com suporte do Windows.
- As últimas atualizações de segurança necessárias do Windows estão instaladas.
- A Inicialização Segura está habilitada no firmware UEFI.
- Se alguma dessas condições não for atendida, resolva-as antes de continuar com a solução de problemas.
Verificar o status da tarefa Secure-Boot-Update
- Confirme se o mecanismo do Windows responsável por aplicar as atualizações de certificado de Inicialização Segura está presente e funcionando:
- A tarefa agendada Secure-Boot-Update existe.
- A tarefa é habilitada e executada como Sistema Local.
- A tarefa foi executada pelo menos uma vez desde que a atualização de segurança mais recente do Windows foi instalada.
- Se a tarefa estiver desabilitada, excluída ou não estiver em execução, as atualizações de certificado do Secure Boot não poderão ser aplicadas. A solução de problemas deve se concentrar na restauração da tarefa antes de investigar outras causas.
Verifique as configurações do Registro para a progressão esperada
Examine o estado de manutenção de Inicialização Segura do dispositivo no Registro:- Examine UEFICA2023Status, UEFICA2023Error e UEFICA2023ErrorEvent.
- Examine AvailableUpdates e compare-o com a progressão esperada (consulte Referência e Internos).
Juntos, esses valores indicam se a manutenção está progredindo normalmente, repetindo uma operação ou interrompida em uma etapa específica.
Correlacionar o estado do Registro com eventos de Inicialização Segura
Examine os eventos relacionados à inicialização segura no log de eventos do sistema e correlacione-os com o estado do registro. Os dados de evento normalmente confirmam se o dispositivo está progredindo, tentando novamente devido a uma condição transitória ou bloqueado por um problema de firmware ou plataforma.
Juntos, os logs do Registro e de eventos geralmente indicam se o comportamento é esperado, temporário ou requer ação corretiva.
Tarefa agendada de Inicialização Segura e Atualização
A manutenção de certificado de Inicialização Segura é implementada por meio de uma tarefa agendada do Windows chamada Secure-Boot-Update. A tarefa é registrada no seguinte caminho:
Observação
\Microsoft\Windows\PI\Secure-Boot-Update
A tarefa é executada como Sistema Local. Por padrão, ele é executado na inicialização do sistema e a cada 12 horas depois disso. Sempre que é executado, ele verifica se as ações de atualização do Secure Boot estão pendentes e tenta aplicá-las em sequência.
Se essa tarefa estiver desabilitada ou ausente, as atualizações de certificado do Secure Boot não poderão ser aplicadas. A tarefa Secure-Boot-Update deve permanecer habilitada para que a manutenção de inicialização segura funcione.
Por que uma tarefa agendada é usada
As atualizações de certificado de Inicialização Segura exigem coordenação entre o firmware Windows e UEFI, incluindo a gravação de variáveis UEFI que armazenam chaves e certificados de Inicialização Segura. Uma tarefa agendada permite que o Windows tente essas atualizações quando o sistema está em um estado em que as variáveis de firmware podem ser modificadas.
A programação recorrente de 12 horas oferece oportunidades adicionais para repetir as atualizações se uma tentativa anterior falhar ou se o dispositivo permanecer ligado sem reiniciar. Esse design ajuda a garantir o progresso sem exigir intervenção manual.
A máscara de bits do Registro AvailableUpdates
A tarefa de Atualização de Inicialização Segura é controlada pelo valor do Registro AvailableUpdates . Esse valor é uma máscara de bits de 32 bits localizada em:
Observação
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot
Cada bit no valor representa uma ação específica de atualização da Inicialização Segura. O processo de atualização começa quando AvailableUpdates é definido com um valor diferente de zero, automaticamente pelo Windows ou explicitamente por um administrador. Por exemplo, um valor como 0x5944 indica que várias ações de atualização estão pendentes.
Quando a tarefa Secure-Boot-Update é executada, ela interpreta os bits definidos como trabalho pendente e os processa em uma ordem definida.
Atualizações sequenciais, registro em log e comportamento de novo teste
As atualizações de certificado de Inicialização Segura são aplicadas em uma ordem fixa. Cada ação de atualização foi projetada para ser segura para tentar novamente e é concluída independentemente. A tarefa Secure-Boot-Update não avança para a próxima etapa até que a ação atual seja bem-sucedida e seu bit correspondente seja removido de AvailableUpdates.
Cada operação usa interfaces UEFI padrão para atualizar variáveis de Inicialização Segura, como o DB e a KEK, ou para instalar o gerenciador de inicialização atualizado do Windows. O Windows registra o resultado de cada etapa no log de eventos do sistema. Os eventos de êxito confirmam o progresso para a frente, enquanto os eventos de falha indicam por que uma ação não pôde ser concluída.
Se uma etapa de atualização falhar, a tarefa interromperá o processamento, registrará o erro em log e deixará o conjunto de bits associado. A operação será repetida na próxima vez que a tarefa for executada. Esse comportamento de nova avaliação permite que os dispositivos se recuperem automaticamente de condições temporárias, como falta de suporte de firmware ou atualizações de OEM atrasadas.
Os administradores podem acompanhar o progresso correlacionando o estado do registro com as entradas do log de eventos. Valores de registro como UEFICA2023Status, UEFICA2023Error e UEFICA2023ErrorEvent, juntamente com a máscara de bits AvailableUpdates , indicam qual etapa está ativa, concluída ou bloqueada.
Essa combinação mostra se o dispositivo está progredindo normalmente, repetindo uma operação ou parado.
Integração com firmware OEM
As atualizações de certificado de Inicialização Segura dependem do comportamento correto e do suporte no firmware UEFI de um dispositivo. Enquanto o Windows orquestra o processo de atualização, o firmware é responsável por impor a política de Inicialização Segura e manter os bancos de dados de Inicialização Segura.
Os OEMs fornecem dois elementos críticos que permitem a manutenção de certificado de Inicialização Segura:
- Chaves de Troca de Chaves assinadas por Chave de Plataforma (KEKs) que autorizam a instalação de novos certificados de Inicialização Segura.
- Implementações de firmware que preservam, acrescentam e validam corretamente os bancos de dados de Inicialização Segura durante as atualizações.
Se o firmware não der suporte total a esses comportamentos, as atualizações de Inicialização Segura poderão parar, tentar novamente indefinidamente ou resultar em falhas de inicialização. Nesses casos, o Windows não pode concluir a atualização sem alterações no firmware.
A Microsoft trabalha com OEMs para identificar problemas de firmware e disponibilizar atualizações corrigidas. Quando a solução de problemas indica uma limitação ou defeito de firmware, os administradores podem precisar instalar a atualização de firmware UEFI mais recente fornecida pelo fabricante do dispositivo antes que as atualizações de certificado de Inicialização Segura possam ser concluídas com êxito.
Cenários e resoluções comuns de falhas
As atualizações de Inicialização Segura são aplicadas pela tarefa agendada Secure-Boot-Update com base no estado do Registro AvailableUpdates .
Em condições normais, essas etapas ocorrem automaticamente e registram eventos bem-sucedidos à medida que cada etapa é concluída. Em alguns casos, o comportamento do firmware, a configuração da plataforma ou os pré-requisitos de manutenção podem impedir o progresso ou levar a um comportamento inesperado da inicialização.
As seções a seguir descrevem os cenários de falha mais comuns, como reconhecê-los, por que ocorrem e as próximas etapas apropriadas para restaurar a operação normal. Os cenários são ordenados dos casos mais comumente encontrados para os casos mais graves que afetam a inicialização.
Atualizações de Inicialização Segura não se aplicam (sem progresso)
Quando as atualizações de Inicialização Segura não mostram progresso, normalmente significa que o processo de atualização nunca foi iniciado. Como resultado, os valores esperados do Registro de Inicialização Segura e os logs de eventos estão ausentes porque o mecanismo de atualização nunca foi acionado.
O que aconteceu
O processo de atualização da Inicialização Segura não foi iniciado, portanto, nenhum certificado da Inicialização Segura ou o gerenciador de inicialização atualizado foram aplicados ao dispositivo.
Como reconhecê-lo
- Nenhum valor de registro de serviço de Inicialização Segura está presente, como UEFICA2023Status.
- Os eventos de Inicialização Segura esperados (por exemplo, 1043, 1044, 1045, 1799, 1801) estão ausentes no log de eventos do sistema.
- O dispositivo continua usando certificados e componentes de inicialização de inicialização mais antigos.
Por que isso acontece
Esse cenário geralmente ocorre quando uma ou mais das seguintes condições são verdadeiras:
- A tarefa agendada Secure-Boot-Update está desabilitada ou ausente.
- A Inicialização Segura está desabilitada no firmware UEFI.
- O dispositivo não atende aos pré-requisitos de manutenção do Windows, como executar uma versão compatível do Windows ou ter as atualizações necessárias instaladas.
O que fazer
- Verifique se o dispositivo atende aos requisitos de manutenção e qualificação da plataforma do Windows.
- Confirme se a Inicialização Segura está habilitada no firmware.
- Verifique se a tarefa agendada SecureBootUpdate existe e está habilitada.
Se a tarefa agendada estiver desabilitada ou ausente, siga as orientações em Tarefa agendada de inicialização segura desabilitada ou excluída para restaurá-la. Depois que a tarefa for restaurada, reinicie o dispositivo ou execute a tarefa manualmente para iniciar a manutenção de Inicialização Segura.
O dispositivo é inicializado na recuperação do BitLocker após a atualização da Inicialização Segura
Em alguns casos, as atualizações relacionadas à Inicialização Segura podem fazer com que um dispositivo entre na recuperação do BitLocker. O comportamento pode ser transitório ou persistente, dependendo da causa subjacente.
Cenário 1: recuperação única do BitLocker após a atualização da Inicialização Segura
O que acontece
O dispositivo entra na recuperação do BitLocker na primeira inicialização após a atualização da Inicialização Segura, mas inicializa normalmente nas reinicializações subsequentes.
Por que isso acontece
Durante a primeira inicialização após a atualização, o firmware ainda não relata os valores atualizados de Inicialização Segura quando o Windows tenta selar novamente o BitLocker. Isso causa uma incompatibilidade temporária nos valores de inicialização medidos e aciona a recuperação. Na próxima inicialização, o firmware relata os valores atualizados corretamente, o BitLocker é selado novamente com êxito e o problema não se repeti.
Como reconhecê-lo
- A recuperação do BitLocker ocorre uma vez.
- Depois de inserir a chave de recuperação, as inicializações subsequentes não solicitam a recuperação.
- Nenhuma ordem de inicialização em andamento ou envolvimento PXE está presente.
O que fazer
- Insira a chave de recuperação do BitLocker para retomar o Windows.
- Verifique se há atualizações de firmware.
Cenário 2: recuperação repetida do BitLocker devido à primeira configuração de inicialização do PXE
O que acontece
O dispositivo entra na recuperação do BitLocker em cada inicialização.
Por que isso acontece
O dispositivo está configurado para tentar a inicialização PXE (rede) primeiro. A tentativa de inicialização PXE falha, e o firmware retorna para o gerenciador de inicialização do Windows no disco.
Isso resulta em duas autoridades de assinatura diferentes sendo medidas durante um único ciclo de inicialização:
- O caminho de inicialização PXE é assinado pelo Microsoft UEFI CA 2011.
- O gerenciador de inicialização do Windows no disco é assinado pelo UEFI CA 2023 do Windows.
Como o BitLocker observa cadeias de confiança de Inicialização Segura diferentes durante a inicialização, ele não pode estabelecer um conjunto estável de medidas de TPM para selar novamente. Como resultado, o BitLocker entra na recuperação em cada inicialização.
Como reconhecê-lo
- A recuperação do BitLocker é disparada em cada reinicialização.
- Inserir a chave de recuperação permite que o Windows seja iniciado, mas o prompt retorna na próxima inicialização.
- O PXE ou a inicialização de rede são configurados antes do disco local na ordem de inicialização do firmware.
O que fazer
- Configure a ordem de inicialização do firmware, de modo que o gerenciador de inicialização do Windows no disco seja o primeiro.
- Desabilite a inicialização PXE se não for necessária.
- Se o PXE for necessário, verifique se a infraestrutura PXE usa um carregador de inicialização do Windows assinado em 2023.
O dispositivo falha ao inicializar após redefinir a Inicialização Segura
O que aconteceu
Isso reflete uma alteração no nível do firmware, e não um problema do Windows. A atualização de Inicialização Segura foi concluída com êxito, mas após uma reinicialização posterior, o dispositivo não inicializa mais no Windows.
Como reconhecê-lo
- O dispositivo não consegue iniciar o Windows e pode exibir uma mensagem de firmware ou BIOS indicando uma violação da Inicialização Segura.
- A falha ocorre depois que as configurações de Inicialização Segura são redefinidas para os padrões de firmware.
- Desabilitar a Inicialização Segura pode permitir que o dispositivo inicialize novamente.
Por que isso acontece
Redefinir a Inicialização Segura para os padrões de firmware limpa os bancos de dados de Inicialização Segura armazenados no firmware. Em dispositivos que já fizeram a transição para o gerenciador de inicialização assinado pelo Windows UEFI CA 2023, essa redefinição remove os certificados necessários para confiar nesse gerenciador de inicialização.
Como resultado, o firmware não reconhece mais o gerenciador de inicialização do Windows instalado como confiável e bloqueia o processo de inicialização.
Esse cenário não é causado pela atualização da Inicialização Segura em si, mas por uma ação de firmware subsequente que remove as âncoras de confiança atualizadas.
O que fazer
- Use o utilitário de recuperação de Inicialização Segura para restaurar o certificado necessário, para que o dispositivo possa ser inicializado novamente.
- Após a recuperação, certifique-se de que o dispositivo tenha o firmware mais recente disponível instalado pelo fabricante do dispositivo.
- Evite redefinir a Inicialização Segura para os padrões de firmware, a menos que o firmware OEM inclua padrões de Inicialização Segura atualizados que confiem nos certificados de 2023.
Utilitário de recuperação de Inicialização Segura
Para recuperar o sistema:
- Em um segundo computador Windows com a atualização de julho de 2024 ou mais recente instalada, copie SecureBootRecovery.efi de C:\Windows\Boot\EFI\.
- Coloque o arquivo em uma unidade USB formatada em FAT32 em \EFI\BOOT\ e renomeie-o para bootx64.efi.
- Inicialize o dispositivo afetado a partir da unidade USB e permita a execução do utilitário de recuperação. O utilitário adicionará o UEFI CA 2023 do Windows ao DB.
Depois que o certificado for restaurado e o sistema for reiniciado, o Windows deverá ser iniciado normalmente.
Importante: Esse processo reaplicará apenas um dos novos certificados. Depois que o dispositivo for recuperado, verifique se os certificados mais recentes foram reaplicados e considere atualizar o BIOS/UEFI do sistema para a versão mais recente disponível. Isso pode ajudar a evitar a recorrência do problema de redefinição da Inicialização Segura, pois muitos OEMs lançaram correções de firmware para esse problema específico.
O dispositivo falha ao inicializar após a atualização da Inicialização Segura devido ao firmware sobrescrever o banco de dados
O que aconteceu
Depois de aplicar a atualização do certificado de Inicialização Segura e reiniciar, o dispositivo falha ao inicializar e não chega ao Windows.
Como reconhecê-lo
- O dispositivo falha imediatamente após a reinicialização exigida pela atualização da Inicialização Segura.
- Um erro de firmware ou Inicialização Segura pode ser exibido ou o sistema pode parar antes que o Windows seja carregado.
- Desabilitar a Inicialização Segura pode permitir que o dispositivo inicialize.
Por que isso acontece
Esse problema pode ser causado por um defeito na implementação do firmware UEFI do dispositivo.
Quando o Windows aplica atualizações de certificado de Inicialização Segura, espera-se que o firmware acrescente novos certificados ao banco de dados de assinatura permitida (DB) de Inicialização Segura existente. Algumas implementações de firmware substituem incorretamente o banco de dados em vez de anexá-lo.
Quando isso ocorre,
- Certificados anteriormente confiáveis, incluindo o certificado do carregador de inicialização Microsoft 2011, foram removidos.
- Se o sistema ainda estiver usando um gerenciador de inicialização assinado com o certificado de 2011 nesse ponto, o firmware não confiará mais nele.
- O firmware rejeita o gerenciador de inicialização e bloqueia o processo de inicialização.
Em alguns casos, o banco de dados também pode ser corrompido em vez de ser substituído de forma limpa, levando ao mesmo resultado. Esse comportamento foi observado em implementações de firmware específicas e não é esperado em firmwares compatíveis.
O que fazer
- Entre nos menus de configuração de firmware e tente redefinir as configurações de Inicialização Segura.
- Se o dispositivo for inicializado após a redefinição, marque o site de suporte do fabricante do dispositivo para obter uma atualização de firmware que corrija o manuseio do Banco de Dados de Inicialização Segura.
- Se uma atualização de firmware estiver disponível, instale-a antes de reabilitar a Inicialização Segura e reaplicar as atualizações de certificado da Inicialização Segura.
Se redefinir a Inicialização Segura não restaurar a funcionalidade de inicialização, a recuperação adicional provavelmente exigirá diretrizes específicas do OEM.
Atualização de Inicialização Segura bloqueada devido à falta de KEK assinada pelo OEM
O que aconteceu
A atualização do certificado de Inicialização Segura não foi concluída e permanece bloqueada no estágio de atualização da KEK (Chave de Troca de Chave).
Como reconhecê-lo
- O valor do Registro AvailableUpdates permanece definido com o bit KEK (0x0004) e não é limpo.
- UEFICA2023Status não avança para um estado concluído.
- O log de eventos do sistema registra repetidamente a ID do Evento 1803, indicando que a atualização do KEK não pôde ser aplicada.
- O dispositivo continua tentando novamente a atualização sem fazer progresso.
Por que isso acontece
A atualização da KEK de Inicialização Segura requer autorização da PK (Chave da Plataforma) do dispositivo, que pertence ao OEM.
Para que a atualização tenha êxito, o fabricante do dispositivo deve fornecer à Microsoft uma KEK assinada por PK para essa plataforma específica. Essa KEK assinada pelo OEM está incluída nas atualizações do Windows e permite que o Windows atualize a variável KEK de firmware.
Se o OEM não tiver fornecido uma KEK assinada por PK para o dispositivo, o Windows não poderá concluir a atualização da KEK. Nesse estado:
- As atualizações de Inicialização Segura são bloqueadas por padrão.
- O Windows não pode contornar a autorização ausente.
- O dispositivo pode permanecer permanentemente incapaz de concluir a manutenção do certificado de Inicialização Segura.
Isso pode ocorrer em dispositivos mais antigos ou sem suporte em que o OEM não fornece mais firmware ou atualizações de chave. Não há caminho de recuperação manual com suporte para essa condição.
Eventos de atualização de certificado e indicadores de falha do Secure Boot
Quando as atualizações de certificado de Inicialização Segura não são aplicadas, o Windows registra eventos de diagnóstico que explicam por que o progresso foi bloqueado. Esses eventos são gravados quando a atualização do banco de dados (DB) de assinatura de Inicialização Segura ou da KEK (Key Exchange Key) não pode ser concluída com segurança devido ao firmware, ao estado da plataforma ou às condições de configuração. Os cenários nesta seção fazem referência a esses eventos para identificar padrões de falha comuns e determinar a correção apropriada. Esta seção destina-se ao diagnóstico e à interpretação dos problemas descritos anteriormente, e não à introdução de novos cenários de falha.
Para obter uma lista completa de IDs de eventos, descrições e entradas de exemplo, consulte Eventos de atualização de variável do Banco de Dados de Inicialização Segura e DBX (KB5016061).
Falha na atualização do KEK (atualizações do banco de dados são bem-sucedidas, o KEK não)
Um dispositivo pode atualizar certificados com êxito no DB de Inicialização Segura, mas falha durante a atualização do KEK. Quando isso ocorre, o processo de atualização da Inicialização Segura não pode ser concluído.
Sintomas
- Eventos de certificado de banco de dados indicam progresso, mas o estágio KEK não foi concluído.
- AvailableUpdates permanece definido como 0x4004 e o bit 0x0004 não é limpo após várias execuções de tarefas.
- O evento 1795 ou 1803 pode estar presente.
Interpretação
- 1795 normalmente indica falha de firmware ao tentar atualizar uma variável de Inicialização Segura.
- O 1803 indica que a atualização da KEK não pode ser autorizada porque uma carga KEK assinada por PK do OEM necessária não está disponível para a plataforma.
Próximas etapas
- Para 1795, Marque se há atualizações de firmware OEM e valide o suporte de firmware para atualizações de variáveis de Inicialização Segura.
- Para 1803, confirme se o OEM forneceu à Microsoft o KEK assinado por PK necessário para o modelo do dispositivo.
Falha de atualização do KEK em VMs Convidadas hospedadas no Hyper-V
Em máquinas virtuais Hyper-V, as atualizações de certificado de Inicialização Segura exigem que as atualizações do Windows de março de 2026 sejam instaladas no host Hyper-V e no sistema operacional convidado.
As falhas de atualização são relatadas dentro do convidado, mas o evento indica onde a correção é necessária:
- O evento 1795 (por exemplo, "A mídia está protegida contra gravação") relatado no convidado indica que o host Hyper-V não tem a atualização de março de 2026 e deve ser atualizado.
- O evento 1803 relatado no convidado indica que a própria máquina virtual convidada não tem a atualização de março de 2026 e deve ser atualizada.
Referência e internos
Esta seção contém informações de referência avançadas destinadas à solução de problemas e suporte. Ele não se destina ao planejamento de implantação. Ele expande a mecânica de manutenção de Inicialização Segura resumida anteriormente e fornece material de referência detalhado para interpretar o estado do registro e os logs de eventos.
Observação (implantações gerenciadas pela TI): quando configuradas por meio da Política de Grupo ou do Microsoft Intune, duas configurações semelhantes não devem ser confundidas. O valor AvailableUpdatesPolicy representa o estado da política configurada. Enquanto isso, AvailableUpdates reflete o estado de trabalho em andamento e limpeza de bits. Ambos podem gerar o mesmo resultado, mas se comportam de maneira diferente porque a política se reaplica ao longo do tempo.
AvailableUpdates bits usados para manutenção de certificado
Os bits abaixo são usados para as ações do gerenciador de certificados e inicialização descritas neste documento. A coluna Pedido reflete a sequência na qual a tarefa Secure-Boot-Update processa cada bit.
| Ordem | Configuração de bits | Utilização |
|---|---|---|
| 1 | 0x0040 | Esse bit informa a tarefa agendada para adicionar o certificado UEFI CA 2023 do Windows ao Banco de Dados de Inicialização Segura. Isso permite que o Windows confie em gerenciadores de inicialização assinados por esse certificado. |
| 2 | 0x0800 | Este bit informa a tarefa agendada para aplicar a Microsoft Option ROM UEFI CA 2023 ao banco de dados. Comportamento condicional: quando o sinalizador 0x4000 for definido, a tarefa agendada primeiro marcar o banco de dados para o certificado UEFI CA 2011 da Microsoft Corporation. Ele aplicará o certificado Microsoft Option ROM UEFI CA 2023somente se o certificado de 2011 estiver presente. |
| 3 | 0x1000 | Esse bit informa à tarefa agendada para aplicar o Microsoft UEFI CA 2023 ao DB. Comportamento condicional: quando o sinalizador 0x4000 for definido, a tarefa agendada primeiro marcar o banco de dados para o certificado UEFI CA 2011 da Microsoft Corporation. Ele aplicará o certificado Microsoft UEFI CA 2023somente se o certificado de 2011 estiver presente. |
| Modificador (sinalizador de comportamento) | 0x4000 | Esse bit modifica o comportamento dos bits de 0x0800 e 0x1000 para que o Microsoft UEFI CA 2023 e a Microsoft Option ROM UEFI CA 2023 sejam aplicados somente se o DB já contiver o Microsoft Corporation UEFI CA 2011. Para ajudar a garantir que o perfil de segurança do dispositivo permaneça o mesmo, esse bit só aplica esses novos certificados se o dispositivo confiar no certificado UEFI CA 2011 da Microsoft Corporation. Nem todos os dispositivos Windows confiam nesse certificado. |
| 4 | 0x0004 | Esse bit informa à tarefa agendada para procurar uma Chave de Troca de Chaves assinada pela PK (Chave de Plataforma) do dispositivo. O PK é gerenciado pelo OEM. Os OEMs assinam o Microsoft KEK com seu PK e o entregam à Microsoft, onde ele está incluído nas atualizações cumulativas mensais. |
| 5 | 0x0100 | Esse bit informa à tarefa agendada para aplicar o gerenciador de inicialização, assinado pelo UEFI CA 2023 do Windows, à partição de inicialização. Isso substituirá o gerenciador de inicialização assinado pelo Microsoft Windows Production PCA 2011 . |
Observações:
- O bit 0x4000 permanecerá definido depois que todos os outros bits forem processados.
- Cada bit é processado pela tarefa agendada de Inicialização Segura e Atualização na ordem mostrada acima.
- Se o bit 0x0004 não puder ser processado devido a uma PK assinada KEK ausente, a tarefa agendada ainda aplicará a atualização do gerenciador de inicialização indicada pelo bit 0x0100.
Progressão esperada (AvailableUpdates)
Quando uma operação é concluída com êxito, o Windows limpa o bit associado de AvailableUpdates. Se uma operação falhar, o Windows registrará um evento em log e tentará novamente quando a tarefa for executada novamente.
A tabela a seguir mostra a progressão esperada dos valores de AvailableUpdates à medida que cada ação de atualização do Secure Boot é concluída.
| Etapa | Bit processado | Atualizações Disponíveis | Descrição | Evento de sucesso registrado | Possíveis códigos de evento de erro |
|---|---|---|---|---|---|
| Iniciar | 0x5944 | Estado inicial antes do início da manutenção do certificado de Inicialização Segura. | - | - | |
| 1 | 0x0040 | 0x5944 → 0x5904 | O UEFI CA 2023 do Windows é adicionado ao Banco de Dados de Inicialização Segura. | 1036 | 1032, 1795, 1796, 1802 |
| 2 | 0x0800 | 0x5904 → 0x5104 | Adicionar Microsoft Option ROM UEFI CA 2023 ao DB se o dispositivo anteriormente confiava no Microsoft UEFI CA 2011. | 1044 | 1032, 1795, 1796, 1802 |
| 3 | 0x1000 | 0x5104 → 0x4104 | O MICROSOFT UEFI CA 2023 será adicionado ao DB se o dispositivo anteriormente confiava no Microsoft UEFI CA 2011. | 1045 | 1032, 1795, 1796, 1802 |
| 4 | 0x0004 | 0x4104 → 0x4100 | Novo Microsoft KEK 2K CA 2023 assinado pela chave da plataforma OEM é aplicado. | 1043 | 1032, 1795, 1796, 1802, 1803 |
| 5 | 0x0100 | 0x4100 → 0x4000 | O gerenciador de inicialização assinado pelo Windows UEFI CA 2023 está instalado. | 1799 | 1797 |
Observações
- Depois que a operação associada a um bit for concluída com êxito, esse bit será removido de AvailableUpdates.
- Se uma dessas operações falhar, um evento será registrado e a operação será repetida na próxima vez que a tarefa agendada for executada.
- O bit 0x4000 é um modificador e não é limpo. Um valor final de AvailableUpdates de 0x4000 indica a conclusão bem-sucedida de todas as ações de atualização aplicáveis.
- Os eventos 1032, 1795, 1796, 1802 normalmente indicam limitações de firmware ou plataforma.
- O evento 1803 indica a falta de KEK assinada por PK do OEM.
Procedimentos de correção
Esta seção fornece procedimentos passo a passo para corrigir problemas específicos de Inicialização Segura. Cada procedimento tem como escopo uma condição bem definida e deve ser seguido somente após o diagnóstico inicial confirmar que o problema se aplica. Use estes procedimentos para restaurar o comportamento esperado da Inicialização Segura e permitir que as atualizações de certificado prossigam com segurança. Não aplique esses procedimentos de forma ampla ou preventiva.
Habilitando a Inicialização Segura no firmware
Se a Inicialização Segura estiver desabilitada no firmware de um dispositivo, consulte Windows 11 e Inicialização Segura para obter detalhes sobre como habilitar a Inicialização Segura.
Tarefa agendada de Inicialização Segura desabilitada ou excluída
A tarefa agendada Secure-Boot-Update é necessária para que o Windows aplique atualizações de certificado de Inicialização Segura. Se a tarefa estiver desabilitada ou ausente, a manutenção de certificado de Inicialização Segura não avançará.
Detalhes da tarefa
| Nome da Tarefa | Atualização de Inicialização Segura |
|---|---|
| Caminho da tarefa | \Microsoft\Windows\PI\ |
| Caminho completo | \Microsoft\Windows\PI\Secure-Boot-Update |
| Funciona como | SYSTEM (sistema local) |
| Gatilhos | Na inicialização e a cada 12 horas |
| Estado obrigatório | Habilitado |
Como marcar o status da tarefa
Execute a partir de um prompt do PowerShell com privilégios elevados:
schtasks.exe /query /TN "\Microsoft\Windows\PI\Secure-Boot-Update" /FO LIST /V
Procure o campo Status :
| Status | Significado |
|---|---|
| Pronto | A tarefa existe e está habilitada. |
| Compartilhar | A tarefa existe, mas deve ser habilitada. |
| Erro / Não Encontrado | A tarefa está ausente e deve ser recriada. |
Como habilitar ou recriar a tarefa
Se o campo status para Atualização de Inicialização Segura estiver Desabilitado, Erro ou Não Encontrado, use o script de exemplo para habilitar a tarefa: Exemplo Enable-SecureBootUpdateTask.ps1
Observação: este é um script de exemplo e não tem suporte da Microsoft. Os administradores devem examiná-lo e adaptá-lo ao seu ambiente.
Exemplo:
Observação
.\Enable-SecureBootUpdateTask.ps1 -Quiet
Diretrizes de execução
- Se você vir Acesso negado, execute novamente o PowerShell como Administrador.
- Se o script não for executado devido à política de execução, use um bypass de escopo de processo:
Observação
Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass