The Windows patching triage decision tree: which log, which key, which tool - and the five reflex fixes that destroy your evidence

Every post in this series so far has pulled one thread. This one is the map. It exists because of a pattern that shows up in almost every escalated patching ticket I have ever picked up second: by the time the ticket reaches someone who knows how to read the logs, the logs are gone.

Not corrupted. Not rotated. Deleted — deliberately, by a competent engineer, in the first ninety seconds, as part of a fix. Somebody reset SoftwareDistribution. Somebody end-tasked TiWorker. Somebody ran Disk Cleanup to free space for the retry. Each of those actions is a documented, supported operation. Each of them also destroys the specific artefact that would have told you why the update failed, and in three of the five cases it destroys something Microsoft's own troubleshooting guidance later tells you to go read.

So this closer does two things. First, a routing table: for each common symptom, the one place to look first, and why the obvious place is the wrong one. Second, an explicit catalogue of the five reflexes that burn the evidence, with the documented cost of each. Every device number here came off one corporate Windows 11 Enterprise machine, 25H2, build 26200.9168, servicing stack 10.0.26100.9156, read only, on 22 and 23 August 2026.

The problem: the first command you run decides whether root cause survives

There is a deep asymmetry in patching troubleshooting that almost nobody states out loud. Reading evidence is cheap, fast, and reversible. Destroying evidence is also cheap and fast — and completely irreversible.

A Get-BitsTransfer, a netsh winhttp show proxy, a Get-WindowsPackage, a findstr over CBS.log: seconds each, zero risk, and they leave the failure exactly as it was so you can look again after your first theory turns out to be wrong. A rd /s /q %systemroot%\SoftwareDistribution takes about the same time and there is no undo. The download cache, the datastore, the WUA session history and the update-agent's local ID mapping are simply gone, and if the update fails again for the same underlying reason, you get to diagnose it from scratch with less information than you started with.

That asymmetry means the order of operations matters more than the fix. And the order most teams use is inverted, because the reflex fixes are the ones that are easy to remember, easy to script, and easy to justify in a ticket note.

Here is what a proper first pass looks like on a real device. Every line below is read-only, and the values are real, from the lab machine on 23 August 2026. This is the snapshot to take before you form a theory, because it is the one that tells you which of the seven subsystems you are even in.

Four commands. Nothing changed, nothing restarted, nothing cleared. And already you know the installed release, whether the servicing stack is mid-transaction, whether the system-level proxy is even in play, and which services are alive. That is enough to pick a branch. The rest of this post is the branch table.

Why it happens: one label, seven subsystems, seven evidence stores

The reason a single symptom routes to seven different places is that "Windows Update" is a label for a pipeline, not a component. Each stage in that pipeline is a separate service, writing to a separate store, using separate binaries, and failing with a separate error family.

The user-visible symptom tells you very little about which stage broke, because the Settings UI collapses all seven into one progress bar. "Stuck at 0%" and "install failed with 0x800f0831" look like the same class of problem in the UI. They are not even in the same subsystem, do not share a log, and have no fix in common.

Worse, the binaries are not where most people assume. This matters because it determines where you attach a debugger, what you check version-wise, and whether a "servicing stack" claim in a log is about the OS build or something versioned independently.

The measured facts above are the reason the routing table works. Here they are as a reference, because when a log says "TiWorker" and you go looking in C:\Windows\servicing, you conclude the file is missing and start chasing a corruption theory that does not exist.

How to verify: the routing table, the decision path, and the empty-key trap

(A) The symptom-to-evidence routing table

This is the core of the post. One row per symptom, and in every case the "first place to look" is deliberately not the place the symptom's name points at.

(B) The decision path, as numbered steps

Follow these in order. Each step is read-only and each one either lands you on a branch or eliminates one.

Step 1 — establish what is installed. DisplayVersion, CurrentBuild and UBR from HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion. Never ProductName (it says "Windows 10 Enterprise" on this Windows 11 device) and never ReleaseId (frozen at 2009). If build and UBR already meet your baseline, the problem is the report, not the device — go to Step 8.

Step 2 — is the servicing stack mid-transaction? Test for C:\Windows\WinSxS\pending.xml. If it exists, stop. You are in the boot-time commit branch and nothing else you find matters until that transaction is resolved. This is also the point at which the temptation to rename the file appears; do not, and see reflex 2.

Step 3 — which stage reported the failure? Read Microsoft-Windows-WindowsUpdateClient/Operational for scan/download events and the Setup log for staging/install events. The channel identifies the subsystem before the error code does.

Step 4 — decode the error family, not the error. 0x8024xxxx is the update agent (scan, protocol, download manager, datastore). 0x800fxxxx is CBS. 0x8007xxxx is a Win32 error surfaced by whichever layer hit it. 0xC1900xxx is Windows Setup. That single character routes you faster than any error-code lookup.

Step 5 — open the one log the family points to. CBS family goes to CBS.log; setup family goes to setuperr.log; scan family goes to the decoded WU trace; download goes to the BITS queue. Resist opening all four.

Step 6 — if it is a scan failure, test the plumbing in the right order. System clock, then netsh winhttp show proxy, then name resolution of the configured update source, then policy. Not Internet Options.

Step 7 — if it is a CBS failure, read the summary block, not the error count. The counts that matter are CSI Payload Corruption and Total Detected Corruption, not how many lines contain the word Error. See the amber gotcha below for why.

Step 8 — if everything on the device is healthy, the defect is in reporting or policy. Compare build+UBR and the package inventory against the baseline, then check the pin, the deferrals and the PolicyManager hive. Fix the query, not the device.

Two more measurements from the same device make the point beyond CBS.log, because "an error count is not a verdict" generalises further than most people expect. First, C:\Windows\System32\catroot2\dberr.txt held 47 error lines against 38 success lines — on a machine where every August 2026 update installed correctly. The errors were shutdown-race noise: 0x426 (ERROR_SERVICE_NOT_ACTIVE) sixteen times and 0x45b (ERROR_SHUTDOWN_IN_PROGRESS) fourteen times. More errors than successes, and nothing wrong.

Second, and more surprising: 14 of the 73 certificates in the machine's root store were already expired, including Microsoft Code Signing PCA 2011, which expired on 8 July 2026. Updates install fine anyway, and the reason is documented rather than lucky. Microsoft's Authenticode time-stamping guidance states that "Time stamping allows Authenticode signatures to be verifiable even after the certificates used for signature have expired", because the countersignature lets a verifier establish that the signature was valid at the time it was affixed. An expired-certificate alarm from a scanner is therefore not a patching finding, and chasing it wastes the hour you needed for the actual failure.

One more routing shortcut, and it is a strange one: the decoder's silence tells you which subsystem raised the code. Measured on this device, certutil -error cleanly resolves the 0x800B (trust), 0x8009 (crypto), plain Win32 and WinHTTP facilities — and for anything in 0x8024xxxx, the Windows Update facility, it simply echoes the number back at you. So if certutil -error gives you a name, you are in a trust, crypto or transport problem. If it hands the number back unchanged, you are in the update agent and you need the decoded WU trace instead. It also returns nothing useful for the 0x800f08xx CBS family, which is why the CBS row above sends you to the log rather than to a decoder.

(C) The empty-key trap: one bug class, four measured instances

This deserves promoting to a named pattern, because it is the strongest through-line in the whole series and it has now been measured four separate times on the same device. The pattern is this: on Windows policy and servicing hives, the existence of a key carries almost no information. Keys get created by the OS whether or not anybody configured anything, and the thing you actually care about is a value inside — or, in one case, a subkey rather than a value.

These checks do not fail loudly. They return a confident boolean, the boolean is wrong, and nothing in the output hints at it. All four below are measured read-only on the lab device.

Four instances, four different hives, one bug. Worth grepping your own remediation library for tonight: a Get-ItemProperty reboot check will happily report "no reboot pending" across a fleet of machines that all need one, and a Test-Path-only policy check will report configuration that does not exist. The rule that covers all four: test for the value you care about, and if you must report on a key, report ValueCount and SubKeyCount alongside the boolean so the next person can see what you actually found.

Two of the four are worth seeing in raw form, because the output is so unremarkable that it is easy to read past.

Note what the second half of that block buys you. The same three commands that expose the empty AU key also hand you the pin state — and the pin on this device says 24H2 while the device runs 25H2. A Test-Path-only check would have sent you looking for a WSUS server that does not exist, and you would have walked straight past the overtaken pin sitting two lines below.

The policy keys themselves are worth tabulating, because the "already up to date" branch lives here and it is the branch most often misdiagnosed as a client fault.

The event log is the other routing surface, and it is faster than any registry read because the channel itself names the subsystem.

The fix: five evidence-destroying reflexes and what each one costs

Every one of these five is a real, documented, sometimes necessary operation. The problem is never the operation. The problem is running it before the evidence has been read, when the operation itself is what deletes the evidence.

Reflex 1 — resetting or renaming SoftwareDistribution

Worth knowing why the reset ever works, because it explains when it is the right call rather than a coin flip. Microsoft's mitigation for 0x80240022 (WU_E_ALL_UPDATES_FAILED) says: "The most common issue is that antivirus software is blocking access to certain folders (like SoftwareDistribution). CBS.log analysis has to determine the file or folder that's being protected." Note the second sentence. The reset treats a symptom whose cause is identified in a log — the log you are about to make harder to read. This is covered in more depth in the SoftwareDistribution post in this series.

Reflex 2 — deleting or renaming pending.xml out of sequence

Reflex 3 — end-tasking TiWorker.exe

Reflex 4 — /StartComponentCleanup /ResetBase

Reflex 5 — Disk Cleanup "clean up system files", and deleting Windows.old

Read those five together and a pattern falls out. In four of the five, the thing destroyed is named in a Microsoft troubleshooting article as the thing you are supposed to go and read: Datastore.edb for Local IDs, CBS.log for the blocked-folder analysis, the superseded packages for uninstalling a bad update, the setup logs and SetupDiag.exe for upgrade failures. The reflexes are not fighting best practice in the abstract. They are deleting the specific inputs to the documented procedure.

Proof it worked: the evidence pack, and proving it rather than assuming it

The last thing a triage decision tree needs is a definition of done, because "the update installed" is not the same claim as "we understand why it was failing" and only one of those prevents a repeat next month.

Capture these on both sides of any change. All read-only, all cheap.

1. Build and UBR together, from HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion. Both, always. The UBR trap is real: KB5121003 is 26200.9168 on 25H2 and 26100.9168 on 24H2, so a UBR-only comparison silently passes the wrong release.
2. The package inventory, not Get-HotFix. Counts by PackageState, so you can see Staged entries waiting on a reboot rather than assuming they installed.
3. The three pending-reboot markers, tested correctly — CBS RebootPending and PackagesPending by subkey enumeration, WindowsUpdate\Auto Update\RebootRequired, and PendingFileRenameOperations under Session Manager. Record the boolean and how you tested it.
4. The CBS summary block, not the error count. Total Detected Corruption, CSI Payload Corruption, Total Repaired Corruption, and the Operation result.
5. The policy triple — the GPO key, the AU subkey's value count, and the PolicyManager hive — so you can prove the device was in scope.
6. The relevant events with timestamps, from the channel that matches the subsystem you diagnosed.

Then prove the linkage rather than asserting it, which is the single most useful habit in this whole series. Two logs describing the same event will agree to the second, and when they do you have a fact rather than a theory. Two real correlations from the lab device:

And one closing note on what "proof" means for the things you did not find. A clean result is only meaningful if the check that produced it could have failed. That is the whole reason the empty-key trap matters, in all four of its measured forms: a Get-ItemProperty reboot check returns False on every device in existence, so its False tells you nothing at all, and a Test-Path on the AU, Servicing or AuthRoot keys returns True on a device where none of them is configured. Before you record any negative finding, satisfy yourself that the test had the ability to come back positive. That single habit would have prevented more wasted escalations than every command in this post combined.

That is the series. One device, a great many logs, and one recurring lesson underneath all of it: the servicing stack is unusually good at telling you what went wrong, in writing, with timestamps — right up until the moment somebody helps.

References

• Windows Update log files — the log inventory table, the component tag list, the log structure, and the statement that Local IDs are resolved from %WINDIR%\SoftwareDistribution\Datastore\Datastore.edb.
• Additional resources for Windows Update — the documented SoftwareDistribution reset, the manual component reset, and the explicit gate on the DataStore/Download/catroot2 rename step.
• Common Windows Update errors — the ResolveSource() unsuccessful string for 0x800f081f, the , error CBS.log search technique, the WinHTTP/WinINET note on 0x8024401B, the BITSADMIN /LIST mitigation, and the 0x80070bc9 escalation ladder ending in the pending.xml rename.
• Fix Windows Update corruptions and installation failures — the corruption error-code table (0x80073712 = ERROR_SXS_COMPONENT_STORE_CORRUPT, 0x800B0101 = CERT_E_EXPIRED against the system clock), the list of resources DISM checks, and the annotated CBS summary block.
• How the Windows Update client determines which proxy server to use — WinHTTP for scan, BITS/DO for download, the Local System account, and the documented system-proxy-then-user-proxy fallback order.
• Stop error 7B or Inaccessible_Boot_Device troubleshooting — the ordered WinRE procedure: /RevertPendingActions first, the pending.xml rename second, the offline COMPONENT hive and PendingXmlIdentifier deletion at step 6, and PendingFileRenameOperations at step 11.
• Why you don't want to edit your pending.xml to resolve 0xC0000034 issues — the checkpoint value, why clearing it marks the whole queue critical, and "Doing this should be an absolute last resort."
• SetupDiag — extraction to $Windows.~bt\Sources, the move into Windows.old, the statement that deleting Windows.old removes SetupDiag.exe, the setupmem.dmp locations, the recursive /LogsPath behaviour, and "the last failure in the log file is typically the fatal error".
• Log files and resolving upgrade errors — the per-phase log location table, setuperr.log as the error-only companion to setupact.log, the log-entry structure, and the instruction to find the last occurrence of the result code and cross-match timestamps between logs.
• Clean Up the WinSxS Folder — the StartComponentCleanup task and its 30-day grace period and 1-hour timeout, and the /ResetBase warning that "All existing update packages can't be uninstalled after this command is completed".
• Windows Update error code list by component — the symbolic names behind the routing table, including 0x8024402C WU_E_PT_WINHTTP_NAME_NOT_RESOLVED and 0x8024401C WU_E_PT_HTTP_STATUS_REQUEST_TIMEOUT.
• Troubleshoot Update ring policies for Windows devices — the HKLM\SOFTWARE\Microsoft\PolicyManager\current\device\Update path for Intune-delivered settings, the ...\Policies\Microsoft\Windows\WindowsUpdate keys to check alongside it, and the conflicting-TargetReleaseVersion caveat.
• Policy CSP - Update — the TargetReleaseVersion definition and its Software\Policies\Microsoft\Windows\WindowsUpdate registry mapping, plus the documented deferral ranges (up to 365 days for feature updates, up to 30 for quality).
• Manage the Component Store — what the store is for, including "Uninstalling problematic updates", and the hard-link explanation behind the "Shared with Windows" figure.
• CheckForPendingReboot.ps1 — Microsoft's own published pending-reboot script. It opens the Component Based Servicing key, calls GetSubKeyNames(), and tests whether the result -contains "RebootPending". That is the authoritative answer to the subkey-versus-value question.
• Time Stamping Authenticode Signatures — why an expired signing certificate does not invalidate an already-signed binary, and therefore why expired root-store certificates are not a patching finding.

All device values in this post were read from a single corporate Windows 11 Enterprise 25H2 device, build 26200.9168, servicing stack 10.0.26100.9156, on 22 and 23 August 2026. Every command shown is read-only; none of the five reflexes described here was executed, which is why there are no after-numbers for them. Findings labelled measured came from that device rather than from documentation — validate against your own pilot ring before applying any of this to a fleet.