Prevenção e recuperação de crise contínuas
Se uma atualização de firmware falhar, os resultados poderão ser devastadores. Na melhor das hipóteses, a atualização falha, mas o sistema é resiliente e se recupera sem que o usuário final fique ciente. Na pior das hipóteses, é possível que uma atualização de firmware com falha resulte em um sistema inutilizável, exigindo que o usuário final retorne seu sistema ao varejista ou fabricante para reparo. O último caso é o que chamamos de crise.
Uma crise pode resultar de uma atualização de firmware com falha ou devido ao firmware incompatível com o Windows ou outros aspectos do sistema. Esta seção discute os recursos projetados para evitar e se recuperar de crises resultantes de atualizações de firmware com falha. Nossa expectativa é que a cobertura de teste de atualização de firmware pelo autor do firmware impeça a maioria das crises resultantes de firmware incompatível.
Para fornecer uma ótima experiência para os usuários finais, os seguintes requisitos de prevenção e recuperação de crises devem ser atendidos para o mecanismo de atualização do pacote do driver de firmware. Esses requisitos não impedem soluções adicionais de recuperação ou prevenção de crises.
Critérios de pré-instalação
Quando o firmware do sistema está executando a atualização real, há uma série de verificações de pré-instalação que devem ser executadas. O firmware do sistema deve executar esse marcar para garantir que haja energia suficiente para concluir a atualização. Também é recomendável que as verificações sejam feitas para cada uma das atualizações antes que a atualização seja aplicada se houver várias atualizações de firmware. A lista de itens a marcar e validar são fornecidas na tabela a seguir. Todas as verificações devem ser executadas quando aplicável. Não há nenhuma ordem específica para a execução dos testes.
| Tipo de verificação | Descrição |
|---|---|
| Energia | O sistema deve ter pelo menos 25% de carga da bateria. A energia amarrada (energia por cabo USB e/ou energia AC) não é necessária. Em um ambiente de teste/laboratório, é aceitável não ter nenhuma bateria presente, mas ainda permitir atualizações de firmware, desde que a energia amarrada seja fornecida. No entanto, uma diferenciação deve ser feita entre uma bateria inativa/não carregada e nenhuma bateria presente. |
| Segurança | Validar se o conteúdo da cápsula de atualização está assinado corretamente. Valide se todos os arquivos EFI baseados em PE na carga são assinados corretamente com um certificado EFI adequado |
| Integridade | Execute uma marcar de integridade no conteúdo da atualização de firmware. |
| Versão | Verifique se o firmware que está sendo aplicado não faz downgrade do firmware atual instalado além do valor LowerSupportedFirmwareVersion. |
| Armazenamento | As verificações a seguir são executadas conforme apropriado, dependendo do hardware do sistema Há espaço suficiente para backups do firmware atual que serão substituídos Há espaço suficiente no dispositivo para acomodar o novo firmware. |
Qualquer falha deve resultar em um código de erro de Status da Última Tentativa apropriado. Para obter mais informações, consulte as informações de código de erro Status da Última Tentativa na definição da tabela ESRT e atualização de firmware status.
Se várias atualizações estiverem sendo aplicadas e algumas passarem pelas verificações de pré-instalação e outras não, o firmware da plataforma poderá continuar atualizando o firmware para os recursos que passaram nas verificações de pré-instalação. No entanto, qualquer recurso que falhou na pré-instalação marcar não deve ser atualizado.
Critérios pós-instalação
Depois que o firmware (dispositivo ou sistema) tiver sido instalado, ele deverá ser verificado para validar se a nova imagem de firmware atualizada é o que se pretendia. Isso é para minimizar os riscos de corrupção introduzidos durante o processo de atualização real (por exemplo, bits autoadesivas em FLASH ROM, ruído em um barramento durante a atualização e assim por diante).
O processo de atualização deve validar se o firmware atualizado passa por verificações de integridade. Se falhar, ele deverá se recuperar revertendo para a última versão boa conhecida do firmware.
Qualquer falha deve resultar em um código de erro de Status da Última Tentativa apropriado. Para obter mais informações, consulte as informações de código de erro Status da Última Tentativa na definição da tabela ESRT e atualização de firmware status.
Recuperando-se de falhas de instalação e inicialização
Para impedir que um sistema atinja um estado não inicializável, o mecanismo de atualização de firmware deve atender aos requisitos a seguir nos casos em que as atualizações de firmware não são instaladas ou nos casos em que o sistema falha ao inicializar com êxito.
Nas seções a seguir, o termo "confirmado" é usado para descrever o firmware. Depois que o firmware for "confirmado", o firmware será tratado como totalmente instalado e não será revertido automaticamente pelo firmware devido a uma falha de inicialização, etc. O firmware "Não confirmado" descreve o firmware parcialmente atualizado e pode potencialmente ser revertido para uma versão anterior nos casos em que a atualização de firmware não pode ser concluída ou uma falha é detectada pelo firmware de atualização (por exemplo, marcar crc inválidos na atualização). Se o firmware está confirmado é algo que o firmware deve acompanhar internamente e não é capturado como parte do ESRT.
Atualização de firmware malsucedida
Se um firmware de dispositivo ou sistema individual não puder ser instalado ou tiver sido instalado incorretamente (por exemplo, devido a algum tipo de corrupção ou uma perda de energia durante a instalação da atualização), a atualização poderá ser repetida até um total de três (3) tentativas, incluindo a primeira tentativa. Se novas tentativas adicionais forem executadas pelo firmware, o sistema não deverá inicializar no Windows entre nenhuma das tentativas. Se todas as tentativas falharem, o firmware de atualização deverá descartar a atualização. Se a atualização tiver sido parcialmente aplicada, o firmware deverá reverter para a versão anterior. O firmware deve reverter para a versão anterior sem nenhuma interação do usuário. A falha de atualização não afeta outras atualizações pendentes; As atualizações de firmware pendentes devem ser tentadas.
Depois que todas as atualizações forem processadas, a UEFI retomará a inicialização do Windows. O firmware UEFI deve verificar se todas as atualizações de firmware não confirmadas foram instaladas com êxito para atenuar problemas devido à perda de energia (a UEFI nunca deve tentar inicializar o Windows com firmware parcialmente gravado).
As possíveis causas de falha na instalação incluem, mas não se limitam aos seguintes problemas:
| Causa da falha de instalação | Código do erro |
|---|---|
| Recursos insuficientes | STATUS_INSUFFICIENT_RESOURCES |
| Perda de energia | STATUS_INSUFFICIENT_POWER |
| Falha de hardware | STATUS_POWER_STATE_INVALID |
A atualização de firmware é bem-sucedida, mas o Windows falha ao inicializar
O firmware UEFI não é responsável por reverter o firmware atualizado depois de confirmado. A lógica de failover existente no Windows desviará o usuário final para o WinRE (Ambiente de Recuperação do Windows) após duas tentativas de inicialização malsucedidas. O WinRE pode ou não ser inicializado com êxito. O usuário final precisa executar uma etapa de recuperação manual para recuperar seu sistema ou terá que retornar seu dispositivo para o varejista/fabricante.
As possíveis causas para essa classe de falha incluem, mas não se limitam a:
Firmware incompatível com drivers do sistema operacional.
Firmware incompatível com componentes do sistema operacional.
Se um fornecedor de hardware decidir implementar uma lógica adicional para determinar se o Windows foi inicializado com êxito, isso é aceitável. Conforme mencionado anteriormente, a expectativa é que a cobertura de teste de atualização de firmware pelo autor do firmware impeça a maioria das crises resultantes de firmware incompatível.
Artigos relacionados
Criação de um pacote de driver de atualização
Comentários
Em breve: Ao longo de 2024, eliminaremos os problemas do GitHub como o mecanismo de comentários para conteúdo e o substituiremos por um novo sistema de comentários. Para obter mais informações, consulte https://aka.ms/ContentUserFeedback.
Enviar e exibir comentários de