Error 0x80070005 means Access Denied.
For Windows Update, Microsoft identifies it as E_ACCESSDENIED and states that it occurs when the update process cannot access required files, folders, or registry entries. [R1] [R2]
The important distinction is:
The code tells us that access was denied. It does not tell us which resource denied access or why.
That makes the surrounding evidence important.
Does this mean my Windows account is not an administrator?
Not necessarily.
Microsoft's general Windows Update guidance notes that some updates require administrator access. [R3]
However, a Windows Update 0x80070005 can still occur while you are signed in with an administrator account.
Windows servicing also relies on system identities such as SYSTEM and TrustedInstaller. Microsoft documents cases where this error is caused by incorrect permissions on Windows servicing folders or registry entries used by those identities. [R1]
So the useful question is not only:
“Am I an administrator?”
It is:
“Which Windows Update resource was denied access?”
What can cause this error?
Microsoft documents several causes for Windows Update 0x80070005, including:
- incorrect permissions on the Windows component store (
WinSxS); - incorrect permissions on the
SoftwareDistributionfolder; - incorrect permissions on Component Based Servicing registry entries;
- the SYSTEM account lacking required access to the Windows directory;
- a third-party antivirus or security product locking update-related files or folders; and
- Group Policy or a management agent restricting write access to system directories. [R1]
These are alternatives, not a checklist of things that should all be changed.
The error itself does not prove that antivirus software is responsible, nor does it prove that Windows permissions should be reset globally.
How can Windows tell what was denied?
The most useful evidence is often in the Windows servicing logs.
Microsoft recommends reviewing WindowsUpdate.log or CBS.log and finding 0x80070005 entries around the time the update failed. [R1]
The log may identify an operation such as:
- failing to create or modify a file;
- failing to open an update package;
- failing to access a registry key; or
- another servicing operation being denied.
That narrows the problem from a generic Access Denied message to a particular object or operation.
Microsoft's common-error guidance specifically recommends identifying the object that lacks the required permissions before changing those permissions. [R2]
Should I change folder or registry permissions myself?
Not as a first response.
Windows system folders and servicing registry keys have deliberate permission structures. Changing them broadly can create new security or servicing problems.
Microsoft's dedicated troubleshooting procedure contains administrative commands for restoring permissions and ownership on specific servicing resources. [R1]
Those are repair operations for a diagnosed permissions problem, not a reason to grant broad access to Windows folders.
Do not take ownership of C:\Windows, grant Everyone full control, or copy registry-permission instructions from unrelated forum posts.
If logs identify a particular servicing permission problem, use the documented repair procedure for that resource.
Could antivirus or security software cause it?
Yes, but the code alone does not prove that.
Microsoft documents third-party antivirus or security software locking update-related files or folders as one possible cause of Windows Update 0x80070005. [R1]
Microsoft's consumer Windows Update guidance also lists temporarily disabling third-party antivirus or firewall software as a troubleshooting step for this error. [R3]
Treat that as a targeted test, not a permanent fix.
If security software is suspected:
- Check whether it logged or quarantined anything at the time of the failed update.
- Make sure the security product is current.
- Follow the security vendor's own instructions if a temporary test is necessary.
- Re-enable protection immediately after the test.
Do not disable Microsoft Defender, a firewall, or other security controls permanently to make an update install.
What if this is a work or school PC?
A managed device may intentionally restrict access through Group Policy or management software.
Microsoft specifically lists Group Policy settings or management agents restricting writes to system directories as a possible cause of this error. [R1]
If the affected PC is managed by an employer or school, do not remove those policies or change protected permissions yourself.
The administrator should determine whether the restriction is intentional, incorrectly configured, or interfering with the update.
Is 0x80070005 always a Windows Update error?
No.
0x80070005 is a general Windows Access Denied result and can appear in other contexts, including Windows activation and Microsoft Office. Microsoft documents separate causes and repairs for those uses of the same code. [R4]
This article applies when Windows Update itself reports 0x80070005.
The application or subsystem that produced the error must therefore be preserved as part of the evidence.
What should I do now?
- Confirm that
0x80070005came from Windows Update, not another application. - Restart Windows and retry the update once.
- Confirm that the account being used has appropriate administrator access for installing updates.
- If the error repeats, inspect the Windows Update and CBS evidence around the failure time.
- Identify the file, folder, registry key, package, or other operation that was denied access before changing permissions.
- If third-party security software appears in the evidence, investigate it as a possible file lock rather than assuming it is responsible.
- On a managed PC, involve the administrator before changing Group Policy, management settings, or protected system permissions.
- Apply only the repair appropriate to the identified access problem.
- Restart if the repair requires it and retry the original update.
A successful repair means the previously denied operation can complete and the original Windows update installs successfully.
Changing permissions or temporarily disabling a security product without successfully installing the original update is not proof that the incident is resolved.