Windows Update: 0x80070005 (E_ACCESSDENIED) on install

Hi, it's BlueByte. You install a Windows update, it grinds for a while, then rolls back with 0x80070005 — and Windows Update only says something went wrong. Nothing in the update is corrupt: 0x80070005 is E_ACCESSDENIED, a plain "access denied," and it means the servicing stack tried to touch a file, folder, or registry key it wasn't allowed to. We'll walk through what that code means, the permission gaps that cause it, how to read CBS.log to see exactly what was denied, fix it per cause, and keep it from coming back.

What 0x80070005 (E_ACCESSDENIED) is actually telling you

0x80070005 is the Windows HRESULT for E_ACCESSDENIED — "general access denied error." When it shows up during Windows Update, the payload downloaded fine; the failure is that the component-based servicing (CBS) engine couldn't read or write something it needed. In CBS.log the failure reads like this:

Error   CBS   Failed to create file. [HRESULT = 0x80070005 - E_ACCESSDENIED]
Error   CBS   Failed to internally open package. [HRESULT = 0x80070005 - E_ACCESSDENIED]

This is a permissions problem on the machine, not a bad update. You don't need to reinstall Windows — you need to find which object the servicing stack couldn't reach and give it back the access it expects.

Where the update loses access — the permission gaps behind it

Per Microsoft's guidance, 0x80070005 during servicing comes from one of these:

• The TrustedInstaller service account lacks permissions on %windir%\WinSxS (the component store) or %windir%\SoftwareDistribution.
• The permissions on the registry subkey HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing are wrong.
• A third-party antivirus or security tool locked update files or folders while CBS was using them.
• The SYSTEM account doesn't have Full Control on %windir%.
• A Group Policy setting or management agent restricted write access to system directories.

(%windir% is the Windows folder — C:\Windows by default.) All five reduce to the same thing: the update runs as a system account, and something changed the ACLs so that account can no longer write where it must.

Find the exact denial in CBS.log before you change anything

Don't reset permissions blindly — read the log first so you fix the right object. The servicing log lives at %windir%\logs\CBS; open the newest CBS.log and search for , error, then match the timestamp of your failed install. To get a readable Windows Update log at the same time, generate one from an elevated PowerShell:

Get-WindowsUpdateLog

Search that output for 0x80070005. The line just above the error usually names the file or registry key that was denied — that is the object whose permissions you will restore.

Reset the permissions on the component store first

The most common cause is a broken ACL on the component store, so start there. In an administrator Command Prompt, reset the inherited permissions and confirm TrustedInstaller owns the store:

icacls "%windir%\WinSxS" /reset /t /c /q
icacls "%windir%\SoftwareDistribution" /reset /t /c /q
icacls "%windir%\WinSxS" /setowner "NT SERVICE\TrustedInstaller" /t /c /q

/reset restores the default inherited ACLs, /t recurses through the tree, /c continues past errors, and /q keeps it quiet. Restart the machine and retry the update. On many machines this alone clears 0x80070005, because the servicing stack can write to the store again.

Rebuild the update stack when permissions aren't enough

If the error survives the ACL reset, clear the update caches and repair the store. Stop the services, rename the two cache folders so Windows rebuilds them, then start the services again:

net stop wuauserv
net stop bits
net stop cryptSvc
ren %windir%\SoftwareDistribution SoftwareDistribution.old
ren %windir%\System32\catroot2 catroot2.old
net start cryptSvc
net start bits
net start wuauserv

Then repair the component store and verify the system files:

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

DISM pulls fresh component payloads (it uses Windows Update as its source by default) and sfc re-checks protected system files. Restart and retry the update once more.

A real case: an antivirus filter driver holding the store

A file server won't take its monthly cumulative update — every attempt ends at 0x80070005. The CBS.log shows Failed to create file ... E_ACCESSDENIED on a file under SoftwareDistribution. The ACL reset doesn't help, which points at a lock rather than a permission. You list the file-system filter drivers:

fltmc

A non-Microsoft antivirus filter appears in the list. You temporarily disable real-time protection and unload it:

fltmc unload <DriverName>

The next update run installs cleanly. The security tool had been holding update files open while CBS tried to replace them, so the denial was really a lock in disguise.

Confirm the update installs and the log stays clean

Retry from Settings ▸ Windows Update. When it reaches Installed (or prompts for the restart that finishes it), open the newest CBS.log again and search for E_ACCESSDENIED — a clean run leaves no fresh 0x80070005 line. The update installed and no new denial in the log is your all-clear.

Keep 0x80070005 from coming back

Leave the ACLs and ownership on %windir%, WinSxS, and the registry CBS key at their defaults — most cases start with a well-meaning "harden the system" script that stripped SYSTEM or TrustedInstaller access. If a security tool caused the lock, add the update folders to its exclusions so it doesn't hold them during servicing. And review any Group Policy that changes permissions on system directories; a policy that looks harmless can quietly break every future update.

How this differs from 0x80246017 and 0x80070020

0x80070005 is the servicing account being denied by an ACL. 0x80246017 (WU_E_DM_UNAUTHORIZED_LOCAL_USER) is different — there the signed-in user lacks rights to download updates, and the fix is to run as a local administrator, not to touch ACLs. 0x80070020 (ERROR_SHARING_VIOLATION) is a file that's locked open by another process rather than permission-denied; you trace it with Process Monitor and stop the offending process. If the log says E_ACCESSDENIED, it's a permission gap — reset the ACLs; if it says a sharing violation, hunt the lock instead.