October 2026 Windows Update causing major issues

Microsoft send me this:

The fix for this issue has been released for the following OS:

You can download the KBs from https://catalog.update.microsoft.com/Search.aspx?q=KB5127936

https://support.microsoft.com/en-us/servicing/os/windows-11/2026/10/kb5127936-windows-11-25h2-26h2-update

rollback and install this KB and its work for me now. 

Same issue here: Dell Pro 14 Plus PB14250 (BIOS [Version des geretteten Geräts]), Windows 11 25H2, Intune/Autopatch managed. After KB5127648 the device loops in Automatic Repair; Safe Mode and "Uninstall latest quality update" fail.

What fixed it for us:

1. BIOS (F2) > Virtualization Support > Enable Intel Trusted Execution Technology > Off
2. Boot into Windows and sign in (have the BitLocker recovery key ready)
3. Back into BIOS > Intel TXT > On
4. Boot again - the device runs normally

What our logs show:

• Intel TXT / System Guard Secure Launch is active on every boot (Kernel-Boot/Operational event 210, SINIT).
• The failed boots leave no trace at all: no System events, no CBS.log entries, no crash dump. The failure happens very early in boot.
• No lsass.exe termination (event 1074), so this is not the KB5058379 TXT issue from May 2025, although the BIOS-side workaround is similar.
• After the rollback, Windows Update reports 0x800f0845 for KB5127648.
• On one device the build 26100/26200.9711 ran fine for two days and failed on a later restart, so it may not hit on the first reboot.

We are now piloting: switch TXT off via Dell BIOS WMI before the update reboot, switch it back on afterwards (Intune remediation). Will report results.

Has anyone else confirmed the TXT toggle? Which models and BIOS versions?

Hello I tried booting safe mode but it’s just got stuck in hp logo screen without circling, what to do? My computer doesn’t boot anymore, auto relate and system rd over failed. Unable to uninstall windows update from advance option, I disabled secure boot, I’m not tech person and looking for help

same issue here

The affected devices we checked have a TPM-only protector (PCR 7, 11) and no recovery password protector, and no recovery key in Intune (dont know why yet). At the time of failure, BitLocker was suspended (the volume was accessible from WinPE without a key).

The healthy reference device (same model and firmware, on 9711) has a TPM protector and a recovery password.

On those two previously failing devices (Dell and a Dynabook ), we added a recovery password protector, backed it up to Entra ID, resumed BitLocker, then reinstalled KB5127648 and KB5127690. Both devices rebooted normally and are now on 26200.9711.

Workaround that works (from WinPE/WinRE):

manage-bde -unlock C: -RecoveryPassword <key>
dism /image:C:\ /cleanup-image /revertpendingactions

Same thing happening here. We delayed a KB5127648 a week (until Friday 23/10) and this morning we came back to work with a bunch of clients reporting similar issues. 

We did work out that jumping into CMD in RE, and using command [bcdboot c:\Windows] fixes the issue if the device is stuck in a Windows RE Boot loop. 

Hey, I'm just some guy who used to work in software, sorry to barge in. This seemed like a good place to report all the desktop experience issues I've had with a machine that was pretty well isolated from other variables when the PC took this update. My machine is pretty well unusable and lots of programs are failing in a way that makes me suspect something OS related.

It's really annoying. Many actions don't take the first time? And it takes forever to think about everything, and licensing stuff is failing for audio plugin PACE and not launching at all, and there are technical error messages with the Circle-X icon.

Oh and there's a mysterious new blank icon in my tray that doesn't do anything.

Any chance you guys having the problem are using Threatlocker?

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.