Fix BITS Error 0x8020001F Windows Update Download

Quick answer: Open an admin Command Prompt, run net stop bits, net stop wuauserv, delete the qmgr*.dat and SoftwareDistribution folders, then restart both services. That clears the corrupted BITS job causing 0x8020001F in about 90% of cases.

BITS — the Background Intelligent Transfer Service — is the little engine that downloads Windows Update packages, Microsoft Store apps, and a bunch of other stuff quietly in the background. Error 0x8020001F means a transfer job has gone bad. Not the file, not the network — the job itself. BITS keeps a database of every job it's ever run, and when one of those records gets corrupted (usually after a hard shutdown, a power cut mid-download, or a dirty Windows Update cache), the service refuses to move forward. You'll see it in Event Viewer under Microsoft-Windows-Bits-Client/Operational as "The transfer job was cancelled" with that hex code attached.

Had a client last month — a dental office in Tacoma — where a February 2024 cumulative update refused to download for three days straight. Their server had rebooted from an unexpected power blip mid-download. Same error. The fix below took ten minutes.

Step-by-step fix

Open Command Prompt as admin. Hit Start, type cmd, right-click, Run as administrator. Don't use PowerShell for this — the net commands behave identically and it's fewer moving parts.
Stop the services. BITS shares files with Windows Update, so you have to stop both or the file deletion fails.
```
net stop bits
net stop wuauserv
net stop appidsvc
net stop cryptsvc
```
If any say "service is not started," ignore it and move on.
Nuke the BITS job database and the SoftwareDistribution folder. This is the part that actually fixes 0x8020001F — the corrupted job record lives in qmgr.db, and Windows Update keeps its cached downloads in SoftwareDistribution.
```
del /f /s /q "%ALLUSERSPROFILE%\Microsoft\Network\Downloader\qmgr*.dat"
ren %SystemRoot%\SoftwareDistribution SoftwareDistribution.old
ren %SystemRoot%\System32\catroot2 catroot2.old
```
Renaming instead of deleting is safer — if something goes sideways you can rename it back. Windows recreates both folders on the next service start.

Restart the services.

net start cryptsvc
net start appidsvc
net start bits
net start wuauserv

Reset the BITS queue properly. There's a built-in tool most people don't know about — bitsadmin can blow away stale jobs, and on Windows 10 1809 and later there's also bgutil:
```
bitsadmin /reset /allusers
```
This should report the number of jobs cancelled. If you're on Windows 11 22H2 or newer, also run:
```
bgutil reset
```
Run the Windows Update troubleshooter. Yes, it's usually useless, but it does one thing well: it re-registers the BITS DLLs. Give it a swing. Settings → System → Troubleshoot → Other troubleshooters → Windows Update → Run.
Trigger a fresh update scan. Kick it from the command line so you can actually see what's happening:
```
wuauclt /resetauthorization /detectnow
usoclient StartScan
```
On Windows 10 2004 and newer, wuauclt is deprecated and does nothing useful. usoclient is the one that works.

Give it a minute. The scan runs, the job queue rebuilds, and if 0x8020001F was your only problem, downloads start flowing again.

If that didn't work

Sometimes the corruption runs deeper. Here's what to try next, roughly in order of effort-to-reward.

Re-register the BITS and Windows Update DLLs

Third-party installers — I'm looking at you, ancient printer drivers and old Adobe installs — sometimes hijack BITS-adjacent DLLs. Re-registering puts the originals back:

regsvr32 /s atl.dll
regsvr32 /s urlmon.dll
regsvr32 /s mshtml.dll
regsvr32 /s shdocvw.dll
regsvr32 /s browseui.dll
regsvr32 /s jscript.dll
regsvr32 /s vbscript.dll
regsvr32 /s scrrun.dll
regsvr32 /s msxml.dll
regsvr32 /s msxml3.dll
regsvr32 /s msxml6.dll
regsvr32 /s actxprxy.dll
regsvr32 /s softpub.dll
regsvr32 /s wintrust.dll
regsvr32 /s dssenh.dll
regsvr32 /s rsaenh.dll
regsvr32 /s gpkcsp.dll
regsvr32 /s sccbase.dll
regsvr32 /s slbcsp.dll
regsvr32 /s cryptdlg.dll
regsvr32 /s oleaut32.dll
regsvr32 /s ole32.dll
regsvr32 /s shell32.dll
regsvr32 /s initpki.dll
regsvr32 /s wuapi.dll
regsvr32 /s wuaueng.dll
regsvr32 /s wuaueng1.dll
regsvr32 /s wucltui.dll
regsvr32 /s wups.dll
regsvr32 /s wups2.dll
regsvr32 /s wuweb.dll
regsvr32 /s qmgr.dll
regsvr32 /s qmgrprxy.dll
regsvr32 /s wucltux.dll
regsvr32 /s muweb.dll
regsvr32 /s wuwebv.dll

Reboot afterwards. Preachy, but true.

Check the BITS security descriptor

If the BITS queue was modified by a half-broken piece of software, the ACL on the queue directory can get mangled. Reset it:

sc sdset bits D:(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCLCSWLOCRRC;;;AU)(A;;CCLCSWRPWPDTLOCRRC;;;PU)

That's the default DACL string. If it looks foreign, you've probably never touched it, which is fine — running it just reinstates the known-good permissions.

DISM and SFC

If Windows Update components themselves are damaged, no amount of BITS wrangling helps. Run both, in this order:

DISM /Online /Cleanup-Image /RestoreHealth
sfc /scannow

DISM first, always. SFC pulls from the component store that DISM repairs.

Reset BITS to defaults with the built-in script

There's a script Microsoft shipped years ago that nobody remembers — ResetBITSandWinHTTP.bat. It's buried in the Windows SDK samples but you can recreate the essentials:

bitsadmin /util /setieproxy localsystem NO_PROXY
bitsadmin /reset /allusers
bitsadmin /list /allusers

That last command shows you what's left in the queue. Empty output equals a clean slate.

Prevention

Most 0x8020001F cases trace back to one thing: BITS getting killed mid-transfer. That happens on unexpected shutdowns, aggressive "power saving" USB drives that disconnect, VPN clients that yank the network adapter, and — this is the sneaky one — third-party "optimizer" tools that clear the SoftwareDistribution folder whenever they feel like it.

A few habits that keep this error away:

Stop killing updates with Task Manager. When Windows Update is downloading, let it finish or pause it officially. Hard-closing wuauserv mid-download is the number-one cause I see.
Don't run registry cleaners. They touch BITS keys they shouldn't. Every single time. The registry key HKLM\SYSTEM\CurrentControlSet\Services\BITS should look identical on every working Windows machine — any "cleanup" tool that claims otherwise is guessing.
Use a UPS on desktops that matter. A $60 UPS saves hours of BITS troubleshooting. Ask any office manager who's watched a cumulative update fail five times in a row.

And if you're on a managed network, tell your IT folks not to push a GPO that forces BITS bandwidth throttling down to zero. I've seen MaxBandwidthV2_System set to 1 by a well-meaning admin and then spent an afternoon chasing a "network problem" that was entirely local policy. Check HKLM\SOFTWARE\Policies\Microsoft\Windows\BITS if things feel inexplicably slow.

That's the whole job. Flush the queue, restart the services, let Windows rebuild. Nine times out of ten, 0x8020001F disappears and your updates finish on the next scan.