0x80246007: the update was never downloaded so the install cannot start

Fix it now

0x80246007 is WU_E_DM_NOTDOWNLOADED: the update has not been downloaded, so the installer has been pointed at a file that is not there. The update itself is fine and the machine is licensed and healthy. What is broken sits between the download queue and the disk.

Get-BitsTransfer -AllUsers | Select-Object DisplayName, JobState, BytesTransferred, BytesTotal
Get-BitsTransfer -AllUsers | Remove-BitsTransfer
net stop wuauserv
net stop bits
ren C:\Windows\SoftwareDistribution SoftwareDistribution.old
net start bits
net start wuauserv

1. Read the job list before you clear it. A job stuck in a transient error state, or one days old with a byte count that never moves, tells you which of the causes below you are in.
2. Check for updates and let the download start from scratch.
3. If one specific KB still fails, download it from the Microsoft Update Catalog and install it by hand. That proves whether the content is good and the transfer path is at fault.
4. Run Get-DeliveryOptimizationStatus during a download to see whether Delivery Optimization or the background transfer service is doing the work.

Do not rename the folder that holds the BITS queue. Microsoft does not document it as a supported repair; removing jobs with Remove-BitsTransfer and restarting the service is the documented route.

If the download completes and the update installs, you are finished. If it fails the same way, the next section separates a broken transfer from content that is being altered on the wire.

Why it happens

Windows Update splits fetching from installing. The agent decides what is needed, hands the content request to a transfer component, and only later calls the handler to install what arrived. Historically that transfer was always done by the Background Intelligent Transfer Service; on current builds Delivery Optimization does most of it and falls back to BITS in some configurations. Either way the same contract applies: the file has to be complete, and its digest has to match what the metadata said it would be.

0x80246007 is the install step discovering that the contract was not met. Its published wording is exactly that: the update hasn’t been downloaded. 0x80246002 is the more informative sibling, WU_E_DM_INCORRECTFILEHASH, meaning a download manager operation could not be completed because the file digest was not recognised. That distinction matters. A missing file points at a transfer that failed or was cleaned up. A digest mismatch points at something modifying content in flight, which in practice means a proxy, a caching appliance or TLS inspection.

0x80246008 is WU_E_DM_FAILTOCONNECTTOBITS: the download manager could not connect to the Background Intelligent Transfer Service. That is a service state problem on the machine rather than a network one, and it is answered by checking whether BITS is running and what stopped it. 0x8024000B is WU_E_CALL_CANCELLED, an operation cancelled by the user or the service, which Microsoft notes you can also receive when results cannot be filtered.

The two 0x8020xxxx codes are BITS reporting for itself, and both are routinely described wrongly. 0x80200010 is BG_E_NETWORK_DISCONNECTED: the network adapter is inactive or disconnected, and all jobs are placed in the transient error state. 0x80200013 is BG_E_INSUFFICIENT_RANGE_SUPPORT, whose published wording is that the server does not support the Content-Range header, and which Microsoft says you can also receive if an intermediate proxy is removing the Content-Range or Content-Length header. That second one is a concrete instruction to go and look at the proxy, not a hint that the link is flaky.

Full reference

The six codes and what each layer is saying

Useful commands for a stuck download

Which component is actually downloading

This matters because the two paths fail differently and you can waste an afternoon on the wrong one. Run Get-DeliveryOptimizationStatus during a download. If it shows an active job, Delivery Optimization owns the transfer, and BITS codes in the log are historical. If it shows nothing while Get-BitsTransfer -AllUsers shows a job, the background transfer service has it, and the 0x8020xxxx codes apply directly.

Proving the content rather than guessing

1. Take the KB number from Update history.
2. Download the standalone package for your exact edition, build and architecture from the Microsoft Update Catalog, on a connection you trust.
3. Install it by hand.
4. If it installs cleanly, the content is good and the transfer path is the fault. If it fails too, the problem is on the machine and you are in the wrong article.
5. If every month needs this treatment, fix the transfer path rather than repeating the manual install.

What not to do

Renaming or deleting the folder that holds the BITS job queue is a recipe passed around widely and not documented by Microsoft as a repair. It can lose jobs belonging to other software as well as Windows Update. Remove the jobs with Remove-BitsTransfer and restart the service instead; that is the documented route and it achieves the same end.

When downloads work but the install still fails

• Check free space on the system volume. Feature updates in particular need several gigabytes of headroom, and a transfer that completes onto a full disk fails at install.
• Confirm no backup, sync or endpoint protection agent is locking files under C:\Windows\SoftwareDistribution\Download, and exclude the folder from real-time scanning if the product allows it.
• Run chkdsk C: /scan on the system volume and read the result.
• Read Get-WindowsUpdateLog output for the exact file the installer expected, then check whether it is on disk.
• If the digest is failing rather than the file being absent, stop looking at the disk and start looking at what is between the machine and Microsoft.

Every code this article covers

Confirm the fix worked

1. Confirm the update installs and appears in Update history as successful.
2. Run Get-BitsTransfer -AllUsers and confirm no failed or orphaned jobs are left behind.
3. Confirm C:\Windows\SoftwareDistribution\Download is being populated during a fresh download rather than staying empty.
4. Run sc.exe query bits and confirm the service is running with a supported start type.
5. Install a second update to be sure you fixed the transfer path rather than one file.

Questions people ask about this