WindowsUpdate.log is 276 bytes of pointer text: reading the real ETW traces with Get-WindowsUpdateLog

Somebody reports that updates have stopped. You remote in, open C:\Windows\WindowsUpdate.log, and the entire file is four lines long.

Not truncated. Not empty. Four lines, 276 bytes, telling you to run a PowerShell command.

At this point a lot of admins conclude logging is broken, or that something wiped the log. Neither is true. That file has been a signpost rather than a log since Windows 8.1, and the real evidence sits in ninety-nine binary trace files in a subdirectory nobody opens.

This post is about getting at that evidence, and reading it, before you touch a service.

The problem: WindowsUpdate.log is 276 bytes of pointer text

The file still exists. That is what makes the trap effective.

If C:\Windows\WindowsUpdate.log had been deleted outright, everyone would have learned the new method in a week. Instead Microsoft left a stub, so the muscle memory still works, the file still opens, and the result looks like a broken log rather than a redirect.

Here is that file on the Windows 11 device I used. Read-only, nothing changed.

Note the LastWriteTime: 10:27 that same morning. Something rewrote the stub hours earlier. That timestamp is the best clue on the device, and I will come back to what it means.

The damage is not the wasted five minutes. It is what people do next. Finding no log, the reflex is the standard reset: stop wuauserv and bits, delete C:\Windows\SoftwareDistribution, restart, retry.

Sometimes that clears the symptom. It also guarantees you never learn the cause, which matters on a fleet, because that cause is about to hit two hundred more devices.

Why it happens: the agent writes ETW, and the agent is not where you think

What ETW actually is

Event Tracing for Windows is a kernel-level tracing facility. A component registers as a provider with a GUID and emits events into a buffer; a session subscribes to providers and drains those buffers to disk as .etl files.

The part that matters for troubleshooting is what the provider writes. To keep tracing cheap enough to leave on permanently, providers do not write your readable sentence. They write a numeric event ID plus raw arguments, and the human-readable format string lives outside the trace, in the binary's metadata or symbols.

That is the whole reason a decode step exists. The .etl file is not encrypted or corrupt, it is shorthand. Opening one in Notepad gives you mojibake because the sentence you want was never in there.

Three sessions, not one

Windows Update does not have a single log. Three separate ETW sessions run on an idle, healthy Windows 11 device, covering different stages of the same operation. Decode only the first and you miss entire classes of failure.

Microsoft's guidance on which to read is unusually direct: go to the orchestrator logs when "updates are available but download isn't getting triggered", when "updates are downloaded but installation isn't triggered", and when "updates are installed but reboot isn't triggered".

A clean split. Agent log for "the update never arrived". Orchestrator log for "it arrived and then nothing happened".

The binaries behind the agent

Every component tag in the decoded log maps to a real file. Knowing which file, and where it lives, is what lets you check a version or spot a tampered install. These versions come from the device I used, read with Get-Item.

Look at the version column, because it holds the most useful thing in this table. The orchestrator files carry 10.0.26100.x, a normal Windows build number. The agent files carry 1509.2607.1012.0, which is not a Windows build number at all. And MoUsoCoreWorker.exe sits under C:\Windows\UUS beside a uusp.json and per-architecture folders, not in System32 with everything else.

The practical consequence: the update agent is serviced on its own track with its own version lineage, independent of the OS build. This device reports OS build 10.0.26200.9168 and an agent at 1509.2607.1012.0. Comparing an agent version against an OS build tells you nothing.

How to verify: prove the trace is running before you decode it

Do not start by decoding. Start by establishing that there is anything worth decoding, because "the log is empty" and "the trace was never running" need different fixes. Follow these in order; each step either clears the device or hands you the root cause.

Step 1. Confirm the ETW sessions are alive. One command settles the "logging is broken" question outright.

Step 2. Read the session configuration. Almost nobody does this, and it answers the two questions that decide whether your evidence still exists: where is it, and how long does it survive?

Three readings matter here.

Buffers Lost is your data-integrity check. Zero means the trace kept up. Non-zero means events were dropped under load, so a gap in the decoded log at the interesting moment may be an artefact rather than a clue.

The Output Location filename solves the timestamp puzzle from earlier. It reads WindowsUpdate.20260823.102701.286.1.etl, and the stub file's LastWriteTime was 10:27:01 that same day. Same moment: the session rolled to a new segment and rewrote the stub, exactly what you expect after a reboot or service restart. A stub timestamp far in the past is a real red flag; one matching the live segment is a healthy device.

Segment Max Size is the one with a deadline attached. Traces roll. If a user reports a failure from three weeks ago, the trace covering it may be gone, and no fix recovers it.

Step 3. Inventory the ETLs and check freshness.

That last distinction is the payoff for doing steps 1 to 3 at all. An old newest-ETL is not a logging problem, it is the symptom: the agent is not being invoked, so look at the orchestrator next.

Where the agent keeps its state

The decoded log constantly refers to service IDs, SLS decisions and reporting state. Those live under one parent key.

The fix: Get-WindowsUpdateLog, run properly

Now decode. Microsoft's description is worth reading literally: the cmdlet "merges and converts Windows Update .etl files into a single readable WindowsUpdate.log file".

Two verbs. It merges the directory of segments into one chronological stream, and it converts shorthand events into sentences. The output is a new file, not a view onto the old ones.

The symbol server history, and why it stopped mattering

If you inherited a runbook saying this decode needs internet access to Microsoft's symbol server, that runbook is at least eight years old, but it was not wrong when written.

Microsoft documents the boundary precisely. For Windows 10 versions before 1709 (build 16299), the cmdlet required access to a Microsoft symbol server and decoding had to be done from a pre-1709 build. From 1709 onward no symbol server is needed, and logs must be decoded on 1709 or higher. The SymbolServer parameter survives in the older documentation, explicitly marked deprecated for 1709 and above.

That is why the old runbook produced garbage logs full of unresolved placeholders on locked-down networks: the decode was silently failing to fetch format strings. On anything modern that data ships with the OS and the failure mode is gone.

Reading the result: the format and the tags

Microsoft documents the decoded log as four identities: timestamp, process and thread ID, component name, and update identifiers. In practice you read the component column and ignore most of the file. Here is the documented list, condensed to the tags that carry weight in a real investigation.

Proof it worked: one scan, three independent records

The test of a decode is not that a file appeared. It is whether you can take one event and find it in three places written by three different mechanisms. If they agree, your evidence is sound.

I ran the cmdlet against the real trace directory without -ForceFlush, so no service was touched.

The schema warning appeared on every batch, on a device with no update fault, and the cmdlet reported success each time. Treat it as noise unless the output file is missing.

Now the correlation. Here are the last lines of the decoded log, landing at 10:43:24 on 2026-08-23.

Earlier in the same file, an Agent-tagged line shows the same kind of operation from the agent's side rather than the API's, carrying the applicability arithmetic:

Twelve updates found, 702 applicability rules evaluated out of 894 deployed entities. When an update you expect is never offered, that ratio and the nearby EEHandler lines are where the answer is.

Now the third record. The same scans are reported independently to the event log, by the event channel below.

These are the real counts from that channel on the same device, over the retained window.

That table is the argument for this whole exercise. The event log tells you that something happened, with a timestamp. The decoded log tells you which update, caller, endpoint and error. Neither suffices alone, and the event log is the one that survives a SoftwareDistribution reset.

So the three records for the 10:43 scan agree: the live ETL segment WindowsUpdate.20260823.102701.286.1.etl was receiving events, the decoded log's final entry reads Updates found = 0 at 10:43:24, and Event 26 reads "successfully found 0 updates". Three mechanisms, one story. That is a trustworthy decode.

One last real detail, because it settles the version question from earlier. The agent stamps its own version into the device attributes it sends on every scan:

On 10 August this device reported WuClientVer=1508.2606.17012.0. By 23 August the on-disk agent was 1509.2607.1012.0 - a full generation, while the OS build barely moved. If a scan fails on some devices and not others, WuClientVer beats the OS build as a comparison across the fleet, and it is only visible here.

References

• Get-WindowsUpdateLog - the cmdlet reference: full syntax, every parameter, the -ForceFlush service-stop warning, and the 1709 symbol-server boundary.
• Get-WindowsUpdateLog (Windows Server 2016 view) - the older parameter set, still documenting -SymbolServer and its deprecation. Useful when auditing an inherited runbook.
• Windows Update log files - the log location table, the ETW-since-8.1 statement, the component tag list, the four-part log structure, the static-snapshot note, and the identifier schemes including Datastore.edb.
• Windows Update issues troubleshooting - worked decoded-log excerpts with Agent, Misc, ProtocolTalker and DownloadManager tags, plus the HTTP RANGE proxy requirement behind many DownloadManager errors.
• Wuapi.h header - the Windows Update Agent API that wuapi.dll implements, including IUpdateSession, IUpdateSearcher and ISearchResult. This is the boundary the ComApi tag marks.

Everything measured here came from one Windows 11 Enterprise device, build 26200.9168, read-only except the decode itself.