Prevención y recuperación de crisis sin problemas
Si se produce un error en una actualización de firmware, los resultados pueden ser devastadores. En el mejor de los casos, se produce un error en la actualización, pero el sistema es resistente y se recupera sin que el usuario final sea consciente. En el peor de los casos, es posible que una actualización de firmware con errores produzca un sistema inutilizable, lo que requiere que el usuario final devuelva su sistema al distribuidor o al fabricante para su reparación. Este último caso es lo que llamamos una crisis.
Una crisis puede deberse a una actualización de firmware errónea o debido al firmware incompatible con Windows u otros aspectos del sistema. En esta sección se describen las características diseñadas para evitar y recuperarse de las crisis que resultan de actualizaciones de firmware erróneas. Nuestra expectativa es que la cobertura de prueba de actualización de firmware por parte del autor del firmware impida la mayoría de las crisis resultantes de firmware incompatible.
Para proporcionar una excelente experiencia para los usuarios finales, se deben cumplir los siguientes requisitos de prevención de crisis y recuperación para el mecanismo de actualización del paquete de controladores de firmware. Estos requisitos no excluyen soluciones adicionales de prevención de crisis ni recuperación.
Criterios de preinstalación
Cuando el firmware del sistema realiza la actualización real, hay una serie de comprobaciones de preinstalación que se deben realizar. El firmware del sistema debe realizar esta comprobación para asegurarse de que hay suficiente energía para completar la actualización. También se recomienda realizar las comprobaciones de cada una de las actualizaciones antes de aplicar la actualización si hay varias actualizaciones de firmware. La lista de elementos que se van a comprobar y validar se proporciona en la tabla siguiente. Todas las comprobaciones deben realizarse cuando proceda. No hay ningún orden específico para la ejecución de las pruebas.
| Tipo de comprobación | Descripción |
|---|---|
| Potencia | El sistema debe tener al menos un 25 % de carga de batería. No se requiere alimentación anclada (alimentación a través de cable USB o alimentación AC). En un entorno de prueba o laboratorio, es aceptable que no haya batería presente todavía permitir actualizaciones de firmware siempre y cuando se proporcione energía anclada. Sin embargo, se debe hacer una diferenciación entre una batería muerta o sin carga y ninguna batería presente. |
| Seguridad | Valide que la carga de la cápsula de actualización esté firmada correctamente. Compruebe que los archivos EFI basados en PE de la carga estén firmados correctamente con un certificado EFI adecuado. |
| Integridad | Realice una comprobación de integridad en la carga de actualización de firmware. |
| Versión | Compruebe que el firmware que se aplica no degrada el firmware actual, instalado más allá del valor de LowestSupportedFirmwareVersion. |
| Storage | Las siguientes comprobaciones se realizan según corresponda, dependiendo del hardware del sistema. Hay suficiente espacio para las copias de seguridad del firmware actual que se reemplazarán. Hay suficiente espacio en el dispositivo para acomodar el nuevo firmware. |
Cualquier error debe dar lugar a un código de error de estado del último intento adecuado. Para obtener más información, consulte la información del código de error del último intento en la definición de tabla de ESRT y el estado de actualización del firmware.
Si se aplican varias actualizaciones y algunas pasan las comprobaciones de preinstalación y otras no, el firmware de la plataforma puede continuar con la actualización del firmware de los recursos que pasaron las comprobaciones de preinstalación. Sin embargo, no se debe actualizar ningún recurso que haya producido un error en la comprobación de preinstalación.
Criterios posteriores a la instalación
Una vez instalado el firmware (dispositivo o sistema), debe comprobarse para validar que la nueva imagen de firmware actualizada es la que se ha previsto. Esto es para minimizar los riesgos de cualquier daño introducido durante el proceso de actualización real (por ejemplo, bits pegajosos en rom flash, ruido en un bus durante la actualización, etc.).
El proceso de actualización debe validar que el firmware actualizado pasa las comprobaciones de integridad. Si se produce un error, debe recuperarse revierte a la última versión correcta conocida del firmware.
Cualquier error debe dar lugar a un código de error de estado del último intento adecuado. Para obtener más información, consulte la información del código de error del último intento en la definición de tabla de ESRT y el estado de actualización del firmware.
Recuperación de errores de instalación y arranque
Para evitar que un sistema alcance un estado que no sea de arranque, el mecanismo de actualización de firmware debe cumplir los siguientes requisitos en los casos en los que las actualizaciones de firmware no se instalan o en los casos en los que el sistema no se inicia correctamente.
En las secciones siguientes, el término "confirmado" se usa para describir el firmware. Una vez que el firmware se ha "confirmado", el firmware se trata como totalmente instalado y el firmware no se revierte automáticamente debido a un error de arranque, etc. El firmware "No confirmado" describe el firmware parcialmente actualizado y puede revertirse a una versión anterior en casos en los que la actualización del firmware no se puede completar o el firmware de actualización detecta un error (por ejemplo, Comprobación de CRC no válida en la actualización). Si el firmware se confirma es algo que el firmware debe realizar un seguimiento interno y no se captura como parte de ESRT.
Actualización de firmware incorrecta
Si no se puede instalar un firmware de dispositivo o sistema individual, o si se ha instalado incorrectamente (por ejemplo, debido a algún tipo de daños o a una pérdida de energía durante la instalación de la actualización), la actualización se puede reintentar hasta un total de tres (3) intentos, incluido el primer intento. Si el firmware realizará intentos de reintento adicionales, el sistema no debe arrancar en Windows entre ninguno de los intentos. Si se produce un error en todos los intentos, el firmware de actualización debe descartar la actualización. Si la actualización se aplicó parcialmente, el firmware debe revertirse a la versión anterior. El firmware debe revertirse a la versión anterior sin ninguna interacción del usuario. El error de actualización no afecta a otras actualizaciones pendientes; Se deben intentar las actualizaciones de firmware pendientes.
Una vez procesadas todas las actualizaciones, UEFI reanudará el arranque de Windows. El firmware UEFI debe comprobar que las actualizaciones de firmware no confirmadas se instalaron correctamente para mitigar los problemas debido a la pérdida de energía (UEFI nunca debe intentar arrancar Windows con firmware escrito parcialmente).
Entre las posibles causas del error de instalación se incluyen, pero no se limitan a los siguientes problemas:
| Causa del error de instalación | Código de error |
|---|---|
| No hay suficientes recursos | STATUS_INSUFFICIENT_RESOURCES |
| Pérdida de energía | STATUS_INSUFFICIENT_POWER |
| Error de hardware | STATUS_POWER_STATE_INVALID |
La actualización de firmware se realiza correctamente, pero Windows no se inicia
El firmware UEFI no es responsable de revertir el firmware actualizado una vez confirmado. La lógica de conmutación por error existente en Windows desviará al usuario final al entorno de recuperación de Windows (WinRE) después de dos intentos de arranque incorrectos. WinRE puede arrancar o no correctamente. El usuario final debe realizar un paso de recuperación manual para recuperar su sistema, o tendrá que devolver su dispositivo al minorista o fabricante.
Entre las posibles causas de esta clase de error se incluyen, pero no se limitan a:
Firmware incompatible con los controladores del sistema operativo.
Firmware incompatible con los componentes del sistema operativo.
Si un proveedor de hardware decide implementar lógica adicional para determinar si Windows se ha arrancado correctamente, es aceptable. Como se mencionó anteriormente, la expectativa es que la cobertura de prueba de actualización de firmware por parte del autor del firmware impida la mayoría de las crisis resultantes de firmware incompatible.
Artículos relacionados
Creación de un paquete de controladores de actualización
Procesamiento de actualizaciones