Over the past year, there have been increasing reports of Windows systems “bricking” following a Windows Update. By “bricking,” I mean that the system becomes entirely non-responsive. Although incidence rates vary — ranging from negligible (0%) in some environments to as high as 0.25% of managed systems per month — the issue raises significant concerns about the reliability and transparency of automated firmware updates.
Disclaimer: The conclusions drawn here are based on multiple user reports and community discussions online. Individual experiences may vary, and the analysis presented may not capture every facet of the problem.
Background: Understanding Firmware Updates
Firmware, stored on the motherboard’s flash memory, controls critical low-level functions and system initialization. Historically these were updated using stand-alone tools, but for some time now manufacturers have also used UEFI Capsule Firmware Updates, a mechanism that enables firmware updates through the operating system, usually via Windows Update.
How UEFI Capsule Updates Work
Firmware updates are packaged as capsules, containing the new code and metadata about the update. The manufacturer publishes these to the operating system update mechanism, for example Windows Update. If Windows Update detects that a system is targeted for an update, it passes the capsule to the UEFI environment. Finally the UEFI firmware then processes the capsule, verifying its integrity before applying it to flash memory.
While this process is designed to reduce user intervention and simplify maintenance, it also introduces an additional layer of complexity and risk. An error in any part of this chain can potentially render a system inoperable.
What Are We Seeing?
Multiple users have reported that their systems become completely unresponsive after a Windows Update. The pattern appears consistent across several vendors, with affected systems primarily from Dell, HP, and Microsoft. The issue occurs on both brand-new and relatively new systems, suggesting that hardware age isn’t a significant factor.
Typical Recovery Methods
- CMOS Reset: In many cases, resetting the CMOS that stores configuration settings in non-volatile memory resolves the issue, allowing the system to boot normally again.
- BIOS/UEFI Reflash: In a smaller set of systems the firmware corruption requires professional intervention. This often requires gaining access to the motherboard and using specialized tools to reflash the BIOS/UEFI.
Potential Causes
The prevailing hypothesis is that OEMs are leveraging Windows Update to push firmware updates, and somewhere along this pipeline, the wrong or corrupted firmware is being applied. However, the process’s opacity makes it difficult to pinpoint whether the failure lies with:
- OEMs: A mispackaged or incompatible firmware update could be inadvertently deployed causing problems until recalled.
- Microsoft: Bugs or “features” in the Windows Update process might be mistargeting updates.
- Interaction Effects: The interplay between OEM updates, Windows Update, and the UEFI environment might lead to unforeseen conflicts.
Regardless of the exact cause, the end result is the same: systems that should be receiving routine firmware improvements instead become bricked.
Mitigation Strategies
The risk is quite low, but the user impact of a failure is high. Hence there may be reason to take action to help mitigate the issue:
1. Disable UEFI Capsule Firmware Updates
Some systems offer an option in the UEFI settings to disable “UEFI Capsule Firmware Updates.” By turning off this feature, many packaged firmware updates will not be applied automatically. However, this setting might not be available on all systems. It also does not stop tools that do not rely on the UEFI Capsule process for updates.
2. Control OEM Application Updates
Windows provides an option to disable the automatic download and installation of manufacturer-specific applications. To implement this, search for “Choose whether Windows downloads manufacturers’ apps” in your system settings.
3. Restrict Driver Updates (not recommended)
I don’t recommend this, but I am including it for completeness. It is possible to change Windows settings to disable automatic driver updates. While this can prevent inadvertent firmware updates, it also risks withholding beneficial updates that do not impact firmware. IT administrators must weigh the trade-offs of this option.
4. Consider OEM Update Utilities (YMMV)
Many manufacturers offer their own firmware update tools, which appear to have lower failure rates. While these tools are not without their own complexities and potential issues, they may offer a more controlled update process than Windows Update. Your mileage may vary.
What to Do When a System Bricks
If you encounter a bricked system, the following steps might help recover it:
- Initial Assessment: Determine whether the system is unresponsive due to a firmware issue by attempting to access the BIOS/UEFI settings. If the system fails to display the BIOS splash screen or UEFI interface, firmware corruption is possible.
- CMOS Reset: Power off the system and disconnect it from the power source. Remove the CMOS battery or use the motherboard’s reset jumper to clear the CMOS memory. Reconnect and power on the system. Note: This process resets all BIOS/UEFI settings to factory defaults, which may require reconfiguration.
- BIOS/UEFI Reflash: If a CMOS reset does not resolve the issue, the next step involves reflashing the firmware. This typically requires professional tools as it involves exposing the flash device on the motherboard and directly connecting to it with flash tools.
About the Author
With over 30 years of experience in computer diagnostic testing, I specialize in differentiating hardware failures from software-related issues. My company helps clients avoid unnecessary hardware replacements and ensures that systems operate reliably.
