Windows firmware update program

Afuwingui — это простая утилита для прошивки биос из под Windows поможет, когда Ваш биос невозможно прошить программой FPT, или при прошивке через AFUDOS у Вас по каким либо причинам не работает клавиатура (например после неудачной прошивки, или кривого мод биоса).

Программа предназначена для биосов производства American Megatrends.
Версия 5.12 подходит для биосов на Aptio 5, использующихся в большинстве китайских материнских плат на сокете 2011-3.

Сначала делаем бэкап родного биоса — запускаем утилиту AFUWINGUIx64.EXE, нажимаем «Save» и сохраняем файл.

Если программа не совместима с Вашим чипом Вы увидите соответствующее сообщение с ошибкой

Таким образом перед прошивкой биоса мы можем проверить совместимость программы с нашим чипом биоса, если процесс бэкапа прошёл удачно, значит чип биоса совметим с программой.

Далее нажимаем кнопку «Open», выбираем файл биоса для прошивки, во вкладке Setup ставим галочки как на скриншоте и нажимаем кнопку «Flash».

По завершению процесса прошивки, система перезагрузится уже с обновлённым биосом.

Прошить биос через Afuwin можно и без графического интерфейса, для этого создайте в папке с программой .bat файл с параметрами:

Не прошивайте файл дампа биоса, если не уверены, что он предназначен для Вашей платы.
После прошивки биоса рекомендуется сбросить настройки по умолчанию.
Скачать AFUWINGUI v5.12.03.2074: AfuWin64, AfuWin32 (поддержка Aptio 5)
Скачать AFUWINGUI v3.09.03.1462: AfuWin64, AfuWin32 (поддержка Aptio 3, 4, 4.5)
Официальный сайт утилиты

Чтобы оставить комментарий, авторизуйтесь или зарегистрируйтесь.

1″ :pagination=»pagination» :callback=»loadData» :options=»paginationOptions»>

Updating Device Firmware using Windows Update

This topic describes how to update a removable or in-chassis device’s firmware using the Windows Update (WU) service. For information about updating system firmware, see Windows UEFI firmware update platform.

To do this, you’ll provide an update mechanism, implemented as a device driver, that includes the firmware payload. If your device uses a vendor-supplied driver, you have the option of adding the firmware update logic and payload to your existing function driver, or providing a separate firmware update driver package. If your device uses a Microsoft-supplied driver, you must provide a separate firmware update driver package. In both cases, the firmware update driver package must be universal. For more info about universal drivers, see Getting Started with Windows Drivers. The driver binary can use KMDF, UMDF 2 or the Windows Driver Model.

Because WU cannot execute software, the firmware update driver must hand the firmware to Plug and Play (PnP) for installation.

Firmware update driver actions

Typically, the firmware update driver is a lightweight device driver that does the following:

At device start or in the driver’s EVT_WDF_DRIVER_DEVICE_ADD callback function:

1. Identify the device to which it is attached.
2. Determine whether the driver has a firmware version that is more recent than the version on the firmware currently flashed on device hardware.
3. If a firmware update is necessary, set an event timer to schedule the update.
4. Otherwise, do nothing until the driver is started again.

During system runtime:

1. If an update is queued, wait for a set of conditions to be met.
2. When conditions are met, perform the firmware update on the device.

Firmware update driver contents

Typically, the firmware update driver package contains the following:

• Universal Driver INF
• Driver catalog
• Function driver (.sys or .dll)
• Firmware update payload binary

Submit your firmware update package as a separate driver submission.

Adding firmware update logic to a vendor-supplied driver

The existing function driver can implement the firmware update mechanism, as shown in the following diagram:

Alternatively, if you want to update the function driver and the firmware update driver separately, create a second device node, on which you will install the firmware update driver. The following diagram shows how one device can have two separate device nodes:

In this case, the function and firmware device nodes must have different hardware IDs in order to be targeted independently.

There are a couple ways to create a second device node. Certain device types have the ability to expose a second device node on one physical device, such as USB. You can use this functionality to create a device node targetable by WU, and install a firmware update driver on it. Many device types, however, do not allow a single physical device to enumerate more than one device node.

In this case, use an extension INF that specifies the AddComponent directive to create a device node that can be targeted by Windows Update and install the firmware update driver on it. The following snippet from an INF file shows how you can do this:

In the above INF sample, ComponentIDs = ComponentDeviceId indicates that the child device will have a hardware ID of SWC\ComponentDeviceId . When installed, this INF creates the following device hierarchy:

For future firmware updates, update the INF and binary file containing the firmware payload.

Adding firmware update logic to a Microsoft-supplied driver

To update firmware for devices that use a Microsoft-supplied driver, you need to create a second device node, as shown above.

Best practices

In your firmware update driver INF, specify DIRID 13 to cause PnP to leave the files in the driver package in the DriverStore:

PnP resolves this location when it installs the device. The driver can then open this registry key to determine the location of the payload.

Firmware update drivers should specify the following INF entries:

To locate another device node, the firmware driver should walk the device tree relative to itself, not by enumerating all device nodes for a match. A user may have plugged in multiple instances of the device, and the firmware driver should only update the device with which it is associated. Typically, the device node to be located is the parent or sibling of the device node on which the firmware driver is installed. For example, in the diagram above with two device nodes, the firmware update driver can look for a sibling device to find the function driver. In the diagram immediately above, the firmware driver can look for the parent device to find the primary device with which it needs to communicate.

The driver should be robust to multiple instances of the device being on the system, possibly with multiple different firmware versions. For example, there may be one instance of the device that has been connected and updated several times; a brand new device may then be plugged in which is several firmware versions old. This means that state (such as current version) must be stored against the device, and not in a global location.

If there is an existing method to update the firmware (EXE or co-installer, for example), you can largely reuse the update code within a UMDF driver.

Windows UEFI firmware update platform

Windows supports a platform for installing system and device firmware updates via driver packages that are processed by using the UEFI UpdateCapsule function. This platform provides a consistent, reliable firmware update experience, and it improves the discoverability of important system firmware updates for end-users.

The UEFI firmware update platform guidance is intended for SoC vendors and OEMs who are building hardware platforms that run Windows. The UEFI firmware update platform is supported by the following operating system versions:

• WindowsВ 8
• WindowsВ 8.1
• WindowsВ 10 for desktop editions (Home, Pro, Enterprise, and Education)
• WindowsВ 10 Mobile

UEFI firmware update support in Windows 10

All systems that run WindowsВ 10 for desktop editions should implement UEFI firmware updates by following the UpdateCapsule-based update process described in this section of the documentation.

Devices that run WindowsВ 10 Mobile can follow the UpdateCapsule-based process used for Windows 10 Desktop. These devices can also follow the binary update process, which performs a binary update to the storage partition which contains the UEFI firmware.

Microsoft strongly recommends that devices running WindowsВ 10 Mobile should update UEFI firmware by using the binary update process. Devices that run Windows 10 Mobile can use the UpdateCapsule-based process only in scenarios where the binary update process cannot be used. For example, if the partition layout of the device prevents the UEFI firmware from being updated by using a binary update package.

For more information about .spkg packages for WindowsВ 10 Mobile, see Creating packages.

Overview of the UEFI firmware update platform

There are two types of firmware that can be serviced via Windows: system firmware and device firmware. System firmware is responsible for providing critical boot and runtime services to the system as a whole, and device firmware is associated with a particular device integrated into a system. Such device firmware typically works together with a device driver, allowing the OS to expose the device to OS-level services and applications.

System firmware updates

System firmware updates for UEFI-based systems will be deployed as device driver packages (INFs). Windows will use information provided by the platform to ensure that the update package only applies to appropriate systems. A firmware update package contains a binary file containing the system firmware image. After the firmware update package is on the end-user’s system, Windows will use the UEFI UpdateCapsule function to hand-off the firmware payload to the platform firmware for processing.

Deploying the update as a driver package allows the firmware update process to align with many existing deployment and servicing tools, and ensures simple update package authoring for hardware vendors.

The fact that the firmware update is delivered as a driver package does not mean that the update is written as an actual driver. The driver package will contain an INF file and a binary file containing the system or device firmware image.

Device firmware updates

For the purposes of updating device firmware, the device firmware can be assigned to one of these two categories:

UEFI-updatable device firmware.

This device firmware can be updated using a device driver package leveraging the same mechanism as system firmware. A device firmware update is distributed as a firmware update package. After the firmware update package is on the end-user’s system, Windows will use the UEFI UpdateCapsule function to hand-off the device firmware payload to the platform firmware for processing. This process is virtually identical to how Windows hands off system firmware update payload, and is discussed below.

It is recommended that device firmware be updated using a discrete firmware update driver package, but device firmware may also be updated with system firmware as part of a single firmware update driver package.

NoteВ В UEFI should not be used to update peripheral devices. UEFI requires devices to be present during reboot to apply a firmware update which cannot be guaranteed with (external, removable) peripheral devices.

Driver-updatable device firmware.

This device firmware can be updated by the device driver during the normal Windows OS runtime. Updating device firmware using normal Windows OS drivers is not covered by this paper.

System requirements for Windows firmware updates

In order for a system to be compatible with the Windows firmware updating mechanism, it must meet the following requirements:

The system must implement UpdateCapsule and QueryCapsuleCapabilities as defined by section 8.5.3 of the UEFI specification 2.8.

UpdateCapsule is used to pass the firmware update payload between Windows and the platform firmware.

Platform firmware must support firmware updates initiated by Windows.

System firmware, and some classes of device firmware, must be updatable using this process. Firmware code recognizes a firmware update payload passed to UpdateCapsule and initiates the update process. The implementation is owned by the partner.

Must specify a Firmware Resource in the EFI System Resource Table (ESRT)

The Firmware Resource allows Windows to surface a device instance with a Hardware ID, which will be used to target the system or device firmware update to appropriate systems and devices. It also describes the current firmware version and provides status for previous updates.

There exists a single entry for system firmware updates. All devices with updateable firmware must have a resource specified in the ESRT, unless a device’s firmware is updated as part of a system firmware update.

Updating drive firmware

Applies to: Windows Server 2019, Windows Server 2016, Windows 10

Updating the firmware for drives has historically been a cumbersome task with a potential for downtime, which is why we’re making improvements to Storage Spaces, Windows Server, and Windows 10, version 1703 and newer. If you have drives that support the new firmware update mechanism included in Windows, you can update drive firmware of in-production drives without downtime. However, if you’re going to update the firmware of a production drive, make sure to read our tips on how to minimize the risk while using this powerful new functionality.

Firmware updates are a potentially risky maintenance operation and you should only apply them after thorough testing of the new firmware image. It is possible that new firmware on unsupported hardware could negatively affect reliability and stability, or even cause data loss. Administrators should read the release notes a given update comes with to determine its impact and applicability.

Drive compatibility

To use Windows Server to update drive firmware, you must have supported drives. To ensure common device behavior, we began by defining new and — for Windows 10 and Windows Server 2016 — optional Hardware Lab Kit (HLK) requirements for SAS, SATA, and NVMe devices. These requirements outline which commands a SATA, SAS, or NVMe device must support to be firmware-updatable using these new, Windows-native PowerShell cmdlets. To support these requirements, there is a new HLK test to verify if vendor products support the right commands and get them implemented in future revisions.

Contact your solution vendor for info about whether your hardware supports Windows updating the drive firmware. Here are links to the various requirements:

SATA: Device.Storage.Hd.Sata — in the [If Implemented] Firmware Download & Activate section

SAS: Device.Storage.Hd.Sas — in the [If Implemented] Firmware Download & Activate section

NVMe: Device.Storage.ControllerDrive.NVMe — in sections 5.7 and 5.8.

PowerShell cmdlets

The two cmdlets added to Windows are:

The first cmdlet provides you with detailed information about the device’s capabilities, firmware images, and revisions. In this case, the machine only contains a single SATA SSD with 1 firmware slot. Here’s an example:

Note that SAS devices always report «SupportsUpdate» as «True», since there is no way of explicitly querying the device for support of these commands.

The second cmdlet, Update-StorageFirmware, enables administrators to update the drive firmware with an image file, if the drive supports the new firmware update mechanism. You should obtain this image file from the OEM or drive vendor directly.

Before updating any production hardware, test the particular firmware image on identical hardware in a lab setting.

The drive will first load the new firmware image to an internal staging area. While this happens, I/O typically continues. The image activates after downloading. During this time the drive will not be able to respond to I/O commands as an internal reset occurs. This means that this drive serves no data during the activation. An application accessing data on this drive would have to wait for a response until the firmware activation completes. Here’s an example of the cmdlet in action:

Drives typically do not complete I/O requests when they activate a new firmware image. How long a drive takes to activate depends on its design and the type of firmware you update. We have observed update times range from fewer than 5 seconds to more than 30 seconds.

This drive performed the firmware update within

5.8 seconds, as shown here:

Updating drives in production

Before placing a server into production, we highly recommend updating the firmware of your drives to the firmware recommended by the hardware vendor or OEM that sold and supports your solution (storage enclosures, drives, and servers).

Once a server is in production, it’s a good idea to make as few changes to the server as is practical. However, there may be times when your solution vendor advises you that there is a critically important firmware update for your drives. If this occurs, here are a few good practices to follow before applying any drive firmware updates:

Review the firmware release notes and confirm that the update addresses issues that could affect your environment, and that the firmware doesn’t contain any known issues that could adversely affect you.

Install the firmware on a server in your lab that has identical drives (including the revision of the drive if there are multiple revisions of the same drive), and test the drive under load with the new firmware. For info about doing synthetic load testing, see Test Storage Spaces Performance Using Synthetic Workloads.

Automated firmware updates with Storage Spaces Direct

Windows Server 2016 includes a Health Service for Storage Spaces Direct deployments (including Microsoft Azure Stack solutions). The main purpose of the Health Service is to make monitoring and management of your hardware deployment easier. As part of its management functions, it has the capability to roll-out drive firmware across an entire cluster without taking any workloads offline or incurring downtime. This capability is policy-driven, with the control in the admin’s hands.

Using the Health Service to roll-out firmware across a cluster is very simple and involves the following steps:

• Identify what HDD and SSD drives you expect to be part of your Storage Spaces Direct cluster, and whether the drives support Windows performing firmware updates
• List those drives in the Supported Components xml file
• Identify the firmware versions you expect those drives to have in the Supported Components xml (including location paths of the firmware images)
• Upload the xml file to the cluster DB

At this point, the Health Service will inspect and parse the xml and identify any drives that do not have the desired firmware version deployed. It will then proceed to re-direct I/O away from the affected drives – going node-by-node – and updating the firmware on them. A Storage Spaces Direct cluster achieves resiliency by spreading data across multiple server nodes; it is possible for the health service to isolate an entire node worth of drives for updates. Once a node updates, it will initiate a repair in Storage Spaces, bringing all copies of data across the cluster back in sync with each other, before moving on to the next node. It is expected and normal for Storage Spaces to transition to a «degraded» mode of operation while firmware is rolled out.

To ensure a stable roll-out and sufficient validation time of a new firmware image, there exists a significant delay between the updates of several servers. Per default, the Health Service will wait 7 days before updating the 2 nd server. Any subsequent server (3 rd , 4 th , …) updates with a 1 day delay. Should an administrator find the firmware to be unstable or otherwise undesirable, she can stop further roll-out by the health service at any time. If the firmware has been previously validated and a quicker roll-out is desired, these default values can be modified from days, to hours or minutes.

Here is an example of the supported components xml for a generic Storage Spaces Direct cluster:

To get the roll-out of the new firmware started in this Storage Spaces Direct cluster, simply upload the .xml to the cluster DB:

Edit the file in your favorite editor, such as Visual Studio Code or Notepad, then save it.

If you would like to see the Health Service in action and learn more about its roll-out mechanism, have a look at this video: https://channel9.msdn.com/Blogs/windowsserver/Update-Drive-Firmware-Without-Downtime-in-Storage-Spaces-Direct

Frequently asked questions

Will this work on any storage device

This will work on storage devices that implement the correct commands in their firmware. The Get-StorageFirmwareInformation cmdlet will show if a drive’s firmware indeed does support the correct commands (for SATA/NVMe) and the HLK test allows vendors and OEMs to test this behavior.

After I update a SATA drive, it reports to no longer support the update mechanism. Is something wrong with the drive

No, the drive is fine, unless the new firmware doesn’t allow updates anymore. You are hitting a known issue whereby a cached version of the drive’s capabilities is incorrect. Running «Update-StorageProviderCache -DiscoveryLevel Full» will re-enumerate the drive capabilities and update the cached copy. As a work-around, we recommend running the above command once before initiating a firmware update or complete roll-out on a Spaces Direct cluster.

Can I update firmware on my SAN through this mechanism

No — SANs usually have their own utilities and interfaces for such maintenance operations. This new mechanism is for directly attached storage, such as SATA, SAS, or NVMe devices.

From where do I get the firmware image

You should always obtain any firmware directly from your OEM, solution vendor, or drive vendor and not download it from other parties. Windows provides the mechanism to get the image to the drive, but cannot verify its integrity.

Will this work on clustered drives

The cmdlets can perform their function on clustered drives as well, but keep in mind that the Health Service orchestration mitigates the I/O impact on running workloads. If the cmdlets are used directly on clustered drives, I/O is likely to stall. In general, it is a best practice to perform drive firmware updates when there is no, or just a minimal workload on the underlying drives.

What happens when I update firmware on Storage Spaces

On Windows Server 2016 with the Health Service deployed on Storage Spaces Direct, you can perform this operation without taking your workloads offline, assuming the drives support Windows Server updating the firmware.

What happens if the update fails

The update could fail for various reasons, some of them are: 1) The drive doesn’t support the correct commands for Windows to update its firmware. In this case the new firmware image never activates and the drive continues functioning with the old image. 2) The image cannot download to or be applied to this drive (version mismatch, corrupt image, …). In this case the drive fails the activate command. Again, the old firmware image will continue function.

If the drive does not respond at all after a firmware update, you are likely hitting a bug in the drive firmware itself. Test all firmware updates in a lab environment before putting them in production. The only remediation may be to replace the drive.

How do I stop an in-progress firmware roll-out

Disable the roll-out in PowerShell via:

I am seeing an access denied or path-not-found error during roll out. How do I fix this

Ensure that the firmware image you would like to use for the update is accessible by all cluster nodes. The easiest way to ensure this is to place it on a cluster shared volume.