Windows Update Error 0x80248007: What It Means and How to Fix It

Windows Update stops at "Download error - 0x80248007", and pressing Retry changes nothing. The code looks vague, but Microsoft's own error table says exactly where things broke: Windows Update went looking in its local database and the record wasn't there. This guide explains what 0x80248007 means, the cache reset that clears it, and what to check when it comes back.

What 0x80248007 Means

Every Windows Update code has a name behind it. Microsoft's Windows Update error reference lists 0x80248007 as WU_E_DS_NODATA: "The information requested isn't in the data store."

The data store is Windows Update's local database. It caches what the machine knows about updates: which ones exist, which apply, and which are already installed. It lives in C:\Windows\SoftwareDistribution\DataStore\DataStore.edb, and Microsoft's Windows Update log guide describes the DataStore component as "caching update data locally."

So the error isn't about your internet connection or Microsoft's servers. Windows asked its own cache for a record, and the cache came back empty or out of step. That's why the usual fix is the least exciting one: make Windows throw the cache away and rebuild it.

You'll see the code in two flavors. "Download error - 0x80248007" appears in Settings while an update is fetching. "Install error - 0x80248007" appears after the download finished. Same database, different moment. Its neighbors in the same table point at the same place: 0x80248014 means the update service isn't in the data store, and 0x80248006 means the data store version doesn't match what Windows expects.

Start With the Quick Checks

Before you touch any folders, rule out the cheap causes. Restart the machine first. Microsoft's error table has a separate code for an install blocked by a pending restart, and a half-finished update from last week can trip the next one.

Next, check the Windows Installer service. The fixes shared in Microsoft Q&A for this error restart it alongside the update services. In an elevated Command Prompt:

code
sc query msiserver
net start msiserver

Then run the built-in troubleshooter. On Windows 11, Microsoft's Windows Update troubleshooting page points to the Windows Update troubleshooter in the Get Help app, or Settings > System > Troubleshoot > Other troubleshooters. It resets the same components you're about to reset by hand, so it's worth the two minutes.

Last, look at anything that sits between Windows and its files. In a long-running Microsoft Q&A thread on 0x80248007, users reported that pausing third-party antivirus or switching off a VPN let the update through. Neither is a fix. Both tell you where to look next.

Reset the Windows Update Cache

This is the fix. You stop the services that hold the cache open, rename the folders so Windows builds fresh ones, and start the services again. Renaming beats deleting, because you can put the old folders back if something odd happens.

Microsoft's steps to reset Windows Update components rename three folders: SoftwareDistribution\DataStore (the database), SoftwareDistribution\Download (downloaded payloads) and System32\catroot2 (signature catalogs). Run this in an elevated Command Prompt:

code
net stop bits
net stop wuauserv
net stop cryptsvc
net stop msiserver
ren %systemroot%\SoftwareDistribution\DataStore DataStore.bak
ren %systemroot%\SoftwareDistribution\Download Download.bak
ren %systemroot%\System32\catroot2 catroot2.bak
net start bits
net start wuauserv
net start cryptsvc
net start msiserver

If a ren fails with "access denied", a service is still running. Run the net stop line again and retry. Then open Settings > Windows Update and check for updates. The first scan takes longer than usual because the database is being rebuilt from scratch.

Microsoft's page also includes a step that resets the security descriptors on the BITS and Windows Update services with sc.exe sdset. Skip it unless everything else fails. Microsoft warns it overwrites the existing permissions on both services.

The same reset in PowerShell, handy if you're already in a remote session:

code
$svc = 'bits','wuauserv','cryptsvc','msiserver'
Stop-Service $svc -Force
Rename-Item "$env:SystemRoot\SoftwareDistribution\DataStore" DataStore.bak
Rename-Item "$env:SystemRoot\SoftwareDistribution\Download" Download.bak
Rename-Item "$env:SystemRoot\System32\catroot2" catroot2.bak
Start-Service $svc

Run it twice on the same machine and the second rename fails, because DataStore.bak already exists. Delete or rename the old .bak folders first. If PowerShell is new to you, our list of PowerShell commands for technicians covers the service and file cmdlets used here.

This short walkthrough shows the Windows Installer restart and the SoftwareDistribution reset on a live machine:

BITS is the service that downloads the payloads, which is why it shows up in threads about this code. This r/WindowsHelp post pairs the download-stage error with BITS:

When the Reset Doesn't Stick

If the error comes back after a clean reset, the problem is deeper than the cache. The label on the error tells you which way to go.

An "Install error" points at the servicing stack, the part of Windows that applies updates. Repair the component store with DISM, then run SFC. Our guide to DISM RestoreHealth walks through the order, the source switch and what to do when DISM can't find its files.

When one update keeps failing and the rest install fine, stop fighting Windows Update for that one package. Download it from the Microsoft Update Catalog and install the .msu by hand. A Microsoft support engineer suggested exactly this in the Q&A thread, and it gets you an error message you can read if it fails again.

If the stuck update is a driver, get the driver from the device maker instead. Our guide on updating drivers safely covers where to get them and how to roll back.

Then read the logs. Windows Update writes trace files, not a text log. Run Get-WindowsUpdateLog in PowerShell and it merges them into a readable WindowsUpdate.log on your desktop. Microsoft notes it's a static copy, so run it again after each attempt. Search it for DataStore and the error code. For install failures, C:\Windows\Logs\CBS\CBS.log is where the servicing stack records what it tried.

On servers the same code turns up with fewer easy answers. In this r/sysadmin thread, an admin hit 0x80248007 on a Server 2022 domain controller after resetting services, recreating SoftwareDistribution and catroot2, and running DISM and SFC:

The replies go where you'd expect: read the failure in CBS.log, check what the endpoint protection is doing, and try the Catalog package followed by a restart of the Windows Update service. One admin says it hits their Server 2016 machines every few months. When a server keeps failing after all of that, an in-place repair install is usually faster than another week of retries.

Fixing It Across a Fleet

One machine with 0x80248007 is a cache problem. Ten machines with it on the same morning is something they share. Check the update source first. If the devices point at a WSUS server, the WUServer value under HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate tells you which one, and a WSUS problem won't be fixed by clearing client caches. Our guide to Windows Update policy covers where those settings come from.

To see which machines are failing and with what, pull the Windows Update client's failure events instead of asking users for screenshots:

code
Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Microsoft-Windows-WindowsUpdateClient'; Id=20} -MaxEvents 5 |
  Select-Object TimeCreated, Message

Event 20 is the installation failure record, and its message carries the update name and the error code. Run it across the affected devices, group by code, and you'll know whether you have one problem or three. OpenFrame can run a script like this across a client's devices and collect each device's output in one place.

Once you know which machines need the reset, script it rather than remoting in one by one. The PowerShell block above works over any remote session. Add a check that the .bak folders don't already exist, and schedule a scan afterwards so the result shows up in the next report.

The Short Version

0x80248007 means Windows Update asked its own database for something that wasn't there. Restart, start the Windows Installer service, then reset the cache by renaming DataStore, Download and catroot2. If it returns, the label tells you where to go: install errors need DISM and SFC, and a single stubborn package needs the Catalog. For the component store side of the fix, read our DISM RestoreHealth guide next.