One read-only PowerShell collector for Windows patching failures - and the six traps that make naive versions lie to you

This is the last post in a forty-part series on Windows patching troubleshooting, and it exists because of something six of the earlier posts each discovered independently, without any of them setting out to.

Every single one of them was writing a small diagnostic snippet. Every single one of them found that the snippet lied.

Not crashed. Not errored. Lied — returned a clean, confident, plausible verdict that was flatly contradicted by the device it had just read. Six times, in six different subsystems, with six different registry keys. That is not six coincidences. That is a pattern, and it has a shape: on Windows, checking whether something exists is not the same as checking what it says, and the gap between those two questions is where triage scripts go to die.

Post 40 in this series covers the human side of that — which log to read for which symptom, and the five reflex fixes that destroy your evidence before you get to it. It names the pattern "the empty-key trap". This post owns the automation of it: why a patching triage script is far harder to write correctly than it looks, what each trap does to a naive implementation, and a single read-only collector that handles all of them.

Everything measured below came off one corporate Windows 11 Enterprise device — 25H2, build 26200.9168, servicing stack 10.0.26100.9156 — read only, on 23 August 2026. The script was written, saved, and then run from disk four times with different switches before a single number went into this post.

The problem: your triage script returns a confident answer that is wrong

Here is the scenario, and if you manage a fleet you have lived it. A batch of devices is not patching. You need a first pass across all of them, so you write forty lines of PowerShell: build, pending reboot, services, policy, last scan. You run it against the estate, get a tidy table back, and start working from it.

The table is wrong in at least three columns, and nothing in the output tells you which three.

This is worse than a script that crashes. A crash sends you to the device. A confident false negative sends you to the wrong theory, and you spend the afternoon there. On the lab device, a naive collector and a correct one were run against the same registry within the same minute and disagreed on the pending-reboot verdict, the management state, and the last-scan time.

The uncomfortable part is that the naive version is the version everybody writes, because it is the version that reads correctly in English. "Is a reboot pending? Test the RebootPending value." "Is this device managed by Windows Update for Business? Read IsWUfBConfigured." "Is legacy Automatic Updates policy in force? Test-Path the AU key." Each of those sentences is a perfectly sensible thing to say, and each of them maps to a line of PowerShell that returns the wrong answer on a real 25H2 device.

Read that block again and notice what is missing: an error. Not one of those four lines failed. Two returned nothing, one returned True, one returned 0. In PowerShell, "returned nothing" and "returned false" and "returned zero" all collapse into the same falsy value the moment you put them in an if, and that is where the wrong verdict gets born.

Why it happens: six places where existence is not evidence

The root cause is architectural, and once you see it you cannot unsee it. A Windows policy hive is not a database of settings. It is a namespace, and lots of different components create keys in it for lots of different reasons that have nothing to do with a policy being configured.

Group Policy creates keys when it applies a setting and, crucially, sometimes leaves them behind when it stops. The MDM policy stack creates a parallel set of keys somewhere else entirely. Certificate auto-update creates its own subkeys the first time it runs regardless of policy. The servicing stack uses subkeys as flags rather than values because a subkey can be created and deleted atomically in a transaction. And a value can exist while holding an empty string, which is a third state that neither Test-Path nor a truthiness test can see.

So "the key is there" tells you almost nothing. Here are the six instances confirmed on the lab device, each of which breaks a different naive check.

Trap 6 deserves its own paragraph because it is the nastiest of the six. Microsoft is explicit about the requirement, in the WMI Bridge Provider scripting article: "For all device settings, the WMI Bridge client must be executed under local system user." The documented way to satisfy that is psexec.exe -i -s cmd.exe. What is not documented is what happens when you ignore it. Measured behaviour: the query succeeds and returns the documented default for every property. You get plausible fiction with a clean exit code, which is the worst possible failure mode for a diagnostic.

That distinction is not academic. On the lab device the two hives are wildly asymmetric, and an audit that reads only the classic one concludes the device is barely managed at all.

The MDM hive. Every value below was read on 23 August 2026. Note that the raw value count is 65 while the real policy count is 23 — PolicyManager decorates each policy with _ProviderSet, _WinningProvider and _LastWrite siblings, so counting raw names roughly triples the apparent configuration.

And the agent's own resolved state key, which is the closest thing Windows has to "what did the update client actually conclude". Eighteen values, one of which cannot be trusted.

This is the update agent's resolved verdict after it has merged every policy source. It is the most useful key in the entire diagnostic — and it contains the single most misleading value.

One more class of trap, because it is the one that quietly corrupts compliance reporting rather than triage: the version APIs.

How to verify: reading each trap correctly, with the real output

Before writing the collector, each trap needs a read that is provably correct. That means, for every check, asking the same three questions: does the key exist, how many values and subkeys does it hold, and is the specific value I care about present, empty or absent. Three states, never one boolean.

Here is the pending-reboot check done properly, alongside the naive one, on the same key in the same second.

That TiRunning observation is worth sitting with for a second. The set of CBS subkeys is not a constant. It changed between two consecutive runs of the same read-only script, because the Windows Modules Installer service transitioned from Stopped to Running in between. Any heuristic of the form "this key has more subkeys than I expected, something must be pending" is measuring service state, not servicing state.

Next, the two policy hives, side by side. This is the check that changes how you read every Intune-managed device.

Then the bridge. This one is worth running deliberately, once, so you have seen it with your own eyes and never trust it again from the wrong context.

The event log is the other half of the evidence, and it needs the same discipline: counts are a measurement at a moment, not a device property. Between successive reads in this series the Event 26 count on this channel moved from 210 to 412 to 555 to 1,815. Quote what you measured and when.

Finally, the binaries, because half of the false corruption reports in this space come from someone looking for a file in the wrong directory and concluding it is missing.

The fix: one read-only collector, and every trap handled in code

The "fix" in this post changes nothing on the device. That is deliberate and it is the whole argument of the series: the correct first action on a patching failure is to collect, not to remediate. So the deliverable is a collector.

Follow this as a numbered path. Each step is a read, and each step is designed so that the answer cannot be a silent false negative.

1. Establish what the device really is. Read CurrentBuild and UBR from the registry and report them as one paired value. Print [Environment]::OSVersion.Version and Win32_OperatingSystem.Version beside them so the gap is visible rather than assumed. Flag ProductName and a BuildLabEx that disagrees with CurrentBuild. If you get this wrong nothing downstream is meaningful, because you are comparing the device against the wrong baseline.
2. Settle the pending-reboot question across every source. CBS markers via GetSubKeyNames(); the Windows Update client's Auto Update\RebootRequired key, which genuinely is a key so Test-Path is correct there; PendingFileRenameOperations as a specific value, counted; WinSxS\pending.xml as a file; and a computer-rename check comparing ActiveComputerName against ComputerName. Report each source separately with the method used. If a reboot is pending, stop — everything else queues behind it.
3. Check the services against an expected steady state, not against "Running". trustedinstaller and msiserver Stopped/Manual while idle is correct. A collector that flags them generates a false alarm on every healthy device in the fleet, which is how people learn to ignore the tool.
4. Read both policy hives and print them together. Classic hive with ValueCount and the named legacy AU values; MDM hive with the metadata siblings stripped out so the policy count is real. Compare the two counts and say so out loud when they diverge.
5. Read the agent's resolved state, and derive the management verdict from evidence. Print all eighteen PolicyState values including IsWUfBConfigured — then build the verdict from the deferral state and the policy values actually present, and say explicitly in the output that the flag was not used as a test.
6. Only query the MDM bridge deliberately, and only trust it as SYSTEM. The collector keeps this behind -IncludeMdmBridge, checks WindowsIdentity.IsSystem, compares every returned value against the registry, and labels the whole section untrusted when the context is wrong.
7. Compare the inventory against an honest denominator. Get-HotFix returned 4 rows. The CBS Packages subkey count on the same device is 7,490. Win32_QuickFixEngineering returns only Component Based Servicing updates, so the gap is expected — but it is why Get-HotFix is the wrong basis for a compliance report.
8. Prove the legacy last-scan check is dead before you rely on its absence. Test all three Auto Update\Results keys and report their non-existence as a finding, not as "never scanned". Use the event channel for scan evidence instead.
9. Read the restart-suppression surface, including the parts policy cannot see. Active hours live in ...\WindowsUpdate\UX\Settings, are user-chosen, and are invisible to a policy-key audit. Measured here: ActiveHoursStart=8, ActiveHoursEnd=0 — a 16-hour daily window in which automatic restarts are suppressed.
10. Emit findings with severities, and distinguish "clean" from "unknown". Anything the collector could not read goes into a separate gap list and forces exit code 2, because a section that failed to read must never render as a section that came back clean.

The mechanism that makes all of this possible is small: three helper functions that refuse to collapse three states into one boolean.

Two switches matter operationally. -Redact masks the machine name, every GUID in every emitted string, and the hardware serial, so the report can be attached to a public forum post or a vendor case — values are masked, never removed, because "field is populated but hidden" and "field is absent" are different pieces of evidence. -OutputHtml <path> writes a self-contained styled report: no external CSS, no web fonts, no scripts, no images, so it renders identically offline, from a USB stick, or behind a proxy that blocks outbound requests from a local HTML file.

Proof it worked: the run, the self-audit, and two bugs that parsed clean

The script was saved to disk and run four times: plain, with -VerifyReadOnly, with -IncludeMdmBridge, and with -Redact -OutputHtml. Here is the tail of the real run.

Ten findings on a device that every dashboard reports as healthy. None of them is a fault. All of them are things you would want to know before you started changing anything — and four of them are cases where a naive script would have produced a different, wrong answer.

The same run with -Redact added produced a 20,774-byte report against the plain run's 20,702. Both files were then checked mechanically: DOCTYPE present; every tag balanced, at 134 tr and 298 td elements each with matching closers; zero <script>, <img> and <link> elements; zero @import; zero url(); no unresolved template variables anywhere in the output; and exactly one outbound hyperlink in the whole document, the repository link in the footer. In the redacted copy the machine name, the hardware serial and all six enrollment GUIDs were confirmed absent by string search, and the same strings were confirmed present in the unredacted copy — so the switch is doing work rather than being decorative.

The first bug is a genuine PowerShell 5.1 quirk that I had not met before. Wrapping a System.Collections.Generic.List[object] in the array subexpression operator throws:

The second bug is funnier and more instructive. The read-only self-audit originally worked by reading its own source file line by line and searching for mutating command names. It reported three violations on its first real run:

That is the empty-key trap in a different costume: a check that answers "does this text appear somewhere in the file" when the question was "does this file execute this command". The fix is the same in kind as every other fix in this post — stop pattern-matching the surface, parse the structure. The audit now tokenises itself with the PowerShell parser, discards every Comment token, and searches only real code. That is the 8,517 code tokens in the output above, and it is why the result is now 0.

Forty posts. One recurring lesson, discovered independently six times: on Windows, the question "is this configured" almost never has a boolean answer, and a script that pretends it does will lie to you politely and at scale. Ask for the state. Print the counts. Name the method. And run the thing before you ship it.

References

• CheckForPendingReboot.ps1 — Microsoft's own published pending-reboot script. It opens Software\Microsoft\Windows\CurrentVersion\Component Based Servicing\ and calls GetSubKeyNames(), then tests the returned array for RebootPending. Archived, and still the clearest statement anywhere that the CBS markers are subkeys.
• Using PowerShell scripting with the WMI Bridge Provider — the source of the SYSTEM requirement: "For all device settings, the WMI Bridge client must be executed under local system user", with the documented psexec.exe -i -s cmd.exe route. It also explains the InPartition("local-system") class qualifier that marks a device-scoped class.
• MDM_Policy_Result01_Update02 class — the class the collector queries behind -IncludeMdmBridge, and its InPartition("local-system") declaration.
• Policy CSP - Update — the documented allowed values and defaults that let you recognise the silent-defaults fallback: AllowAutoUpdate default 2 (enumerating 0-5 only), DeferQualityUpdatesPeriodInDays range 0-30 default 0, ConfigureDeadlineForQualityUpdates range 0-30 default 7, ConfigureDeadlineGracePeriod range 0-7 default 2. Also the per-setting "Group policy mapping" registry key names, including the AllowAutoUpdate to AUOptions translation.
• Windows Update log files — the log inventory, the component tag list, and the note that C:\Windows\WindowsUpdate.log is a stub pointing at Get-WindowsUpdateLog rather than the real trace.
• Windows-Patching-Scripts — Get-WindowsPatchingEvidence.ps1, the read-only collector described in this post, with -OutputHtml, -Redact, -IncludeMdmBridge and -VerifyReadOnly.