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)

1. 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.
2. 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.
3. 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.
4. 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)

1. Pause/withdraw the KB5066835 deployment in SCCM and pause Intune rings. (Stop more damage.)
2. Target‑deploy KB5070773 to any devices that are still online and bootable (SCCM, Intune).
3. 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.
4. If you need to rollback on test devices, use DISM/wusa as above and validate behavior before rolling back production.
5. 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.