Forum Discussion
October 2026 Windows Update causing major issues
We have had about 50 computers in our organization giving boot failures after Windows restarts to apply the October update, KB5127648. Affected machines are Dell devices, both laptops and desktops. The most common error message is "file missing or containing errors \windows\system32\winload.efi"
The only fix for now is to try booting into Safe Mode and uninstall the October update.
We use a 3rd party tool to patch our devices, Automox, but manually triggering updates from Windows Settings yields similar results. But what I have noticed is that when running Windows Update from Settings, multiple drivers and firmware udpates are also being installed, so I'm wondering if there is incompatibility with outdated stuff in our machines. So we're pushing Dell updates for drivers, firmware, and BIOS, along with Windows Updates hoping that this will take care of the issue.
Has anyone else experienced anything similar with this update? Or have any ideas on what may be the root cause in our case? Any feedback will be much appreciated.
8 Replies
We are seeing similar across our Dells, HPs, and Lenovo's. We started seeing it prior to the October update but has gotten worse with the October update. We are seeing one of two scenarios:
Scenario 1:
If BitLocker is fully and properly deployed, protection on and recovery keys created and backed up to AD and AAD the laptop will ask for the recovery key. Once entered the system realizes something went wrong and will roll back the patches, pause patching, and the machine operates fine.
Scenario 2:
If BitLocker isn't fully and properly deployed, didn't create or save a recovery key then the system enters an Automatic Repair blue screen and is trapped in that state.
One thing we tried on a Dell that worked was disabling the TPM, letting the patches install, after a reboot we rebooted again and reenabled the TPM. When it started up after reenabling the TPM the system should an automatic recovery and rebuilt the TPM with the new information that was causing the mismatch and the system boots fine now with patch installed.
It appears to be related to the PCR7 check that is done and the patches making changes that the hardware doesn't know about or wasn't ready for.
I haven't been able to identify a single root cause, but we've had success getting devices patched by going through Windows Update settings and making sure that all driver and firmware updates are installed, along the monthly Windows Updates. For our Dell 16 Pros, a repeated firmware update is 2.18.1.0
We also have Dells 5500 and those seem to need firmware 1.26 or 1.27.
I don't know if this is the cause, but it's the only consistent correlation that I've been able to identify.
In our case, the update is already seeded in most machines, just pending a reboot, so we'll have to deal with the boot failures to later patch systems.
A missing or corrupt winload.efi right after a servicing reboot usually means the boot files on the EFI System Partition could not be updated cleanly, not that the OS volume is damaged. Some things I would check:
- ESP free space. A small ESP (100 MB) that is nearly full is a classic cause of boot file updates failing halfway. Compare the affected Dells with a few healthy ones of the same model.
- BIOS and Secure Boot state. Compare BIOS version, Secure Boot on or off, and the Secure Boot certificate state between affected and unaffected machines. Boot manager and certificate servicing has been touching this area, and old Dell firmware is where it tends to break. The Secure Boot servicing events (1795, 1796, 1801) in the System log can show whether it started and failed.
- Find the pattern. Group the 50 by model, BIOS version, BitLocker state and the date the update landed. If they share one or two models or an older BIOS, that is your root cause, and the Dell BIOS update you are already pushing is the right fix.
Until you know the cause, hold the update on any Dell model that has not taken it yet, and run it through a small pilot group first. Staged rings are what keep a bad update at 5 machines instead of 50.
Thank you for your response. I'll check the items you've mentioned.
Unfortunately, I work for a financial institution where cyber security is a top priority so there is a little obsession with patching and presenting pristine numbers to stakeholders, so staging and testing updates has not been part of the protocol. Hopefully this changes people's mindset.
Our organization facing the same issue and we have our servers on AWS. we have put patching on hold and continuously working on to figure out the root cause and remediation to avoid further impact
We are currently seeing a very similar issue with two different customers, both using Dell OptiPlex Micro 7010 systems.
The devices fail to boot into Windows and end up in the Automatic Repair loop with “Your PC did not start correctly”. Since we have now seen the same behavior on two separate customer environments with the same Dell model, we are wondering whether this could be related to the October update, drivers, firmware, or BIOS.
Did you manage to identify the root cause or find a reliable fix? Did uninstalling KB5127648 solve the issue for you?
We are seeing a very similar issue with two different customers, both using Dell OptiPlex Micro 7010 devices.
Both systems suddenly fail to boot into Windows and end up in Automatic Repair / “Your PC did not start correctly”.
Have you found a reliable solution or identified the root cause in your environment? Did uninstalling the October update resolve the issue permanently?
Where I don't have a fix, the correct way, make sure BIOS storage is set to whatever it normally uses (I say this because it was noticed that the storage was changing from AHCI to RAID and had to be changed back to AHCI) and disable secureboot, vt-d and vt-x, save and reboot.
