"Pending reboot" has at least five sources and your tooling probably checks one

An update installs cleanly. The device reports no restart required. Three weeks later your vulnerability scanner is still flagging the CVE that patch was supposed to close.

Or the mirror image: a laptop has reported restart pending for eleven days, has been rebooted six times, and every new cumulative update on it fails.

Both are the same defect, and it is almost never in Windows. It is in the thing doing the checking. "Pending reboot" is not a flag. It is a minimum of five independent markers, each owned by a different component, written at different times and cleared by different code. Most RMM and compliance tools check one.

The problem: one flag checked, five that matter

This failure has two shapes that look like opposites. They are the same blind spot seen from two sides.

The false negative. Your report says the KB is installed, Get-HotFix agrees, the device says no restart required. But the binaries on disk are still the old ones, because the replacement was deferred to boot and that boot never drained the queue. The patch is registered, not in effect.

The false positive. A device reports reboot-pending permanently. Users reboot; it comes back. Every subsequent update fails, because Windows Update genuinely refuses to install while a mandatory restart is outstanding. That refusal is documented behaviour, not a bug.

Here is the check that ships inside a startling number of monitoring scripts.

Read that first command again. It asks for the values inside a container that has no values in it. RebootPending is a key: it exists or it does not, and its existence is the signal. Microsoft's own reference script enumerates subkey names with GetSubKeyNames() and tests for the string RebootPending among them, precisely because there is no value to read.

So the tool returns $null, the rule evaluates to compliant, and the device sails through reporting with fourteen queued file replacements and a blocked servicing stack.

Why it happens: five owners, one label

There is no single flag because no single component owns "restart". Servicing, Windows Update, the file system, the computer identity and your management agent each have their own reason to want one, and each records it their own way.

Microsoft enumerates this directly. The Microsoft.Windows/RebootPending resource states a reboot may be required due to Windows Updates, Component-Based Servicing, pending file rename operations, pending computer rename, or pending domain join. Five causes, one boolean. That resource is explicitly a proof-of-concept, but its list is the clearest official statement that the answer is a union of independent checks.

The five authoritative sources

A sixth exists where it applies: a pending domain join, recorded by Netlogon under HKLM\SYSTEM\CurrentControlSet\Services\Netlogon. Microsoft's documentation for JoinDomainOrWorkgroup is explicit that the computer must be restarted afterwards.

Inside the CBS parent key

Component-Based Servicing is where most real patching pain lives. Everything below hangs off one parent.

Shared parent key for the table below. All three are subkeys, tested with Test-Path.

Why a stuck CBS flag blocks the next update

This is what turns a cosmetic reporting problem into a patching outage, and it dictates the fix.

When CBS installs a component and a target file is in use, it cannot swap it there and then. It writes the outstanding primitive and advanced installer operations into a transaction file at %windir%\WinSxS\pending.xml, to be applied on the following boot before the files are referenced.

That transaction is why the flag exists. RebootPending is not a reminder to the user; it is the stack recording that it holds an open, incomplete transaction. A servicing stack with an open transaction will not begin a new one, because that would interleave two sets of component changes over the same store.

So the loop is: the queue does not drain, because a file is still locked, store permissions are wrong, or the transaction is damaged. The flag is rewritten. The next cumulative update requests a session, is refused, and fails. Delete the flag by hand and it returns on the next boot, because pending.xml is still there and the stack re-derives its state from the transaction, not from the flag.

Windows Update surfaces the refusal with a documented code. WU_E_INSTALL_NOT_ALLOWED, 0x80240016, is defined in Wuerror.h as an operation that "tried to install while another installation was in progress or the system was pending a mandatory restart." Its benign sibling WU_S_REBOOT_REQUIRED, 0x00240005, means the system must be restarted to complete installation. Repeated 0x80240016 on one device points at a stuck transaction rather than content or connectivity.

The binaries involved

TrustedInstaller and the operations it performs write to %windir%\Logs\CBS\CBS.log, where you go once the registry has told you which marker fired.

How to verify: a read-only sweep of every source

Work through this in order. Every step is read-only. You are identifying which marker fired, because that determines the fix, and a wrong guess turns a five-minute job into a reimage.

1. Establish whether a restart actually happened. Check the System log for User32 Event 1074, which records a planned restart with the requesting process and a reason code. If the device genuinely never restarted, you have a compliance problem, not a servicing one.
2. Sweep all markers at once with the script below. Never check them one at a time; the point is seeing which ones disagree.
3. Only Auto Update\RebootRequired set, CBS clean: an ordinary Windows Update restart still owed. Benign.
4. Only PendingFileRenameOperations populated: read its contents first. This is usually a third-party installer or AV update, not Windows servicing, and clears on the next boot.
5. CBS RebootPending set: check whether %windir%\WinSxS\pending.xml exists and enumerate PackagesPending. This is the branch that blocks future updates, and those two artefacts name the stuck package.
6. CBS RebootPending persisted through a confirmed restart (an Event 1074 after the flag was set): a stuck transaction. Go to CBS.log and search for the package named in PackagesPending.
7. Markers clean but ConfigMgr still reports pending: the client's state is stale and the fix belongs on the agent, not in the registry.

The script below checks every source in one pass and reports which fired. It reads only; there is no remediation in it by design.

Two design choices matter. The CBS and Auto Update checks use Test-Path because their markers are keys; Session Manager uses Get-ItemProperty because its marker is a value. Mixing those up is the original sin of every broken reboot report.

The ConfigMgr branch is guarded because root\ccm\ClientSDK does not exist on an Intune-only device, where an unguarded call throws.

Here is the output from a device in the bad state, where the flag outlived a restart.

CBS set with Windows Update clear is the signature of the blocked-servicing case, and exactly what a single-source check misses most often, because many tools check the WindowsUpdate\Auto Update location rather than the CBS one.

Now name the stuck package, still read-only.

That format is frequently misread as a list of single files. It is a sequence of null-terminated pairs: source then destination is a rename on boot, source then an empty entry is a delete on boot. Session Manager processes them in issue order, and entries come from any process calling MoveFileEx with the delay-until-reboot flag.

Above, that is a vendor agent replacing its own DLL, not Windows servicing: clearing the CBS key would do nothing for it.

Event ID catalog

All of the below is one channel: Microsoft-Windows-WindowsUpdateClient/Operational (Event Viewer: Applications and Services Logs, Microsoft, Windows, WindowsUpdateClient, Operational).

That last row is the false negative in one line. Event 19 plus a CBS RebootPending that never clears is a device your inventory calls patched and your scanner calls vulnerable.

The fix: match the remedy to the marker that fired

There is no single fix, because there was no single cause. Take the branch your diagnostic landed on.

Only Auto Update\RebootRequired. Restart the device. That is the whole fix. Do not touch the registry; this marker is the agent doing its job correctly.

Only PendingFileRenameOperations. Read the pairs, identify the owning product, restart. If it repopulates every boot with the same pairs, the fault is that vendor's installer. Do not delete the value: you would be cancelling a file replacement some product depends on, occasionally half of an update.

A computer rename is pending. Restart. To cancel it instead, set the value under the ComputerName key back to the currently active name so the two agree. Correct the configuration, do not delete the key.

CBS RebootPending set, no restart yet since servicing. Restart properly and re-run the diagnostic. A single clean boot resolves most of these, and everything below is then unnecessary.

CBS RebootPending survived a confirmed restart. This is the real case, and order of operations matters:

1. Capture evidence first. Save the PackagesPending subkey names, copy %windir%\Logs\CBS\CBS.log aside, note whether pending.xml exists. If this escalates to Microsoft, that is the package they will ask for.
2. Install the latest Servicing Stack Update. The stack repairs itself more often than people expect, an SSU is the documented first move for TiWorker and CBS failures, and it is the least invasive item here.
3. Let the transaction complete on its own terms. Reboot once more and leave the device at "Working on updates" without interrupting. poqexec.exe needs that window to drain the queue.
4. Then repair the component store. DISM /Online /Cleanup-Image /RestoreHealth, then SFC /ScanNow, in that order. SFC alone cannot repair a store whose own payload is damaged.
5. Treat deleting the CBS keys and pending.xml as a last resort, done knowingly and with a backup. It gets the device installing again, but it abandons an in-flight component transaction: expect to validate the affected KB and to reinstall the package the transaction belonged to.

Markers clean but ConfigMgr still pending. The client's cached state is stale. Trigger the client's own evaluation; never edit registry markers to make the agent happier. That is not where the client stores its state, and you would be lying to five other consumers to satisfy one.

Proof it worked: what a clean device looks like

Verify with the same read-only sweep, not by the device reporting itself compliant.

For reference, here is genuinely clean. Captured read-only from a live Windows 11 corporate device, build 26200.9168, during preparation for this article; all three primary markers were verified absent.

Three things make that a real verification rather than a hopeful one.

Every marker is reported, not just the failing one. A pass is all sources clean at once. Reporting only the marker you chased is how devices get closed out with a second flag still set.

pending.xml is gone, not just the flag. If the flag cleared but the transaction file remains, nothing is fixed and the flag returns on the next boot. That line is the difference between a fix and a reset.

A subsequent update installs. Trigger a scan, confirm an Event 26 followed by a 41, and confirm 0x80240016 is gone.

References

• Microsoft.Windows/RebootPending resource - the five documented causes.
• CheckForPendingReboot.ps1 - CBS RebootPending enumerated as a subkey.
• MoveFileEx function - how PendingFileRenameOperations is written and consumed.
• PendMoves and MoveFile (Sysinternals) - the pair format and delete semantics.
• WUA Success and Error Codes (Wuerror.h) - 0x80240016 and 0x00240005.
• DetermineIfRebootPending, CCM_ClientUtilities - ConfigMgr output parameters.
• Analyze log file entries that SFC.exe generates - %windir%\Logs\CBS\CBS.log.
• Troubleshoot unexpected reboots using system event logs - User32 Event 1074.
• Fix Windows Update corruptions and installation failures - DISM and SFC ordering.