wuauclt /detectnow Does Nothing: Diagnosing Patching Through the Update Session Orchestrator

Somebody on the bridge call says the machine has not scanned for updates in three weeks. Somebody else opens an elevated prompt, types wuauclt /detectnow, gets no output at all, and says "right, I have kicked it, give it ten minutes". Ten minutes later nothing has changed, because nothing ever happened.

That command has done nothing on any supported build of Windows for years. It does not error. It does not warn. It returns to the prompt instantly and silently, which is exactly why the myth survives: silence looks like success.

The problem: the command returns instantly and nothing scans

The reason this particular piece of folklore is so durable is that the binary is still there. wuauclt.exe has not been deleted from Windows. It sits in System32 exactly where it has since Windows XP.

So when you type wuauclt /detectnow you do not get "command not found". You do not get a usage message. You get a clean, instant return - the shape of a command that worked.

Note the version string on that binary: 1509.2607.1012.0. That is not an OS build number, and it matters later.

Microsoft has said this out loud. An archived Microsoft blog post covering Windows 10 and Windows Server 2016 states it in one sentence: "Administrators trying to use wuauclt /detectnow will notice that it doesn't do anything."

So the immediate operational damage is not that a scan failed. It is that somebody recorded "scan triggered, no updates found" in a ticket, and the device stays unpatched behind a note that says it was checked.

Before touching a single command on a device that is allegedly not scanning, three questions need answers.

1. Which component is actually supposed to start a scan on a modern build, and is it running?
2. Where does that component log, given that it does not appear in Event Viewer under any obvious name?
3. When Event 26 says "successfully found N updates", which binary emitted that, and does it prove the orchestrator did its job?

Why it happens: USO owns the workflow, and System32 only holds the front door

Microsoft's own description of the Windows Update workflow is built around a component it calls the Orchestrator, and the phrasing is unambiguous about who is in charge.

The documented sequence has four phases, and the Orchestrator initiates every one of them: it "schedules the scan", it "starts downloads", it "starts the installation", and it "starts a restart". The Windows Update client and the arbiter do the work underneath.

That is the mental model to hold. The Windows Update agent is a worker with an API. The Update Session Orchestrator is the thing that decides when the worker runs and drives it through the phases in order. wuauclt.exe was a front end for the worker, from an era when the worker scheduled itself.

This is why the failure modes changed shape. Microsoft's own log documentation lists exactly when to reach for the orchestrator trace, and every entry is a phase-transition failure: "updates are available but download isn't getting triggered", "updates are downloaded but installation isn't triggered", "updates are installed but reboot isn't triggered".

Read those three lines again, because they are the single most useful diagnostic sentence Microsoft publishes about USO. A device stuck between phases is an orchestration problem. A device that errors inside a phase is an agent or servicing-stack problem. Those are different investigations.

The part that breaks detection scripts: System32 is mostly stubs now

Here is where a lot of home-grown health checks quietly go wrong. If you assume the USO binaries live in System32 like a normal Windows component, you will get some right and some very wrong.

On the lab device the USO files in System32 carry OS-line version numbers in the 10.0.26100.x range. The actual working implementation is somewhere else entirely, in C:\Windows\UUS\amd64, on a completely different version line.

The pattern is consistent once you see it. System32 holds the entry point that the OS ships and versions with the OS. C:\Windows\UUS\amd64 holds the implementation, and it is versioned on its own line because it is serviced on its own schedule.

You can see the same shape in the naming: UsoClient.exe in System32 against UsoClientImpl.dll in UUS, and usosvc.dll in System32 against usosvcimpl.dll in UUS. Stub in front, implementation behind.

Binary reference: what each file is and where it really is

How to verify: service, tasks, trace session, events - in that order

This is a read-only sequence. Every step below observes state without changing it, and the order matters: each step tells you whether the next one is even worth running.

Step 1. Confirm the orchestrator service is running and correctly configured. If UsoSvc is disabled or its ServiceDll has been tampered with by a "debloat" script, nothing downstream is worth checking.

Step 2. Read the scheduled tasks - and read the verbs off them. This is the highest-value step in the whole exercise, and almost nobody does it.

Windows ships the orchestrator's triggers as scheduled tasks under \Microsoft\Windows\UpdateOrchestrator\. Their actions are first-party: Microsoft wrote those command lines, so the verbs in them are not internet folklore.

Two things to take from that output. First, Schedule Scan being Ready with a populated next-run time is your evidence that scans are scheduled at all. A disabled or deleted Schedule Scan is a root cause, and it is a common casualty of update-blocking utilities.

Second, the Disabled state on the three "Work" tasks is not damage. On a WUfB-managed device that is the expected shape, and treating it as a fault sends you off repairing something that was never broken.

Step 3. Confirm the orchestrator's trace session is live. USO does not log where you expect, so verify the session exists before you go looking for files.

Step 4. Find the ETL files on disk. Microsoft documents these as UpdateSessionOrchestration.etl in C:\ProgramData\USOShared\Logs. On this 25H2 device they are one level deeper, and the file names carry a session GUID and sequence number.

Those are binary ETL files, not text. To read them, use Get-WindowsUpdateLog, which merges and converts the trace files into a single readable log. It produces a static snapshot - it does not keep updating, so re-run it each time you want current data.

Step 5. Now look at the event channel - and be precise about what it proves. There is no USO channel in Event Viewer. On the lab device, filtering every registered channel for a USO-related name returns only the Windows Update client channels.

Now the part that settles the question in the title. Ask Windows which binary registers that provider.

So Event 26 is emitted by the agent, and its serviceGuid tells you which update source was scanned. Microsoft publishes that mapping: 9482F4B4-... is Windows Update, 7971f918-... is Microsoft Update, 855E8A7C-... is the Store, 3DA21691-... is WSUS or Configuration Manager, and 8B24B027-... is OS Flighting.

The documentation attaches a warning to that table which is worth repeating: the ServiceId "identifies a client abstraction, not any specific service in the cloud", so do not infer a particular server from it.

Event 41 rewards the same scepticism. On the lab device the most recent one reads updateTitle = 9PKDZBMV1H3T-Microsoft.GetHelp. That is a Microsoft Store app, not a cumulative update. "An update was downloaded" had nothing to do with patching the OS.

Step 6. Decide which investigation you are in. With the above in hand the branch is clean. If UsoSvc is stopped or Schedule Scan is gone, you have an orchestration fault and the fix is the service or the task. If both are healthy and Event 26 is landing regularly, the orchestrator is doing its job and any complaint about missing patches is an approval, targeting or applicability question - not a client fault at all.

The fix: trigger a scan the way Windows itself does

Now, and only now, the command. The replacement for wuauclt /detectnow is documented by Microsoft in exactly one place I can find, in that same archived post: "In Windows 10, and Windows Server 2016 or newer, the command to scan Windows Update from the command line is: c:\windows\system32\UsoClient.exe startscan".

That is worth taking seriously precisely because it is corroborated on the device itself. StartScan is the argument in Microsoft's own Schedule Scan task. It is not an internet guess.

Everything else circulating about usoclient.exe deserves a much colder eye, because Microsoft's position on the tool is explicit. Asked directly for documentation in 2018, Microsoft's response was: "Usoclient.exe is an internal command line, so there is no official article or /? /help about it."

There is no /?. There is no reference page. The widely-copied verb lists trace back to community forum threads citing third-party blogs - and if you follow the citation chain in that same Microsoft thread, that is exactly where the extended list came from.

Documented, shipped, or folklore - the honest split

There is a further catch that the forum threads report and that the task definitions corroborate: these verbs were designed to be invoked by the OS, in specific contexts. The shipped tasks run as SYSTEM with a ServiceAccount logon and a Limited run level. Typing the same verb into an interactive elevated prompt is not the same call, and reports of verbs "doing nothing" outside a user session are consistent with that.

So if you need a scan trigger you can actually depend on across builds, prefer an interface Microsoft supports:

1. Run the shipped task itself rather than the raw binary - Start-ScheduledTask -TaskPath '\Microsoft\Windows\UpdateOrchestrator\' -TaskName 'Schedule Scan'. You get Microsoft's own invocation context, and the task's LastTaskResult gives you a return code to check.
2. Drive the Windows Update Agent COM API (or a wrapper module around it) when you need a scan result programmatically. It is a documented API surface with real error codes, and it emits Event 26 like any other caller.
3. Use your management plane - Windows Update for Business policy, or an Intune remediation - when the goal is fleet behaviour rather than one-off diagnosis.
4. Leave the UI as the tiebreaker. If Settings finds updates and your script does not, the fault is in your trigger, not the device.

And if the real finding was step 1 - UsoSvc disabled by a debloat script - then the fix is to restore the start type to 2 and the ServiceDll to usosvc.dll, not to reset the update stack.

Proof it worked: correlating a task run with Event 26

The verification that a scan actually happened does not come from the absence of an error message. It comes from two independent records agreeing on a timeline.

Read that top to bottom. The orchestrator's Schedule Scan task ran at 10:33:43 and returned 0. Roughly ninety seconds later the agent logged Event 26 having found one update. Then it scheduled its next run for 13:17, unprompted.

That is the whole model in one screen: USO schedules and initiates, the agent executes and reports. Neither record alone would have told you the device was healthy.

The six-week counts make the same point at fleet scale. 477 successful scans in about forty days is roughly a dozen a day, on a device where nobody clicked anything. That is not a user checking for updates - that is the orchestrator's randomised schedule doing its job, and it is the baseline you should expect on a healthy managed endpoint.

The 20 Event 25 failures against 477 successes is also the right way to read intermittent errors. A scan failure rate around four per cent on a corporate network, with successes either side, is transient - most likely network or proxy. It is not a broken client, and it is certainly not a reason to reset the update stack.

One honest caveat on that correlation, because it is the kind of thing that gets over-claimed. Event 26 records the process ID that emitted it, and that is a genuinely useful handle - Microsoft's own log documentation notes that "each component, such as the USO, Windows Update engine, COM API callers, and Windows Update installer handlers, has its own process ID". But those processes are long gone by the time you read the log, and PIDs get reused, so resolving one after the fact tells you nothing reliable.

Which is the real lesson. Event 26 proves the agent completed a scan. It does not prove USO asked for it - a script calling the COM API produces an identical event. If you need to know who initiated a scan, the task history and the orchestrator ETL are the records that answer it, and wuauclt /detectnow will never appear in either.

References

• How Windows Update works - the four-phase Scan / Download / Install / Commit model, with the Orchestrator named as the initiator of every phase, plus the documented ServiceId table used to decode Event 26's serviceGuid.
• Windows Update log files - documents UpdateSessionOrchestration.etl under C:\ProgramData\USOShared\Logs, the three phase-transition symptoms that mean "read the USO trace", and the note that USO, the engine and COM API callers each have their own process ID.
• Windows Update error code list by component - the authoritative WU_E_* list. Worth citing for what is absent: 0x80240438 is not on it, though the neighbouring 0x8024043D (WU_E_SERVICEPROP_NOTAVAIL) is.
• Get-WindowsUpdateLog - the supported way to merge and convert the ETL trace files into a readable log, and the reason the output is a static snapshot.
• wuauclt /detectnow in Windows 10 and Windows Server 2016 (archived) - the primary source for both halves of this article: that /detectnow "doesn't do anything", and that the replacement is UsoClient.exe startscan.
• USOCLIENT.EXE - Documentation? (archived) - Microsoft's verbatim position that "Usoclient.exe is an internal command line, so there is no official article or /? /help about it", and the thread where the community verb list originates, with its third-party citations visible.
• Servicing stack updates - why a device legitimately runs several independent version lines at once, which is the context for a 1509.2607.1012.0 update stack on a 10.0.26200.9168 build.

All device output in this article was captured read-only on 23 August 2026 from a single managed Windows 11 Enterprise 25H2 endpoint, build 26200.9168, with a 10.0.26100.9156 servicing stack. Console blocks are reformatted for width and have GUIDs and long paths truncated where marked; no command in this article modifies a device. Version numbers, file paths, task actions, registry values, ETW session details and event counts are all as measured on that machine and will differ on yours - verify before you build a check on them.