The update that installs at every boot and never finishes: reading pending.xml and the primitive operations queue

There is one Windows Update failure that outlives every fix in the standard playbook. The device reboots, shows Working on updates, climbs to somewhere between ten and thirty per cent, then announces that it is undoing changes. It boots back to the desktop. Next reboot, the same screen, the same update, the same reversal. Forever.

Clearing SoftwareDistribution does nothing to it. Nor does sfc /scannow. That is not bad luck: the failure is neither in the download nor in the live file set. It sits in a queue of file and registry operations that Windows wrote to disk, scheduled for the next boot, and could not complete.

That queue has a name, a file, its own executable and its own log. Most advice about it can name only the file, and recommends deleting it.

The problem: the update that installs at every boot and never finishes

The user-visible symptom is a servicing loop. Every restart re-enters the update screen, fails, reverts, and lands back on the desktop with the same update still listed as pending.

What makes it different from an ordinary download error is when it happens: before the shell is up, in a phase of boot where nothing can tell you anything except a percentage. So the reflex is to attack the only thing visible. Someone finds a forum post and deletes or renames C:\Windows\WinSxS\pending.xml. Sometimes the loop stops. That is not the same as the device being fixed.

Four readable facts settle the diagnosis, and none of them changes the device.

1. What state does the servicing stack think the package is in — Staged, Install Pending, or Installed?
2. Does pending.xml exist, and if so, how big and how old?
3. What did poqexec.log record for the last queue?
4. Does the Setup log show the package advancing, or the same reboot-required event repeating?

Why it happens: a transaction that only a boot can close

The servicing stack, and the one thing it cannot do

Microsoft defines the servicing stack as "the component that installs Windows updates", and states that it "contains the component-based servicing stack (CBS), which is a key underlying component for several elements of Windows deployment" — DISM, System File Checker, changing Windows features or roles, and component repair.

CBS is transactional: an update either applies completely or it is rolled back. But CBS runs inside the operating system it is modifying, and there is one thing it cannot do from there — replace a file that running Windows has open, or rewrite a registry key a loaded hive is holding.

So servicing splits in two. What can be done live is done live: payload expanded, component directories created in WinSxS, manifests registered. That phase ends with the package Staged. What cannot be done live is written down as a list of low-level file and registry operations, and deferred. Those are primitive operations, and the list of them is a primitive operations queue, or POQ.

Where the queue lives, and what runs it

The queue is serialised to XML at C:\Windows\WinSxS\pending.xml and executed at the next boot by poqexec.exe, which runs before Windows is fully up — which is exactly why a progress percentage is all you get.

You do not have to take a blog's word for what POQ stands for. The binary says so itself, in metadata read from the lab device used for this article:

Note the version: 10.0.26100.9156 on a device whose OS build is 26200.9168. It is versioned with the servicing stack, not the OS — because it is part of the servicing stack.

The binaries worth knowing by name

These are the names that appear when you are reading CBS.log at two in the morning, with paths and versions read from the lab device.

The documented rule that turns a stuck queue into a loop

This is why one stuck update stops every subsequent update rather than just failing alone. Microsoft states it in the DISM Limitations section:

"When you are installing a package in an offline image, the package state is 'install pending' because of pending online actions. In other words, the package will be installed when the image is booted and the online actions are processed. If subsequent actions are requested, they cannot be processed until the previous pending online action is completed."

That is the loop, stated as documentation. A queue that cannot complete never clears, and a queue that never clears blocks the next servicing operation — so the next cumulative update stages, is refused, and tries again at the following boot.

The states you are actually diagnosing

"Pending" is not one state. Microsoft's DISM API enumerates eight.

A package sitting at Staged for weeks is a different fault from one at Install Pending. Staged means the commit never started; Install Pending means it started and did not finish.

How to verify: read the queue before you touch it

Everything here is read-only. Work through it in order.

Step 1 — read the Setup event log first

Microsoft's own Windows Update repair article opens with this instruction: "You can check the Setup event log for errors." That channel is Applications and Services Logs > Setup, and the provider writing servicing state changes into it is Microsoft-Windows-Servicing. It is the highest-value log for this failure because it records state transitions, not just errors.

Honest caveat: Microsoft publishes no reference catalogue for Microsoft-Windows-Servicing event IDs. The message strings above are the real ones from the lab device, not documented text. The Setup channel itself, and the instruction to check it, are documented.

The query that matters is not "show me errors" but "show me one package's whole life".

Learn that shape: the broken version is the same trace with the last line missing and the fourth repeated.

Step 2 — ask the servicing stack what state it thinks the package is in

Do not trust Settings: the Windows Update UI can say "installed" while CBS still has the package pending. Ask CBS directly.

Microsoft's Stop 7B article uses the offline equivalent as its first diagnostic step — Dism /Image:<OS drive>: /Get-packages — noting you will then "see the Install pending and Uninstall Pending packages". Use that form if the device will not boot at all.

Step 3 — check for the queue file itself, without opening it in place

On the lab device pending.xml is absent, the expected clean-state answer. Presence is not automatically a fault either — a device that staged an update and has not rebooted will legitimately have one. What matters is existence, size and age together.

Step 4 — read poqexec.log, and know its limits

poqexec.exe writes to C:\Windows\WinSxS\poqexec.log. On the lab device that file is 5,321 bytes and holds 21 entries going back to April 2025 — roughly one a month, the cadence of cumulative updates plus reboots. There is no equivalent file in C:\Windows\Panther here; Panther holds Windows Setup's own logs, setupact.log and Setup.etl, which are a different phase of a different process. Here is the tail of the real file, unedited.

The GUID suffix is redacted only because it embeds the device's MAC address. The Transaction UoW value is the useful part: search CBS.log for it to correlate a boot-time queue back to the servicing session that created it.

Step 5 — find the registration in CBS.log

CBS.log is documented at %SYSTEMROOT%\Logs\CBS\CBS.log, with rolled archives beside it as CBS.persist.log and CbsPersist_*.cab. It names the registry value that ties the queue to boot.

Registration happens during ordinary CBS transactions, so its presence in the log means nothing on its own. Assuming otherwise is a classic two-hour dead end.

Step 6 — check the boot-time registry markers

Session Manager runs native-mode programs before the Win32 subsystem starts. The familiar example is BootExecute, which is how autochk runs before Windows. SetupExecute is its servicing sibling.

Two further keys complete the picture, both named in Microsoft's documentation.

Step 7 — land on a root cause

With steps 1 to 6 done you should be on exactly one of these four.

1. Nothing is wrong. Install Pending, one Event 4, pending.xml newer than the last boot. Reboot. Most common outcome.
2. Stuck queue. Event 4 repeating per boot, never advancing past Install Pending, pending.xml older than several boots. Use the recovery below.
3. Store damage under the queue. Event 1014 with a non-zero corruption count, or a package reading Partially Installed. Repair the store first; the queue is a symptom.
4. Never got as far as a queue. Stuck at Staged, no Event 4, no pending.xml. Nothing is deferred, so nothing boot-time is broken — this is a download, applicability or policy problem, and none of the next section applies.

The fix: the documented order, and why the shortcut is worse

What Microsoft actually documents

The documented recovery is Dism /Cleanup-Image /RevertPendingActions, and the documentation is unusually blunt about its scope:

"If you experience a boot failure, you can use the /RevertPendingActions option to try to recover the system. The operation reverts all pending actions from the previous servicing operations because these actions might be the cause of the boot failure. The /RevertPendingActions option is not supported on a running operating system or a Windows PE or Windows Recovery Environment (Windows RE) image. Important: You should use the /RevertPendingActions option only in a system-recovery scenario on a Windows image that did not boot."

Read that carefully, because it is easy to misread. The option is not supported against a running OS — you cannot point it at /Online. You run it from WinRE, targeting the offline volume with /Image:, as Microsoft's Stop 7B article does. Documented ways in: Shift while selecting Restart, Settings > Recovery > Advanced startup, or recovery media. WinRE also starts itself after "two consecutive failed attempts to start Windows".

The full documented sequence, in order

This is Microsoft's Stop 7B procedure, condensed. The ordering is the point.

1. Boot to WinRE and open Command Prompt.
2. Run Dism /Image:<OS drive>: /Get-packages and record which packages read Install pending or Uninstall Pending. Evidence first.
3. Run dism /Image:C:\ /Cleanup-Image /RevertPendingActions, substituting your real partition letter. This step unwinds the transaction rather than abandoning it.
4. Only now: if <OS drive>\Windows\WinSxS\pending.xml still exists, rename it to pending.xml.old.
5. Load <OS drive>\Windows\System32\config\COMPONENT as a hive, back up the key, delete PendingXmlIdentifier if present, unload.
6. Load the SYSTEM hive, find the active ControlSet via Select\Default, and under Control\Session Manager back up and delete PendingFileRenameOperations if present. Unload.

Why "just delete pending.xml" is dangerous

The advice is not wrong because the file is sacred. It is wrong because of what it leaves behind.

A POQ is one half of a transaction whose other half is already applied: component directories created in WinSxS, manifests registered, and the store's own metadata pointing at a specific queue via PendingXmlIdentifier. Deleting the queue rolls none of that back. It removes the instruction list and leaves the half-finished state. Microsoft's own error taxonomy names the outcomes precisely:

That last row is the clearest possible description of the damage: the directory exists, the file does not, and the list that would have put the file there has been deleted.

What Microsoft does not document

The boundary matters here, because the gaps are exactly where bad advice grows.

• No Microsoft reference page for poqexec.exe. It appears in Microsoft Q&A threads and error strings, and its file description names it, but there is no documented command line, no documented switches and no supported way to run it by hand. If a procedure tells you to invoke it manually, it is not from Microsoft.
• No documented schema for pending.xml, and no supported way to edit it.
• No documented reference for the SetupExecute value. What is verifiable is that CBS names it in its own log and that it reads empty on a healthy device.
• No documented format for poqexec.log. The field meanings above come from the file's own labels; the timestamp decode is inference from a clean FILETIME conversion, not documentation.

Proof it worked: one KB traced across three logs

A fix is proven when the package advances state and the queue stops being recreated. Three read-only readings establish that.

First, the state transition. In the real KB5120708 sequence above, the final line is the entire proof: 2026-08-20 09:14:12 ID=2 Package KB5120708 was successfully changed to the Installed state. The matching poqexec.log entry is timestamped 2026-08-19 19:43:46.

Second, the absence of markers.

Third, the negative test most people forget: prove the queue is not being recreated. Install the next cumulative update, reboot once, re-read the Setup log. You want the five-event sequence ending in Installed state, with exactly one Event 4.

One closing observation from the lab data. Across 21 recorded queues, timings ranged from Registry: 4ms, Files: 20ms to Registry: 7081ms, Files: 20039ms, totals from 1.7 to 52.7 seconds. That spread is why this failure is so badly understood: on most devices, most months, the queue runs in under a minute and nobody learns it exists. You only meet it when it stops.

References

• DISM Operating System Package Servicing Command-Line Options - the /RevertPendingActions description and its "not supported on a running operating system" scope, plus the Limitations paragraph on blocked subsequent actions.
• Stop error 7B or Inaccessible_Boot_Device troubleshooting - the ordered recovery procedure: Get-packages, /RevertPendingActions, renaming pending.xml, PendingXmlIdentifier, PendingFileRenameOperations.
• Fix Windows Update corruptions and installation failures - "You can check the Setup event log for errors", the corruption error-code table used above, and the CBS.log paths.
• DismPackageFeatureState Enumeration - all eight documented package states with their verbatim descriptions.
• Servicing stack updates - the definition of the servicing stack and CBS, and what depends on it.
• Clean Up the WinSxS Folder - the verbatim warning about deleting files from WinSxS, where pending.xml and poqexec.log both live.
• Get-WindowsPackage (Dism) - the read-only cmdlet used in step 2.
• Windows Setup Log Files and Event Logs - %WINDIR%\Panther and Setup.etl, a different artefact from the Setup event channel.
• Windows Recovery Environment (Windows RE) - entry points, and the automatic trigger after two consecutive failed boots.
• Manage the Component Store - what WinSxS is, and why its contents are not safe to prune by hand.

Measurement note: every output above was captured read-only from one Windows 11 Enterprise device, build 26200.9168, on 23 August 2026. The poqexec.log, CBS.log and Setup extracts are unedited apart from a redacted MAC-derived GUID suffix. Inferences rather than documented facts are labelled as such in the text.