KB5066835 issues - 24H2 - Machines resetting randomly

[DJRober]

Hi

Just rolling out KB5066835 across our W11 24H2 estate via SCCM, and have had some W11 devices apply the patch, but then the machine resets/wipes back to factory settings?

Varying model etc - just says now rebooting after the patch has applied in Software Centre, then screen goes black, and then says RESETTING your computer?

** UPDATE - THIS IS NOW HAPPENING RANDOMLY ON ALL MACHINES WITHOUT WARNING - SCREEN JUST GOING BLACK AND THEN SAYING RESETTING - Machines are then out of the box wiped **

Can anyone help? Can't look at log files as the machines have wiped before we can get to them.

They are co-managed with SCCM and InTune - the machines after wipe remain on on prem AD but disappear from InTune

 

[ChatGPT]

Hi Neil — sorry you’re hitting this in a rollout. Short answer: this is a known problem linked to the October KB5066835 cumulative update and Microsoft has released an out‑of‑band fix (KB5070773) plus a Known Issue Rollback / mitigation guidance. Stop the rollout now and follow the remediation steps below. What’s happening (short)

• The October cumulative (KB5066835) introduced recovery/quality regressions that in some environments drive devices into recovery flows or other failure states. Microsoft documented the issue and provided a KIR/workaround for enterprises.
• Microsoft published an out‑of‑band update (KB5070773) that fixes the WinRE/USB input problems and is the recommended emergency patch. Deploy that to healthy machines as soon as possible.
  Immediate steps (do these now)
• Pause the deployment to the rest of the estate
• Remove the update from any SCCM collections / deployment rings and pause Intune/WUfB rings. Do not let the package continue to install while you investigate.
• Deploy the Microsoft OOB fix (KB5070773) to bootable systems
• Target KB5070773 via your normal patch channels (SCCM/WSUS/Intune/WSUS catalogs). This is Microsoft’s fix for the WinRE/USB problem and should be pushed to devices that are still booting to the desktop.
• If devices are already in “RESETTING your PC” / wiped
• If the device is already resetting or has been wiped: you will likely need to reimage / provision them. If you have remote management (vPro/AMT, iLO, etc. use that to mount media or capture logs before reprovision.
• Be aware WinRE USB/keyboard may be non‑functional on affected machines until KB5070773 is installed — alternate access methods (PS/2 keyboard, touchscreen, or remote KVM) can let you interact with recovery UI. Community reports also note these workarounds.
• Use Known Issue Rollback (KIR) / Group Policy for enterprise managed devices
• Microsoft published a special Group Policy/KIR to mitigate the issue for managed devices — deploy that while you stage the OOB fix. This is an important enterprise mitigation path until you’ve fully remediated.

If you must roll back KB5066835 (last resort)

• Microsoft documents that LCUs combined with SSUs can complicate removal — use DISM to list/remove packages if wusa fails. Commands you’ll use on an affected machine (test first!:
• DISM /Online /Get-Packages (find the LCU package name)
• DISM /Online /Remove-Package /PackageName:<LCU-package-name>
• Some admins successfully used wusa /uninstall /kb:5066835 (or wusa /uninstall /kb:5065789 if present), but results vary if SSU was included. Test on a nonproduction device and coordinate with security teams because uninstall re‑exposes the security fixes.

Notes on Intune / Autopilot / devices disappearing

• If the machines were wiped / Autopilot reset during this process they may re‑enroll differently or appear removed from Intune until they complete Autopilot/OOBE enrollment. Microsoft has introduced/update behavior where devices can install quality updates during OOBE which may change the provisioning flow — that can explain why wiped devices land in AD but temporarily disappear from Intune until enrollment finishes. Check your Autopilot/ESP settings and pause quality updates during OOBE if needed.
  What I recommend you do next (practical order)
• Pause/withdraw the KB5066835 deployment in SCCM and pause Intune rings. (Stop more damage.
• Target‑deploy KB5070773 to any devices that are still online and bootable (SCCM, Intune).
• For wiped devices: reimage from your known good image or use Autopilot reprovisioning; use remote KVM/PS/2 where needed to get past WinRE. Capture the device name/serials so you can correlate which machines were affected.
• If you need to rollback on test devices, use DISM/wusa as above and validate behavior before rolling back production.
• After you’re stable, run a small pilot and monitor before any further broad rollout.

Logs / evidence to collect (for root cause / vendor/MS support)

• If you can capture any of these before reimage: Windows Update logs, SetupAPI logs, %windir%\panther\setuperr.log, C:\Windows\System32\LogFiles\CBS\CBS.log, and SCCM client logs. If devices are wiping too fast to collect, capture the failure device IDs and image one for postmortem.

Questions for you

• How many devices have been affected so far?
• Are affected devices Autopilot / hybrid‑joined / enrolled in Intune prior to the update?
• Do you have remote management (vPro/ILO/etc. or PS/2 ports available for the affected models?
• Have you already paused the SCCM deployment or do you want exact steps to withdraw the package from SCCM?

If you want, tell me:

• number of affected machines and one model example, and I’ll draft exact SCCM/Intune rollback/targeted deployment steps and a short runbook you can hand to your onsite techs so they can recover machines without losing more data.

References (Microsoft + reporting)

• KB5066835 (October 14, 2025) update page — known issues & uninstall notes.
• KB5070773 (October 20, 2025) out‑of‑band update (WinRE/USB fix).
• Microsoft KIR / Group Policy mitigation for enterprise-managed devices.
• Press/coverage and community reports about the WinRE issue and practical workarounds.
  If you want I can:
• provide the exact SCCM steps to un‑deploy/withdraw the KB, and the detection/requirement rules to target KB5070773; or
• draft the PowerShell/DISM commands to try on a test machine and a short runbook for onsite techs to recover a single affected PC.

Tell me which of the above you want me to produce next and the count/models you’re seeing affected.