Automox / Windows - Troubleshooting a Repeated Cumulative Update and Reboot Loop

Purpose

Use this when an endpoint appears to install the same Windows cumulative update repeatedly and restarts on a recurring schedule, especially when patching is orchestrated by Automox or another third-party platform.

First prove the reboot source

Do not assume every overnight restart is Windows Update. Check the graceful restart event around the reported time:

$Start = (Get-Date).Date.AddDays(-1)
$End   = Get-Date

Get-WinEvent -FilterHashtable @{
    LogName   = 'System'
    Id        = 1074
    StartTime = $Start
    EndTime   = $End
} | Select-Object TimeCreated, ProviderName, Message

Event ID 1074 from User32 identifies a planned restart or shutdown and usually includes the initiating process and reason.

Also review Windows Update activity near the same window:

Get-WinEvent -LogName 'Microsoft-Windows-WindowsUpdateClient/Operational' `
  -ErrorAction SilentlyContinue |
  Where-Object { $_.TimeCreated -ge $Start } |
  Select-Object TimeCreated, Id, LevelDisplayName, Message |
  Sort-Object TimeCreated

Record the actual Windows version and revision

Do not rely on a package filename or CBS package string alone.

Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion' |
Select-Object ProductName, DisplayVersion, CurrentBuild, UBR

The important values are:

DisplayVersion: release such as 24H2 or 25H2.
CurrentBuild: base OS build.
UBR: update build revision.

Capture these values before and after a test installation.

Do not infer applicability from a servicing package build string

Windows 11 24H2 and 25H2 share a common core operating system and identical system files. 25H2 is enabled from the common 24H2 servicing base by an enablement package.

That means a 25H2 device reporting build 26200.x can legitimately receive update metadata or servicing-stack components in the 26100.x family.

Microsoft documents some monthly cumulative updates as applying to both Windows 11 25H2 and 24H2, producing paired builds such as 26200.x and 26100.x. Seeing a CBS entry such as Package_for_RollupFix...26100.x on a 26200.x system is not evidence by itself that the wrong update was targeted.

Use a manual install as an applicability test

If Windows Update or the Microsoft Update Catalog offers the KB and the endpoint can install it manually, compare the build before and after.

Example logic:

Before: CurrentBuild 26200 / UBR 8037
After:  CurrentBuild 26200 / UBR 8246

If the UBR advances to the Microsoft-documented target revision, that proves the update was applicable and successfully committed on that endpoint.

At that point, stop troubleshooting a supposed OS-build mismatch and investigate why the managed deployment path did not reach the same end state.

If the update works manually but repeats under Automox

A successful manual installation does not by itself prove an Automox product defect. It narrows the fault domain to the managed deployment and detection path.

Check:

Automox activity result and exit status for the affected patch run.
Pending restart state. Automox can show a device as Needs Restart when installation is not complete until reboot.
Agent logs:

Get-Content 'C:\ProgramData\amagent\amagent.log' -Tail 1000

For an older incident, collect the full or rotated log rather than only the tail.

Windows Update log:

Get-WindowsUpdateLog -LogPath 'C:\Temp\WindowsUpdate.log'

Search around the failed or repeated run time for the KB number, FAILED, and Windows Update error codes.

CBS servicing log:

Select-String -Path 'C:\Windows\Logs\CBS\CBS.log' `
  -Pattern 'KB1234567','error','fail' -CaseSensitive:$false

Replace KB1234567 with the actual article.

Patch detection refresh. After confirming the KB installed locally, force a fresh Automox device scan and check whether the patch disappears from Needs Patching.

Component-store checks

If repeated attempts are accompanied by servicing errors, check the Windows image before blaming the patching platform:

DISM /Online /Cleanup-Image /ScanHealth
sfc /scannow

A clean component store removes one common cause. Info-level CBS staging lines alone do not prove that an automated update run completed successfully.

Containment versus remediation

Temporarily ignoring or excluding a repeatedly offered KB in Automox can stop a disruptive reboot loop. Treat that as containment, not the final fix.

If the KB has already been installed manually and the build/UBR confirms success:

force an Automox rescan
verify the endpoint now reports compliant
remove any temporary exclusion when the patch is no longer incorrectly detected

If the managed platform still offers an already-installed patch after a fresh scan, preserve the agent and activity logs and escalate the detection or install discrepancy.

Validation

A clean result should show all of the following:

The endpoint's CurrentBuild and UBR match the expected Microsoft build for the installed KB.
Windows Update history and CBS show the update committed successfully.
Automox no longer lists the KB as needed after a fresh scan.
The recurring scheduled reboot stops.
No new servicing errors appear.

Catches / gotchas

A repeated patch and reboot loop is not automatically an OS corruption problem.
A 26100 servicing identifier on Windows 11 25H2 build 26200 is not automatically a mismatch. 24H2 and 25H2 share a common servicing core.
Excluding the KB can stop disruption. Verification and rescan are still required so the endpoint does not remain silently noncompliant.

Key lesson

The strongest applicability test is Microsoft's supported-build documentation plus the endpoint advancing to the expected build and UBR. If a manual install succeeds but the managed path keeps offering the same KB, investigate install, reboot, and detection in the management platform. Do not call it a product defect until the logs prove it.