Solução de problemas
Aplica-se a
Data de publicação original: 19 de março de 2026
ID do KB: 5085046
Neste artigo
Visão geral
Esta página orienta administradores e profissionais de suporte para diagnosticar e resolver problemas relacionados à Inicialização Segura em dispositivos Windows. Os tópicos incluem falhas de atualização de certificado de Inicialização Segura, estados de Inicialização Segura incorretos, prompts de recuperação do BitLocker inesperados e falhas de inicialização após alterações na configuração da Inicialização Segura.
As diretrizes explicam como verificar a manutenção e a configuração do Windows, examinar valores relevantes do registro e logs de eventos e identificar quando as limitações de firmware ou plataforma exigem uma atualização do OEM. Esse conteúdo destina-se a diagnosticar problemas em dispositivos existentes. Não se destina a planejar 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 do certificado de Inicialização Segura
A manutenção do 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 é impulsionado por uma tarefa agendada pelo Windows, uma sequência baseada em registro de ações de atualização e um comportamento interno de registro em 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 após o sucesso das etapas de pré-requisito.
Por onde começar ao solucionar problemas
Quando um dispositivo não parece estar fazendo progresso esperado aplicando 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 de 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 manutenção do Windows e a qualificação da plataforma
-
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 atualizações de segurança necessárias mais recentes do Windows sã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 mais solução de problemas.
-
-
Verifique a tarefa Secure-Boot-Update status
-
Confirme se o mecanismo do Windows responsável pela aplicação de atualizações de certificado de Inicialização Segura está presente e funcionando:
-
A tarefa agendada secure-boot-update existe.
-
A tarefa está 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 de Inicialização Segura não poderão ser aplicadas. A solução de problemas deve se concentrar em restaurar a tarefa antes de investigar outras causas.
-
-
Verificar as configurações do registro para obter 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 parada em uma etapa específica.
-
-
Correlacionar o estado do registro com eventos de Inicialização Segura
Examine eventos relacionados à Inicialização Segura no log de eventos do sistema e correlaciona-os com o estado do registro. Os dados de evento normalmente confirmam se o dispositivo está fazendo progresso, repetindo devido a uma condição transitória ou bloqueado por um problema de firmware ou plataforma.
Juntos, os logs de registro e eventos geralmente indicam se o comportamento é esperado, temporário ou requer ação corretiva.
Tarefa agendada de Atualização de Inicialização Segura
A manutenção de certificado de inicialização segura é implementada por meio de uma tarefa agendada pelo Windows chamada Secure-Boot-Update. A tarefa é registrada no seguinte caminho:
\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. Sempre que ele é executado, ele verifica se as ações de atualização de Inicialização Segura estão pendentes e tenta aplicá-las em sequência.
Se essa tarefa estiver desabilitada ou ausente, as atualizações de certificado de Inicialização Segura 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
Atualizações de certificado de Inicialização Segura exigem coordenação entre firmware do 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 agenda recorrente de 12 horas oferece oportunidades adicionais para repetir atualizações se uma tentativa anterior falhou ou se o dispositivo permaneceu ligado sem reiniciar. Esse design ajuda a garantir o progresso sem exigir intervenção manual.
O bitmask do registro AvailableUpdates
A tarefa Secure-Boot-Update é conduzida pelo valor do registro AvailableUpdates . Esse valor é uma máscara de bits de 32 bits localizada em:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot
Cada bit no valor representa uma ação específica de atualização de Inicialização Segura. O processo de atualização começa quando AvailableUpdates é definido como um valor não 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 julgamento
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 repetir e ser concluída de forma independente. 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 desmarcado de AvailableUpdates.
Cada operação usa interfaces UEFI padrão para atualizar variáveis de Inicialização Segura, como o DB e o KEK, ou para instalar o gerenciador de inicialização do Windows atualizado. O Windows registra o resultado de cada etapa no log de eventos do Sistema. Eventos de sucesso confirmam o progresso, enquanto 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 e deixará o conjunto de bits associado. A operação será tentada novamente na próxima vez que a tarefa for executada. Esse comportamento de novo julgamento permite que os dispositivos se recuperem automaticamente de condições temporárias, como suporte de firmware ausente ou atualizações OEM atrasadas.
Os administradores podem acompanhar o progresso correlacionando o estado do registro com entradas de log de eventos. Valores de registro como UEFICA2023Status, UEFICA2023Error e UEFICA2023ErrorEvent, juntamente com o bitmask 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 do certificado de Arranque Seguro dependem do comportamento e suporte corretos 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 Arranque Seguro e manter as bases de dados de Arranque Seguro.
Os OEMs fornecem dois elementos críticos que permitem a manutenção do certificado de Arranque Seguro:
-
Chaves do Exchange (KEKs) assinadas pela Chave de Plataforma que autorizam a instalação de novos certificados de Arranque Seguro.
-
Implementações de firmware que preservam, acrescentam e validam corretamente as bases de dados de Arranque Seguro durante as atualizações.
Se o firmware não suportar totalmente estes comportamentos, as atualizações de Arranque Seguro podem parar, repetir indefinidamente ou resultar em falhas de arranque. Nestes casos, o Windows não consegue concluir a atualização sem alterações ao firmware.
A Microsoft trabalha com OEMs para identificar problemas de firmware e disponibilizar atualizações corrigidas. Quando a resolução de problemas indica uma limitação ou defeito de firmware, os administradores poderão ter de instalar a atualização de firmware UEFI mais recente fornecida pelo fabricante do dispositivo antes de as atualizações do certificado de Arranque Seguro poderem ser concluídas com êxito.
Cenários e resoluções comuns de falhas
As atualizações de Arranque Seguro são aplicadas pela tarefa agendada Atualização de Arranque Seguro com base no estado de registo AvailableUpdates .
Em condições normais, estes passos ocorrem automaticamente e registam eventos de sucesso à medida que cada fase é 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 de arranque inesperado.
As secções abaixo descrevem os cenários de falha mais comuns, como reconhecê-los, por que motivo ocorrem e os passos seguintes adequados para restaurar o funcionamento normal. Os cenários são ordenados desde os casos mais frequentemente encontrados a casos de impacto de arranque mais graves.
Quando as atualizações de Arranque Seguro não mostram progresso, normalmente significa que o processo de atualização nunca foi iniciado. Como resultado, os valores esperados do registo de Arranque Seguro e os registos de eventos estão em falta porque o mecanismo de atualização nunca foi acionado.
O que aconteceu
O processo de atualização de Arranque Seguro não foi iniciado, pelo que não foram aplicados certificados de Arranque Seguro ou gestor de arranque atualizado ao dispositivo.
Como reconhecê-lo
-
Não existem valores de registo de manutenção de Arranque Seguro, como UEFICA2023Status.
-
Os eventos de Arranque Seguro esperados (por exemplo, 1043, 1044, 1045, 1799, 1801) estão em falta no registo de eventos do Sistema.
-
O dispositivo continua a utilizar certificados de Arranque Seguro mais antigos e componentes de arranque.
Por que acontece
Normalmente, este cenário ocorre quando uma ou mais das seguintes condições são verdadeiras:
-
A tarefa agendada Atualização de Arranque Seguro está desativada ou em falta.
-
O Arranque Seguro está desativado no firmware UEFI.
-
O dispositivo não cumpre os pré-requisitos de manutenção do Windows, como executar uma versão suportada do Windows ou ter as atualizações necessárias instaladas.
O que fazer a seguir
-
Verifique se o dispositivo cumpre os requisitos de elegibilidade da plataforma e de manutenção do Windows.
-
Confirme que o Arranque Seguro está ativado no firmware.
-
Certifique-se de que a tarefa agendada SecureBootUpdate existe e está ativada.
Se a tarefa agendada estiver desativada ou em falta, siga as orientações em Tarefa agendada de Arranque Seguro desativada ou eliminada para restaurá-la. Depois de a tarefa ser restaurada, reinicie o dispositivo ou execute a tarefa manualmente para iniciar a manutenção do Arranque Seguro.
Em alguns casos, as atualizações relacionadas com o Arranque Seguro podem fazer com que um dispositivo entre na recuperação do BitLocker. O comportamento pode ser transitório ou persistente, consoante a causa subjacente.
Cenário 1: Recuperação Onetime BitLocker após atualização de Arranque Seguro
O que acontece
O dispositivo entra na recuperação bitLocker no primeiro arranque após a atualização de Arranque Seguro, mas arranca normalmente nos reinícios subsequentes.
Por que acontece
Durante o primeiro arranque após a atualização, o firmware ainda não comunica os valores de Arranque Seguro atualizados quando o Windows tenta reativar o BitLocker. Isto causa um erro de correspondência temporário nos valores de arranque medidos e aciona a recuperação. No arranque seguinte, o firmware comunica corretamente os valores atualizados, o BitLocker é apresentado novamente com êxito e o problema não se repete.
Como reconhecê-lo
-
A recuperação do BitLocker ocorre uma vez.
-
Depois de introduzir a chave de recuperação, os arranques subsequentes não solicitam a recuperação.
-
Não existe nenhuma ordem de arranque ou envolvimento PXE em curso.
O que fazer a seguir
-
Introduza a chave de recuperação BitLocker para retomar o Windows.
-
Verifique se existem atualizações de firmware.
Cenário 2: Recuperação repetida do BitLocker devido à configuração do primeiro arranque PXE
O que acontece
O dispositivo introduz a recuperação do BitLocker em cada arranque.
Por que acontece
O dispositivo está configurado para tentar primeiro o arranque PXE (rede). A tentativa de arranque PXE falha e, em seguida, o firmware volta para o gestor de arranque do Windows no disco.
Isto resulta na medição de duas autoridades de assinatura diferentes durante um único ciclo de arranque:
-
O caminho de arranque PXE é assinado pelo Microsoft UEFI CA 2011.
-
O gestor de arranque do Windows no disco é assinado pela CA 2023 do UEFI do Windows.
Uma vez que o BitLocker observa diferentes cadeias de fidedignidade de Arranque Seguro durante o arranque, não é possível estabelecer um conjunto estável de medidas TPM para reativar. Como resultado, o BitLocker entra na recuperação em cada arranque.
Como reconhecê-lo
-
A recuperação bitLocker é acionada em cada reinício.
-
Introduzir a chave de recuperação permite que o Windows inicie, mas o pedido regressa no arranque seguinte.
-
O PXE ou o arranque de rede é configurado antes do disco local por ordem de arranque de firmware.
O que fazer a seguir
-
Configure a ordem de arranque do firmware, para que o gestor de arranque do Windows no disco seja o primeiro.
-
Desative o arranque PXE se não for necessário.
-
Se o PXE for necessário, certifique-se de que a infraestrutura PXE utiliza um carregador de arranque do Windows assinado em 2023.
O que aconteceu
Isto reflete uma alteração ao nível do firmware em vez de um problema do Windows. A atualização de Arranque Seguro foi concluída com êxito, mas após um reinício posterior, o dispositivo já não arranca no Windows.
Como reconhecê-lo
-
O dispositivo não inicia o Windows e pode apresentar uma mensagem de firmware ou BIOS que indica uma violação do Arranque Seguro.
-
A falha ocorre depois de as definições de Arranque Seguro serem repostas para as predefinições de firmware.
-
Desativar o Arranque Seguro pode permitir que o dispositivo arranque novamente.
Por que acontece
Repor o Arranque Seguro para as predefinições de firmware limpa as bases de dados de Arranque Seguro armazenadas em firmware. Em dispositivos que já tenham transitado para o gestor de arranque assinado pelo UEFI CA 2023 do Windows, esta reposição remove os certificados necessários para confiar nesse gestor de arranque.
Como resultado, o firmware já não reconhece o gestor de arranque do Windows instalado como fidedigno e bloqueia o processo de arranque.
Este cenário não é causado pela atualização de Arranque Seguro propriamente dito, mas por uma ação de firmware subsequente que remove as âncoras de fidedignidade atualizadas.
O que fazer a seguir
-
Utilize o utilitário de recuperação de Arranque Seguro para restaurar o certificado necessário, para que o dispositivo possa arrancar novamente.
-
Após a recuperação, certifique-se de que o dispositivo tem o firmware mais recente disponível instalado pelo fabricante do dispositivo.
-
Evite repor o Arranque Seguro para predefinições de firmware, a menos que o firmware OEM inclua predefinições de Arranque Seguro atualizadas que confiem nos certificados 2023.
Utilitário de recuperação de Arranque Seguro
Para recuperar o sistema:
-
Num segundo PC Windows com a atualização do Windows de julho de 2024 ou mais recente instalada, copie SecureBootRecovery.efi de C:\Windows\Boot\EFI\.
-
Coloque o ficheiro numa pen USB formatada com FAT32 em \EFI\BOOT\ e mude o nome para bootx64.efi.
-
Inicie o dispositivo afetado a partir da pen USB e permita que o utilitário de recuperação seja executado. O utilitário irá adicionar a AC UEFI do Windows 2023 à BD.
Depois de o certificado ser restaurado e o sistema ser reiniciado, o Windows deverá iniciar normalmente.
Importante: Este processo só irá reaplicar um dos novos certificados. Assim que o dispositivo for recuperado, certifique-se de que tem os certificados mais recentes aplicados novamente e considere atualizar o BIOS/UEFI do sistema para a versão mais recente disponível. Isto pode ajudar a evitar a periodicidade do problema de reposição do Arranque Seguro, uma vez que muitos OEMs lançaram correções de firmware para este problema específico.
O que aconteceu
Depois de aplicar a atualização e o reinício do certificado de Arranque Seguro, o dispositivo não arranca e não chega ao Windows.
Como reconhecê-lo
-
O dispositivo falha imediatamente após o reinício exigido pela atualização de Arranque Seguro.
-
Pode ser apresentado um erro de firmware ou Arranque Seguro ou o sistema pode parar antes de o Windows ser carregado.
-
Desativar o Arranque Seguro pode permitir o arranque do dispositivo.
Por que acontece
Este problema pode ser causado por um defeito na implementação de firmware UEFI do dispositivo.
Quando o Windows aplica atualizações de certificados de Arranque Seguro, espera-se que o firmware acrescente novos certificados à base de dados de assinatura (DB) permitida de Arranque Seguro existente. Algumas implementações de firmware substituem incorretamente a BD em vez de acrescentar à mesma.
Quando isto ocorre,
-
Os certificados anteriormente fidedignos, incluindo o certificado de bootloader do Microsoft 2011, são removidos.
-
Se o sistema ainda estiver a utilizar um gestor de arranque assinado com o certificado 2011 nessa altura, o firmware já não confia no mesmo.
-
O firmware rejeita o gestor de arranque e bloqueia o processo de arranque.
Em alguns casos, a BD também pode ficar danificada em vez de ser substituída de forma limpa, levando ao mesmo resultado. Este comportamento foi observado em implementações de firmware específicas e não é esperado em firmware compatível.
O que fazer a seguir
-
Introduza os menus de configuração de firmware e tente repor as definições de Arranque Seguro.
-
Se o dispositivo arrancar após a reposição, marcar site de suporte do fabricante do dispositivo para uma atualização de firmware que corrija o processamento da BD de Arranque Seguro.
-
Se estiver disponível uma atualização de firmware, instale-a antes de reativar o Arranque Seguro e voltar a aplicar atualizações de certificados de Arranque Seguro.
Se a reposição do Arranque Seguro não restaurar a funcionalidade de arranque, a recuperação adicional provavelmente requer orientações específicas do OEM.
O que aconteceu
A atualização do certificado de Arranque Seguro não foi concluída e permanece bloqueada na fase de atualização da Chave do Exchange de Chaves (KEK).
Como reconhecê-lo
-
O valor de registo AvailableUpdates permanece definido com o bit KEK (0x0004) e não é limpo.
-
UEFICA2023Status não progride para um estado concluído.
-
O registo de eventos do Sistema regista repetidamente o ID do Evento 1803, indicando que não foi possível aplicar a atualização KEK.
-
O dispositivo continua a tentar novamente a atualização sem fazer progressos.
Por que acontece
A atualização da KEK de Arranque Seguro requer autorização da Chave de Plataforma (PK) do dispositivo, que pertence ao OEM.
Para que a atualização tenha êxito, o fabricante do dispositivo tem de fornecer à Microsoft um KEK assinado por PK para essa plataforma específica. Esta 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 um KEK assinado por PK para o dispositivo, o Windows não conseguirá concluir a atualização KEK. Neste estado:
-
As atualizações de Arranque Seguro são bloqueadas por predefinição.
-
O Windows não consegue contornar a autorização em falta.
-
O dispositivo pode permanecer permanentemente incapaz de concluir a manutenção do certificado de Arranque Seguro.
Isto pode ocorrer em dispositivos mais antigos ou sem suporte em que o OEM já não fornece firmware ou atualizações de chaves. Não existe nenhum caminho de recuperação manual suportado para esta condição.
Quando as atualizações do certificado de Arranque Seguro não se aplicam, o Windows regista eventos de diagnóstico que explicam o motivo pelo qual o progresso foi bloqueado. Estes eventos são escritos ao atualizar a base de dados de assinatura de Arranque Seguro (DB) ou a Chave de Troca de Chaves (KEK) não podem ser concluídas em segurança devido ao firmware, ao estado da plataforma ou às condições de configuração. Os cenários nesta secção fazem referência a estes eventos para identificar padrões de falha comuns e determinar a remediação adequada. Esta secção destina-se a suportar o diagnóstico e a interpretação de problemas descritos anteriormente, não para introduzir novos cenários de falha.
Para obter uma lista completa de IDs de eventos, descrições e entradas de exemplo, veja Secure Boot DB and DBX variable update events (KB5016061).
Falha na atualização kek (as atualizações da BD são bem-sucedidas, a KEK não)
Um dispositivo pode atualizar certificados com êxito na BD de Arranque Seguro, mas falha durante a atualização kek. Quando isto ocorre, não é possível concluir o processo de atualização de Arranque Seguro.
Sintomas
-
Os eventos do certificado DB indicam o progresso, mas a fase KEK não está concluída.
-
AvailableUpdates permanece definido para 0x4004 e o bit de 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 uma falha de firmware ao tentar atualizar uma variável de Arranque Seguro.
-
1803 indica que a atualização KEK não pode ser autorizada porque um payload KEK assinado pelo OEM PK necessário não está disponível para a plataforma.
Próximas etapas
-
Para a versão 1795, marcar para atualizações de firmware OEM e valide o suporte de firmware para atualizações de variáveis de Arranque Seguro.
-
Para o 1803, confirme se o OEM forneceu à Microsoft a KEK assinada por PK necessária para o modelo de dispositivo.
Falha na atualização kek em VMs convidadas alojadas no Hyper-V
Nas máquinas virtuais do Hyper-V, as atualizações de certificados de Arranque Seguro requerem que as atualizações de março de 2026 do Windows sejam instaladas no anfitrião Hyper-V e no SO convidado.
As falhas de atualização são comunicadas a partir do convidado, mas o evento indica onde é necessária a remediação:
-
Evento 1795 (por exemplo, "O suporte de dados está protegido por escrita") comunicado no convidado indica que o anfitrião Hyper-V está em falta na atualização de março de 2026 e tem de ser atualizado.
-
O evento 1803 comunicado no convidado indica que a máquina virtual convidada está em falta na atualização de março de 2026 e tem de ser atualizada.
Referência e internos
Esta secção contém informações de referência avançadas destinadas à resolução de problemas e suporte. Não se destina ao planeamento da implementação. Expande-se na mecânica de manutenção de Arranque Seguro resumida anteriormente e fornece material de referência detalhado para interpretar o estado do registo e os registos de eventos.
Nota (implementações geridas por TI): quando configuradas através de Política de Grupo ou Microsoft Intune, duas definições semelhantes não devem ser confundidas. O valor AvailableUpdatesPolicy representa o estado da política configurada. Entretanto, AvailableUpdates reflete o estado de trabalho em curso e de desmarcação de bits. Ambos podem impulsionar o mesmo resultado, mas comportam-se de forma diferente porque a política se aplica novamente ao longo do tempo.
Bits AvailableUpdates utilizados para manutenção de certificados
Os bits abaixo são utilizados para as ações do certificado e do gestor de arranque descritas neste documento. A coluna Order reflete a sequência na qual a tarefa Secure-Boot-Update processa cada bit.
|
Ordem |
Definição de bits |
Uso |
|---|---|---|
|
1 |
0x0040 |
Este bit indica à tarefa agendada para adicionar o certificado CA 2023 da UEFI do Windows à BD de Arranque Seguro. Isto permite que o Windows confie nos gestores de arranque assinados por este certificado. |
|
2 |
0x0800 |
Este bit indica à tarefa agendada para aplicar o UEFI CA 2023 da Opção Microsoft à BD. Comportamento condicional : quando o sinalizador de 0x4000 é definido, a tarefa agendada será marcar primeiro a base de dados para o certificado MICROSOFT Corporation UEFI CA 2011. Aplicará o certificado UEFI CA 2023 da ROM de Opção da Microsoftapenas se o certificado de 2011 estiver presente. |
|
3 |
0x1000 |
Este bit indica à tarefa agendada para aplicar o MICROSOFT UEFI CA 2023 à BD. Comportamento condicional: quando o sinalizador 0x4000 estiver definido, a tarefa agendada será marcar primeiro a base de dados para o certificado MICROSOFT Corporation UEFI CA 2011. Só aplicará o certificado microsoft UEFI CA 2023se o certificado de 2011 estiver presente. |
|
Modificador (sinalizador de comportamento) |
0x4000 |
Este bit modifica o comportamento dos 0x0800 e 0x1000 bits para que o UEFI CA 2023 da Microsoft e o UEFI CA 202 3 da Opção Microsoftsejam aplicados apenas se a BD já contiver a CA UEFI da Microsoft Corporation 2011. Para ajudar a garantir que o perfil de segurança do dispositivo permaneça o mesmo, esse bit só aplicará 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 do Key Exchange 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 é incluído em atualizações cumulativas mensais. |
|
5 |
0x0100 |
Esse bit informa a tarefa agendada para aplicar o gerenciador de inicialização, assinado pela CA 2023 do Windows UEFI, à 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 Secure-Boot-Update na ordem mostrada acima.
-
Se o 0x0004 bit não puder ser processado devido a um KEK assinado por PK ausente, a tarefa agendada ainda aplicará a atualização do gerenciador de inicialização indicada por 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 e repetirá quando a tarefa for executada novamente.
A tabela abaixo mostra a progressão esperada dos valores AvailableUpdates à medida que cada ação de atualização de Inicialização Segura é concluída.
|
Diagnóstico |
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 WINDOWS UEFI CA 2023 é adicionado ao DB de Inicialização Segura. |
1036 |
1032, 1795, 1796, 1802 |
|
2 |
0x0800 |
0x5904 → 0x5104 |
Adicione a CA 2023 da Rom UEFI da Microsoft ao DB se o dispositivo confiasse anteriormente na CA da UEFI da Microsoft 2011. |
1044 |
1032, 1795, 1796, 1802 |
|
3 |
0x1000 |
0x5104 → 0x4104 |
O Microsoft UEFI CA 2023 será adicionado ao DB se o dispositivo confiasse anteriormente na CA da UEFI da Microsoft 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á desmarcado 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 0x4000 bit é um modificador e não está limpo. Um valor final 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 kek assinado por PK OEM ausente.
Procedimentos de correção
Esta seção fornece procedimentos passo a passo para corrigir problemas específicos de Inicialização Segura. Cada procedimento tem o escopo de uma condição bem definida e destina-se a ser seguido somente após o diagnóstico inicial confirmar que o problema se aplica. Use esses procedimentos para restaurar o comportamento esperado de 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 de Atualização de Inicialização Segura é 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 do certificado de Inicialização Segura não progredirá.
Detalhes da tarefa
|
Nome da Tarefa |
Secure-Boot-Update |
|
Caminho da tarefa |
\Microsoft\Windows\PI\ |
|
Caminho completo |
\Microsoft\Windows\PI\Secure-Boot-Update |
|
Execuções como |
SYSTEM (Sistema Local) |
|
Disparadores |
Na inicialização e a cada 12 horas |
|
Estado necessário |
habilitado |
Como marcar tarefa status
Execute a partir de um prompt do PowerShell elevado: 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. |
|
Desabilitada |
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 Secure-Boot-Update 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 revisá-lo e adaptá-lo ao seu ambiente.
Exemplo:
.\Enable-SecureBootUpdateTask.ps1 -Quiet
Executar diretrizes
-
Se você vir o Access 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:
Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass
Precisa de mais ajuda?
Quer mais opções
Explore os benefícios da assinatura, procure cursos de treinamento, saiba como proteger seu dispositivo e muito mais.
As comunidades ajudam você a fazer e responder perguntas, fazer comentários e ouvir especialistas com conhecimento avançado.
