The update stuck at 0% is a BITS job, not Windows Update: read the transfer queue first

A user reports that Windows Update has been sitting at 0% for two days. You open Settings, see the same 0%, and reach for the reflex: stop wuauserv, stop bits, rename SoftwareDistribution, start everything, retry. Sometimes it works. You never find out why.

The reason you never find out is that the reflex deletes the only record of what went wrong. On a modern Windows client the progress bar you are staring at is not owned by Windows Update at all. It is a summary of work being done by two other services with their own queues, their own state machines, and their own logs — and one of those queues will tell you the answer in about four seconds if you read it before you break it.

This article is about reading it. Not fixing anything yet. Reading it.

The problem: 0% is a number nobody has verified

Take the symptom apart. "Stuck at 0%" bundles four separate claims, and every one of them can be false.

1. That a download job exists. It might never have been created.
2. That the job is not progressing. Nobody sampled it twice.
3. That the job belongs to Windows Update. It might belong to the Configuration Manager client, Chrome's updater, or OneDrive.
4. That the failure is a fault. A job that has been in transient error for three days is behaving exactly as Microsoft documents it should.

Here is what the queue actually looked like on the Windows 11 25H2 corporate device I used to write this article. Nobody had reported a problem on it. This is a device somebody would describe as fine.

Real output, captured read-only from a live Windows 11 Enterprise 25H2 device (build 26200.9168) during research for this article. Job GUIDs are the device's own.

Read the second job again. It is 99.99% complete and permanently failed. If a user had been watching a progress bar fed by that job, they would have reported it as "stuck at 100%" — and every troubleshooting article on the internet would have sent them looking for a servicing-stack problem that does not exist.

Neither of these is Windows Update. CCM is the Configuration Manager client, and these are upload jobs — state messages going back to a management point. That matters enormously, because the reflex fix for a stuck Windows Update download is to flush the whole BITS queue. Doing that here would have silently discarded a client's pending inventory data, and the ConfigMgr symptom ("this device stopped reporting") would have surfaced days later with no connection to the update ticket that caused it.

Why it happens: three queues, two services, one progress bar

Who actually downloads a Windows update

Three components share the work behind that progress bar, and they are genuinely separate.

The Update Session Orchestrator (UsoSvc) decides that a scan or a download should happen and drives the session. It does not move bytes.

Delivery Optimization (DoSvc) is what Microsoft describes as "a reliable HTTP downloader with a cloud-managed solution", and its documented content list includes Windows Update feature and quality updates, drivers, Store apps, Defender definitions, Intune Win32 apps, Microsoft 365 apps and Edge updates. On a Windows client it is on by default in LAN peering mode.

BITS (qmgr.dll, hosted in svchost.exe -k netsvcs) is the general-purpose background transfer queue. Plenty of things still use it — the ConfigMgr client, browser updaters, OneDrive's config fetches — and it is also Delivery Optimization's documented fallback path.

The cleanest proof of that split is in Microsoft's own Delivery Optimization reference, in the note deprecating Download Mode 100: "When you configure Bypass (100), the download bypasses Delivery Optimization and uses BITS instead." You only need a setting to make a download use BITS if it was not using BITS to begin with.

The BITS state machine, which is the actual diagnosis

Microsoft groups the nine documented BITS job states into four classes: starting, action, transferred and final. Every state tells you something specific, and two of them are routinely confused with each other.

Why a job in transient error retries silently for days

This is the single most useful piece of BITS arithmetic, and it explains almost every "stuck for a week" ticket.

The minimum retry delay defaults to 600 seconds — 10 minutes. That is how long BITS waits after a transient error before trying again. The floor is 5 seconds; anything lower is silently raised to 5.

The no-progress timeout defaults to 1,209,600 seconds — 14 days. That is how long BITS keeps retrying, from the first transient error, before it moves the job to ERROR. Any actual progress resets the timer.

And the JobInactivityTimeout Group Policy defaults to 90 days, after which BITS considers a pending job abandoned, deletes it, and deletes its downloaded files from disk.

Read that timeline against a helpdesk ticket. A user who says "it's been stuck for a couple of days" is describing a job that is, by Microsoft's own defaults, still inside its normal retry window. Nothing has failed. Something is blocking it, and the blocker has been sitting there quietly for 48 hours while BITS politely tried 288 times.

Microsoft also documents when BITS gives up immediately instead: it does not retry if a network disconnect or a disk lock error occurred (chkdsk running, for example), or if the MaxInternetBandwidth Group Policy is set to zero. A bandwidth limit of zero is documented to place all background jobs in transient error with BG_E_BLOCKED_BY_POLICY.

Priority, and how one dead job starves the rest

BITS has four documented priorities. FOREGROUND (value 0) competes for bandwidth with everything else on the machine and "can impede the user's network experience". HIGH, NORMAL and LOW are all background priorities that "use idle network bandwidth of the client"; NORMAL is the default.

The scheduling remark is the part worth memorising: "Lower-priority jobs don't receive transfer time until all higher-priority jobs are transferred, or are in an error state." Jobs at the same priority share time slices round-robin so a large job cannot block a small one, and all foreground jobs run concurrently with one background job. But a high-priority job stuck in an action state — queued, connecting, transferring at zero throughput — holds the line ahead of everything beneath it until it finally errors out. So the job you are chasing may be perfectly healthy and simply last in a queue behind something else, which is why you enumerate the whole queue rather than one job.

The binaries, and one path worth double-checking

All values below were read from the lab device, not from memory.

One caution, because this class of mistake is easy to make. Microsoft's reference pages for the BITS COM methods list the implementing DLL as QmgrPrxy.dll. On this build there is no qmgrprxy.dll in System32 at all — a filtered listing for qmgr* returns exactly one file, qmgr.dll, and the proxy that is present is named BitsProxy.dll. If your detection script tests for a binary's existence, test the path on the build you are targeting rather than trusting a reference page's requirements table.

How to verify: the read-only order that preserves the evidence

Every step below is read-only. Nothing here restarts a service, resumes a job or deletes a file. Work through them in order and stop at the first one that answers the question.

Step 1 — Confirm which services are even running

Note the version scheme: 7.8.x, not 10.0.x. BITS carries its own component version independent of the OS build, which is why "is BITS up to date" is not a question the OS build number answers.

Step 2 — Enumerate the queue, elevated

Run the Get-BitsTransfer -AllUsers command from the first console block. The -AllUsers switch is documented to require administrative credentials, and without it the cmdlet returns only the calling user's jobs. Almost every job that matters for patching is owned by NT AUTHORITY\SYSTEM, so an unelevated run is guaranteed to under-report. If the parameter fails, you are not elevated — that is the error, not an empty queue.

Step 3 — Is it progressing? Sample twice

Nobody can tell a slow transfer from a dead one with a single reading. Take two, sixty seconds apart, and subtract.

Step 4 — Read the error, while it still exists

For a job in Error, pipe it to Format-List * and capture the whole object to a file before you touch anything. The fields you want are the job state, the error description and the file-level detail. Remember the constraint from earlier: this information is documented as available only while the job is in the error state.

The BITS-specific codes are worth knowing on sight, because several of them point straight at a corporate network rather than at Windows.

Step 5 — Read BITS' own log channel

BITS has a real Event Viewer channel, and Microsoft's own error documentation points you at it by name: the description for BG_E_VALIDATION_FAILED says to "use Event Viewer to view the Application Logs\Microsoft\Windows\Bits-client\Operational log". On the lab device that channel was enabled with 1,238 records sitting in it, entirely unread. Its sibling Analytic channel was disabled, which is the default.

The distribution itself is diagnostic. Across the most recent 400 records the counts were: 60 appearing 71 times, 4 appearing 71 times, 3 appearing 70 times, 16403 appearing 70 times, 59 appearing 70 times, 209 appearing 34 times, 306 and 310 five times each, and 61 just four times. Seventy starts, seventy-one stops, seventy creations and seventy-one completions — a queue doing its job — against four warnings. Those four are the whole signal.

That decomposition trick is worth keeping. Any BITS status code beginning 0x8007 is a wrapped Win32 error and its low sixteen bits are the real code; codes beginning 0x8020 are BITS' own; codes beginning 0x8019 are wrapped HTTP status codes (0x80190197 is 407, 0x80190194 is 404).

Step 6 — Check whether policy is throttling or blocking the transfer

This is where the lab device produced the best trap in the whole article.

Step 7 — If BITS is clean, look at Delivery Optimization

Delivery Optimization keeps its own queue with its own vocabulary, and it does not appear in Get-BitsTransfer at all. The DeliveryOptimization PowerShell module is the way in.

Compare the runtime numbers with the policy that produced them. On this device the MDM policy under the PolicyManager key sets DOMaxBackgroundDownloadBandwidth to 1000, and Microsoft documents that setting's unit as kilobytes per second. Get-DOConfig reports DownBackLimitBps as 1024000 — exactly 1000 × 1024 bytes — and attributes it to MdmProvider. That agreement is your proof the policy is genuinely in force, which is precisely the check the BITS key failed.

One honest gap, deliberately left as a gap: I am not going to give you the on-disk path of the Delivery Optimization cache. Microsoft's reference documents the default location only as the operating system drive "through the %SYSTEMDRIVE% environment variable", redirectable with DOModifyCacheDrive to a drive letter or folder. It does not publish the folder. Third-party write-ups disagree with each other about it. If you need the cache gone, use the supported cmdlet Delete-DeliveryOptimizationCache rather than deleting a directory you found on a forum.

Step 8 — Separate active hours from bandwidth policy

This conflation costs real hours. Microsoft's definition is unambiguous: "Active hours identify the period of time when you expect the device to be in use. Automatic restarts after an update occur outside of the active hours." Default 8 AM to 5 PM, configured through SetActiveHours, ActiveHoursStart and ActiveHoursEnd under the WindowsUpdate policy key. Active hours governs restarts. It does not throttle, delay or block a transfer, and nothing in its documentation touches bandwidth.

The settings that genuinely throttle by time of day are the BITS MaxBandwidthValidFrom/ValidTo window and Delivery Optimization's DOSetHoursToLimitBackgroundDownloadBandwidth. On the lab device all three concepts point at roughly the same working day — BITS at 9-17 (disabled), Delivery Optimization at 8-17 (active, 25%), and active hours unconfigured by policy so the local 8 AM-5 PM default applies to restarts only. Three separate mechanisms, one shared-looking window, and only one of them was actually limiting bytes.

The fix: what to do once you know which state the job is in

Now, and only now, act. The action is determined entirely by the state you found.

1. SUSPENDED, and it is not new. Something created a job and never resumed it. Resume-BitsTransfer will start it, but the real fix is on the calling application's side — a job that BITS suspended at creation and nobody resumed is a caller bug. Note that resuming a job with no files returns BG_E_EMPTY (0x80200003) and leaves it suspended.
2. QUEUED for a long time. Look at what sits above it. A higher-priority job stuck in an action state holds the queue until it errors. Fix or clear the blocker, not the victim.
3. TRANSIENT_ERROR. Do not just resume it — you will get the same failure ten minutes later. Work the documented blockers first: is the connection metered or "too expensive", is the device in battery saver or game mode, is there actual internet connectivity, is a bandwidth policy set to zero, is an inspecting proxy stripping Content-Range. Resuming before you clear the blocker resets nothing except your own clock.
4. ERROR. Capture the error object to a file, then choose deliberately between two documented behaviours. Complete-BitsTransfer keeps fully downloaded files and discards incomplete ones. Remove-BitsTransfer cancels — and Microsoft documents that cancelling deletes all completely and partially transferred files. On a 3 GB feature update on a branch-office link, that distinction is an afternoon.
5. TRANSFERRED. The transfer already succeeded. Files are not released to the caller until Complete is called, so this is an application problem and restarting BITS will not help.
6. BITS queue empty, Delivery Optimization Caching or Downloading. Your download is fine and being throttled or delayed. Check the DO bandwidth policy and the HTTP-fallback delay before touching anything.
7. BITS queue empty, Delivery Optimization empty, no events. Nothing was ever asked for. The problem is upstream in the scan or the orchestrator, not in a transfer queue at all — and now you know that instead of guessing.

Only after all of that does a service restart earn its place, and it is a narrower tool than it looks. Restarting BITS re-reads the persisted job list from disk — that is what event 306 records — so it does not clear the queue and will not resurrect a job whose no-progress timeout has expired. It is the right move for a wedged service, and it is precisely the wrong move for a policy problem, a proxy problem, or a caller bug, all three of which it hides.

The same logic condemns the SoftwareDistribution rename. That folder is Windows Update's download and datastore area. Renaming it does not touch the BITS queue, does not touch the Delivery Optimization cache, and does not change a single one of the policy values above — but it does throw away the update history and datastore that let you correlate a failed transfer with the update that wanted it. It is a step you take when you have a reason, not a step you take instead of finding one.

Proof it worked: the events a healthy transfer actually emits

Do not accept a progress bar as proof. A recovered transfer leaves a specific, checkable trail, and every item below is verifiable read-only.

The queue moves. Re-run the two-sample delta from step 3. A healthy job shows a rising BytesTransferred and a state of Transferring. That is one command and it is not ambiguous.

The channel logs a start and a clean stop. You want event 59 ("BITS started the ... transfer job that is associated with the ... URL"), then event 60 with status code 0x0 at Information level, then event 4 ("The transfer job is complete"). Match them by Job ID. What you do not want is another event 61 at Warning level with a non-zero status — the presence or absence of 61 for your Job ID is the cleanest pass/fail signal in the whole system.

The lab device's own numbers show what a working queue looks like at rest: 70 event-59 starts, 71 event-60 stops, 70 event-3 job creations and 71 event-4 completions across the sampled window, against four event-61 warnings. Successes outnumbering warnings by roughly eighteen to one is the shape of health. A device where 61 is climbing and 4 is flat is a device with a transfer problem, and you can measure that from a single command without touching anything.

Delivery Optimization advances too. Get-DeliveryOptimizationStatus shows TotalBytesDownloaded rising against FileSize, and where peering is working it reports a real figure in PercentPeerCaching — on the lab device, 33.68 percent for a 2.79 GB Microsoft 365 payload, meaning a third of that file came from the local network rather than the internet. That number is the only honest way to answer "is our peer caching actually doing anything", and it is worth capturing on a handful of devices before anybody redesigns a Delivery Optimization policy.

And the negative check. The job you diagnosed should now be absent from Get-BitsTransfer -AllUsers, because a job that reached ACKNOWLEDGED or CANCELLED is documented not to appear in a job enumeration. Absence here is success — but only because you already saw the event 4 that explains it. Absence without that event is the same ambiguity you started with, which is the whole reason this article reads the log and the queue together rather than either one alone.

References

• BG_JOB_STATE enumeration (bits.h) - the nine documented job states, including the exact wording that separates a nonrecoverable ERROR from a recoverable TRANSIENT_ERROR, and the note that BITS does not retry after a network disconnect, a disk lock error, or a MaxInternetBandwidth policy of zero.
• Life Cycle of a BITS Job - the four state classes, the documented transient-error causes (expensive network, battery saver, game mode, no connectivity), the difference between Cancel and Complete for partially transferred files, and the statement that jobs in a final state do not appear in a job enumeration.
• Get-BitsTransfer (BitsTransfer module) - the syntax, and the documented requirement that -AllUsers needs administrative credentials.
• IBackgroundCopyJob::SetNoProgressTimeout - the 1,209,600-second (14-day) default retry period and the transition to BG_JOB_STATE_ERROR when no progress is made.
• IBackgroundCopyJob::SetMinimumRetryDelay - the 600-second default retry delay and the 5-second floor.
• BG_JOB_PRIORITY enumeration - foreground transfers competing with the user versus background transfers using idle bandwidth, NORMAL as the default, and the scheduling rule that lower-priority jobs wait until higher-priority jobs transfer or enter an error state.
• BITS Return Values - the BG_E_* catalogue with hex codes, the note that BITS wraps Windows errors with HRESULT_FROM_WIN32, and the pointer to the Bits-client\Operational log.
• BITS Group Policies - the policy key location, the 90-day JobInactivityTimeout, and the documented behaviour of a bandwidth limit of zero (BG_E_BLOCKED_BY_POLICY, then release to the queued state).
• Policy CSP - BITS - the BITS_MaxBandwidth ADMX mapping, the registry key Software\Policies\Microsoft\Windows\BITS, the Kbps units, and the documented defaults of 8, 17 and 1000.
• What is Delivery Optimization? - Delivery Optimization as "a reliable HTTP downloader", and the content-type table showing Windows Update quality and feature updates, drivers, Store apps, Intune Win32 apps and Microsoft 365 apps flowing through it.
• Delivery Optimization reference - the download modes, the KB/s units for DOMaxBackgroundDownloadBandwidth, the precedence of the business-hours settings over the flat percentages, the Bypass (100) note about using BITS instead, and the %SYSTEMDRIVE% statement that is as specific as Microsoft gets about the cache location.
• Manage device restarts after updates - the definition of active hours as a restart window, the 8 AM to 5 PM default, and the SetActiveHours / ActiveHoursStart / ActiveHoursEnd registry values.
• WinINet error messages - ERROR_INTERNET_CANNOT_CONNECT as 12029, "The attempt to connect to the server failed", which is the payload inside the real 0x80072EFD observed on the lab device.
• bitsadmin list - the /allusers and /verbose parameters, and the same administrator requirement as the PowerShell equivalent.