0x80070002 and 0x8007000D: the same two Win32 codes mean five different things

Two codes dominate Windows Update support threads: 0x80070002 and 0x8007000D. Search either and you get the same shotgun blast — reset SoftwareDistribution, run SFC, run DISM, re-register some DLLs, check the clock, blame the antivirus.

That advice is scattershot for a structural reason. Neither code is a Windows Update error code. Both are generic Win32 codes wrapped in an HRESULT, and at least five unrelated subsystems along the update pipeline can raise them.

So the useful question is never "how do I fix 0x80070002". It is "which component raised it". Get that wrong and you will spend an afternoon repairing a subsystem that was working perfectly.

The problem: codes that Microsoft's own component list does not contain

Start with a negative result, because it is the strongest evidence available.

Microsoft publishes Windows Update error code list by component — the canonical Windows Update Agent reference, broken out by the subsystem that raised each error: Data Store, Download Manager, Update Handler, Protocol Talker, Reporter, Expression Evaluator. Every entry is a WU_E_ or WU_S_ symbol with a component attached.

Neither 0x80070002 nor 0x8007000D appears anywhere on it.

That absence is not an oversight. Those tables list codes the agent defines. Our two are OS-wide Win32 codes that the agent merely relays upward when a lower-level call fails. The agent does not know what went wrong either.

Where both codes do appear together is the "Common corruption errors" table on Microsoft's Fix Windows Update errors page — a servicing-stack document. That pairing is itself a clue about where these codes most often originate, and it is a much better starting point than the WUA component tables.

Decode them and the picture sharpens. Both are plain HRESULT_FROM_WIN32 wrappers, and the arithmetic needs no tooling.

Those message strings are verbatim from Microsoft's System Error Codes (0-499) reference, the documented surface of WinError.h. They are the whole of what the code guarantees.

So 0x80070002 means a file lookup failed — which file, looked up by whom, unknown. And 0x8007000D means some bytes failed a validity check — which bytes, checked by which parser, unknown.

Every popular fix for these codes is a bet on one specific answer to those questions. The fixes are not wrong. They are answers to a question nobody established was being asked.

Why it happens: facility 7 names the failure, never the culprit

An HRESULT is a packed 32-bit value. Microsoft's [MS-ERREF] specification lays out the fields as severity, reserved bits, facility, and code, and describes the eleven-bit facility as "an indicator of the source of the error."

Facility 7 is FACILITY_WIN32, and the spec describes that region precisely: "This region is reserved to map undecorated error codes into HRESULTs." Undecorated is the operative word. Facility 7 is the bucket for errors that arrived with no provenance.

The mapping is a documented one-liner. Microsoft's HRESULT_FROM_WIN32 page masks the input with 0x0000FFFF, ORs in FACILITY_WIN32 << 16, and ORs in 0x80000000 for severity. It preserves what failed and discards who failed. That is the entire problem.

The five places the failing call is actually made

An update scans, downloads, stages, then installs. Different code owns each leg. Each leg opens files and parses data, so each can emit exactly these two codes for reasons with nothing in common.

Five sites, two codes — and the reflex fix addresses one of them.

The binaries that raise these codes

Knowing which file owns which leg turns a log line into a location. Paths and versions below were read from a live Windows 11 25H2 device, build 26200.9168 — that build's values, not universal constants.

One correction worth publishing, because it recurs in DLL lists: usocore.dll is widely cited as the Update Session Orchestrator binary. A recursive search of C:\Windows on this 26200.9168 device returned no such file, and it appears in no Microsoft documentation page. The orchestrator's registered service DLL is usosvc.dll. Verify a path before you build a script around it.

How to verify: localise the raise site before you touch anything

One question: which of the five raised it. Everything below is read-only.

Step 1 — record which of the two codes you have

It matters more than it looks. 0x80070002 is a lookup failure and biases toward sites 1, 3 and 5. 0x8007000D is a validation failure and biases toward sites 1 and 4. Both codes on one device usually means two faults, not one.

Step 2 — produce a readable WindowsUpdate.log

Since Windows 8.1 the client has used Event Tracing for Windows. Microsoft states it plainly: "Windows Update no longer directly produces a WindowsUpdate.log file. Instead, it produces .etl files that aren't immediately readable as written." The traces sit in C:\Windows\Logs\WindowsUpdate and you merge them yourself.

The component tag is the entire diagnostic. Everyone reads the error code and stops, but the code was never the informative part of the line.

Step 3 — if the tag pointed at servicing, go to CBS.log

Microsoft describes CBS.log as the log that "provides insight on the update installation part in the servicing stack", and confirms the Windows Modules Installer service writes to it. It is the authority for sites 3 and 4, and it separates them cleanly.

If neither pattern appears anywhere near the failure timestamp, the servicing stack was never involved and sites 3 and 4 are eliminated. A genuinely useful negative result, and it costs two minutes.

Step 4 — the differential table

This is the table to keep. Left column is "I saw the code in this context"; right column is which subsystem is actually failing.

Step 5 — if site 5 is in play, read the policy before blaming the client

Site 5 failures are configuration, not corruption, and Microsoft documents the configuration in one key. State the parent once:

Step 6 — corroborate against the event log

Events tell you how far down the pipeline the update actually travelled, which narrows the site independently of any log parsing. Channel:

Used for elimination rather than confirmation, these are fast. A 26, then a 41, then a Setup 2, and then 0x80070002, leaves exactly one place to look.

Step 7 — check service state, and do not panic at the obvious

That baseline was captured read-only from a live corporate 25H2 device and every state in it is correct. Engineers reliably see trustedinstaller stopped, conclude the servicing stack is broken, and set it to Automatic — which fixes nothing and slightly degrades boot.

The fix: five branches, five different repairs

Only now, with a site identified, is a fix a decision rather than a guess.

Site 1, agent datastore. This is the branch the reset was designed for, and here it is correct. Microsoft's own manual procedure stops bits, wuauserv and cryptsvc, then renames SoftwareDistribution\DataStore, SoftwareDistribution\Download and System32\catroot2 to *.BAK. Note that it renames. Renaming preserves the old datastore for post-mortem at zero cost, and the blunter documented alternative — rd /s /q %systemroot%\SoftwareDistribution — does not.

Site 2, BITS. If the Parameters key is missing, restore it so ServiceDll points at %SystemRoot%\System32\qmgr.dll and start the service. Clearing SoftwareDistribution will not help, because nothing was ever downloaded. If instead you are seeing real BG_E_ codes, the fault is in the transfer path — proxy range-request support, inspection appliances, disk — and re-downloading into unchanged conditions simply reproduces it. Microsoft's mitigation for 0x8007000D is "try to redownload"; that is right for a one-off corruption and useless for a systematic one. Two identical failures on the same payload means stop retrying and go look at the path.

Site 3, CBS payload resolution. SoftwareDistribution is irrelevant — the payload arrived intact. The missing file is in the package or the component store, so this is a component-store repair against a known-good source: DISM /Online /Cleanup-Image /ScanHealth to assess, then /RestoreHealth, with an explicit /Source when the device is WSUS-managed and cannot reach Windows Update for replacement files. Check %WINDIR%\Logs\Dism\dism.log afterwards, not just the exit code.

Site 4, CBS manifest integrity. Also a component-store repair, but with a materially lower success rate — the thing that would supply a replacement manifest is the servicing stack that cannot read manifests. Expect to need an explicit source, and expect an in-place upgrade to be the honest answer more often than for site 3.

Site 5, scan and metadata. No file on the device needs touching. Fix WUServer, fix the proxy, fix the inspection rule that mangles cabinet downloads. Resetting SoftwareDistribution here produces the most demoralising outcome in the matrix: the reset appears to work, the first scan re-fetches metadata through the same broken path, the same code returns, and you conclude the device is beyond repair.

Why the SoftwareDistribution reset has such a reputation

It genuinely fixes site 1, and it genuinely papers over a transient site 2 transfer failure. That is roughly one branch in five — a hit rate high enough to become folklore, low enough to waste a great deal of time.

What makes it actively harmful is the cost of a miss. The folder holds the agent's datastore and the in-flight payload: the evidence for sites 1 and 2, gone. Then the reset fails, because the fault was in site 3, 4 or 5. Now you are diagnosing a subsystem whose evidence you deleted, and the next fix is chosen even more blindly than the first.

Proof it worked: the events that close the loop

"The error is gone" is not proof. The scan may not have run, the update may have been superseded, or the failure may be waiting on its next attempt. Prove the pipeline completed, leg by leg.

Those KB numbers and the service baseline above are real, read from the lab device. The four-leg sequence — scan, download, stage, install — is the proof, because each leg clears one or two of the five sites.

Then re-run Get-WindowsUpdateLog to a new file and confirm your code is absent from the window after the fix. Because the log is a static snapshot, you can diff it against your step-2 baseline and see the change directly. That is a far stronger claim than a green tick in Settings.

Both codes will appear forever. They are the two most generic failure modes in computing — the file was not there, and the bytes were wrong — and every layer of the update pipeline opens files and parses bytes.

What changes is what you do in the first five minutes. Decode the code, merge the log, read the component tag, and let the surrounding context name the subsystem. The fix is easy once you know which one it is, and unknowable until you do.

References

• System Error Codes (0-499) (WinError.h) - the canonical definitions: 2 (0x2) ERROR_FILE_NOT_FOUND "The system cannot find the file specified." and 13 (0xD) ERROR_INVALID_DATA "The data is invalid."
• [MS-ERREF]: HRESULT - the bit layout, the Facility field as "an indicator of the source of the error", and FACILITY_WIN32 = 7, "reserved to map undecorated error codes into HRESULTs."
• HRESULT_FROM_WIN32 macro (winerror.h) - "Maps a system error code to an HRESULT value", with the 0x0000FFFF mask and FACILITY_WIN32 shift that produce the 0x8007 prefix.
• Windows Update error code list by component - the WU_E_ tables broken out by subsystem, and the source of the component vocabulary used above. Cited chiefly for what it does not contain: no row for either of our codes.
• Common Windows Update errors - the 0x8007000D row: ERROR_INVALID_DATA, "Indicates data that isn't valid was downloaded or corruption occurred", mitigation "Try to redownload the update, and then start the installation."
• Troubleshoot Windows Update Error 0x80070002 - the dedicated article, the Failed to find file: ... [HRESULT = 0x80070002 - ERROR_FILE_NOT_FOUND] line, the FACILITY_NTWIN32 CSI excerpt, and the C:\Windows\Logs\CBS\CBS.log path with its CBSpersist rollover.
• Fix Windows Update errors - the "Common corruption errors" table listing both 0x80070002 and 0x8007000D, plus the CSI Payload Corrupt, CBS MUM Missing and CSI Manifest Corrupt markers used to separate site 3 from site 4.
• Error 0x8007000d at Startup After You Install a Windows Update - the rollback symptom and the HRESULT_FROM_WIN32(ERROR_INVALID_DATA) ... [gle=0x8007000d] log shape.
• Troubleshoot issues with WSUS client agents - the site 2 finding: ERROR_FILE_NOT_FOUND 0x80070002 = "The Parameters key is missing", with the required ServiceDll = %SystemRoot%\System32\qmgr.dll. Also BG_E_INSUFFICIENT_RANGE_SUPPORT, BG_E_MISSING_FILE_SIZE, the iuident.cab reachability test, and BITS's role in WSUS.
• BITS Return Values - the Bitsmsg.h constants. Establishes that genuine BITS faults carry their own 0x8020xxxx facility rather than 0x8007xxxx.
• Additional resources for Windows Update - the official reset: stop bits, wuauserv, cryptsvc, then rename DataStore, Download and catroot2 to *.BAK; plus the blunter rd /s /q %systemroot%\SoftwareDistribution form.
• Configure Windows Update for Business - the documented WUServer and WUStatusServer values under the WindowsUpdate policy key, and UseWUServer under the AU subkey.
• Windows Update log files - the log inventory: ETW traces in C:\Windows\Logs\WindowsUpdate, CBS.log in %systemroot%\Logs\CBS which "provides insight on the update installation part in the servicing stack", %WINDIR%\SoftwareDistribution\Datastore\Datastore.edb, and the USO .etl files.
• Get-WindowsUpdateLog - "Windows Update no longer directly produces a WindowsUpdate.log file", the -LogPath default of "WindowsUpdate.log in the Desktop folder of the current user", and the static-snapshot behaviour.
• How Windows Update works - "Windows Update downloads manifest files and provides them to the arbiter", and Windows Update's use of Delivery Optimization.