Skip to content

Est. 2011·Microsoft Partner 7033487·Delivery under 3 min·Support 7 days a week

Your vault is empty.

License Error 0x80070005

0x80070005: Access Denied During Install When Endpoint Protection Blocks It

11 min read Updated October 4, 2026 Installers, Runtimes & App Deployment

Fix it now

0x80070005 is plain access denied, but during an install it arrives from four different layers and each has a different fix. Which layer said no is the whole job, and the companion codes name it for you. Work out whether you are fixing an application installer or Windows servicing before you change anything.

Run these from an elevated Command Prompt to see who you are and what is applied

gpresult /h C:\temp\policy.html
net localgroup Administrators
fltmc
  1. Run the installer elevated and confirm the account is a local administrator. That rules out the simplest cause in thirty seconds.
  2. Check whether a scanner objected: Windows Security, Virus & threat protection, Protection history, and the third-party product’s own log if one is present. 0x800700E1 and 0x800700E2 are that verdict expressed as a code.
  3. Check application control: Event Viewer, Applications and Services Logs, Microsoft, Windows, then the AppLocker and CodeIntegrity Operational channels, at the timestamp of the failure. 0x800704EC is ‘this program is blocked by group policy’.
  4. Read the gpresult report for software restriction and application control sections before touching any permissions.
  5. If a security agent is refusing, change the setting in its management console rather than on the device.

For an application installer, permissions are the last thing to look at, not the first. For Windows servicing the order is different – see the next section, because Microsoft’s own resolution for 0x80070005 during updates starts with permissions.

If the install completes once the refusing layer is satisfied, stop here. Otherwise the next section separates the two cases.

Why it happens

An install crosses several access decisions in sequence. The process token has to carry administrative rights and the specific privileges the operation needs. The file system has to permit the write. Application control policy has to permit the executable to run at all. And any security agent present has its own opinion, both about the installer’s contents and about writes into its own directories.

Each of those refusals can surface as access denied, which is why blindly changing folder permissions wastes so many afternoons. The companion codes are far more useful because they name the layer. 0x800704EC is ERROR_ACCESS_DISABLED_BY_POLICY – “this program is blocked by group policy. For more information, contact your system administrator.” 0x80070522 is ERROR_PRIVILEGE_NOT_HELD, a required privilege is not held by the client, which is a different thing from a missing file permission.

0x800700E1 and 0x800700E2 are not really errors at all. ERROR_VIRUS_INFECTED is “operation did not complete successfully because the file contains a virus or potentially unwanted software”, and ERROR_VIRUS_DELETED adds that the file has been removed from this location. They are a scanner telling you it refused to hand over the file. Sometimes the verdict is right and the installer is not what you think it is; sometimes it is a false positive on an uncommon tool. Read the detection before deciding, rather than disabling the scanner and running the file anyway.

The one case where permissions genuinely come first is Windows servicing. Microsoft’s documented causes for 0x80070005 during updates are the TrustedInstaller service account lacking permissions on %windir%\WinSxS or %windir%\SoftwareDistribution, incorrect permissions on the Component Based Servicing registry subkey, a third-party antivirus or security tool locking update files, the SYSTEM account lacking Full Control on %windir%, and a Group Policy setting or management agent restricting write access to system directories.

The installer is not running elevated

You have this one if 0x80070005 immediately, on a machine with no policy and no security product in the way.

  1. Right-click the installer and choose Run as administrator, or launch it from an elevated prompt.
  2. Confirm the account is in the local Administrators group: net localgroup Administrators.
  3. For a pushed deployment, check what context the deployment agent runs as. That is where this hides on managed estates.

Policy is blocking the program

You have this one if 0x800704EC, or entries in the AppLocker or CodeIntegrity channels at the moment of the failure.

  1. Read gpresult /h C:\temp\policy.html and look at the software restriction and application control sections.
  2. Change the rule at the policy object, then gpupdate /force on the client. Local edits on a managed device do not survive.
  3. Microsoft’s wording is narrow and useful: ‘this program is blocked by group policy’. That is a rule to change, not a permission to widen.

A scanner has taken the file

You have this one if 0x800700E1 or 0x800700E2, and the installer has quietly disappeared from disk.

  1. Read the detection in Protection history or the third-party product’s log before doing anything else.
  2. If the verdict is wrong, get the file re-checked by the vendor rather than excluding it permanently on a hunch.
  3. If you do add an exclusion, scope it to the file and remove it afterwards.

0x800700E2 means the file has already been removed from that location. Re-downloading it into the same folder will usually produce the same result within seconds.

A required privilege is missing, not a permission

You have this one if 0x80070522, ERROR_PRIVILEGE_NOT_HELD – ‘a required privilege is not held by the client’.

  1. Check User Rights Assignment in the effective policy. This is about privileges such as taking ownership or loading drivers, not about ACLs on a folder.
  2. A privilege removed by a hardening baseline is the usual cause, and widening file permissions will not compensate for it.
  3. Fix it in the baseline rather than on the device if the estate is managed.

It is servicing, not an application install

You have this one if 0x80070005 from Windows Update or DISM rather than from an installer.

  1. Reset the component store permissions: icacls "%windir%\WinSxS" /reset /t /c /q and the same for %windir%\SoftwareDistribution.
  2. Restore ownership: icacls "%windir%\WinSxS" /setowner "NT SERVICE\TrustedInstaller" /t /c /q.
  3. Then reset the update components, repair the image with DISM /Online /Cleanup-Image /RestoreHealth, and run sfc /scannow.

Full reference

Microsoft’s own resolution order for the servicing case

  1. Reset the permissions on the component store: icacls "%windir%\WinSxS" /reset /t /c /q, then the same for %windir%\SoftwareDistribution.
  2. Make sure TrustedInstaller owns WinSxS: icacls "%windir%\WinSxS" /setowner "NT SERVICE\TrustedInstaller" /t /c /q.
  3. Reset the Windows Update components: stop wuauserv, bits and cryptSvc, rename %windir%\SoftwareDistribution and %windir%\System32\catroot2 to .old, then start the three services again.
  4. Repair the component store: DISM /Online /Cleanup-Image /RestoreHealth.
  5. Check system file integrity: sfc /scannow.
  6. Check for third-party filter interference: fltmc to list the loaded minifilters, and fltmc unload <DriverName> to unload one for a test.

That sequence is for servicing failures. Do not run it because an application installer returned access denied – resetting ACLs across WinSxS to fix a third-party setup problem is a large change aimed at the wrong target.

The layer each code names

Code Win32 Layer
0x80070005 5 Access denied. Could be any of the four layers – use the others to narrow it
0x800704EC 1260 ERROR_ACCESS_DISABLED_BY_POLICY – this program is blocked by group policy
0x80070522 1314 ERROR_PRIVILEGE_NOT_HELD – a required privilege is not held by the client
0x800700E1 225 ERROR_VIRUS_INFECTED – the file contains a virus or potentially unwanted software
0x800700E2 226 ERROR_VIRUS_DELETED – and the file has been removed from this location

Where to look, in order

Check Where
Elevation and group membership net localgroup Administrators, and how the installer was launched
Scanner verdict Windows Security, Virus & threat protection, Protection history; plus the third-party product’s log
Application control Event Viewer, Applications and Services Logs, Microsoft, Windows, AppLocker and CodeIntegrity Operational
Effective policy gpresult /h C:\temp\policy.html
Filter drivers fltmc, and fltmc unload <DriverName> for a controlled test
File permissions icacls <path> – last for an application installer, first for servicing

Why taking ownership is the wrong instinct

Taking ownership of system folders to get an install through changes who Windows believes is responsible for those directories, and servicing operations later expect TrustedInstaller to own them. The version of this that is actually documented is narrow and specific: reset the ACLs, then set the owner back to NT SERVICE\TrustedInstaller. That is a repair, not a widening. Granting your own account Full Control on a system directory and leaving it there is the destructive version of the same idea, and it tends to produce servicing failures months later that nobody connects to the install.

When every layer says it is not them

  • Test the same installer on a clean machine of the same build. If it runs there, the fault is this machine’s configuration rather than the package.
  • Check whether the installer writes into a security product’s own directory. Agents defend those paths and the refusal is by design.
  • Look for a management agent that reapplies a restriction between your change and your retry – the symptom is a fix that works once and then stops.
  • Confirm the target path is not redirected by folder redirection or a virtualisation layer to somewhere the account genuinely cannot write.

When a licence is the actual fix

Nothing in this article is fixed by buying software, and a paid endpoint suite will not make access denied go away. What a managed tier changes is your ability to answer the question the article is really about: which layer refused, and can you see it from somewhere other than the machine. ESET PROTECT Entry is the managed-console tier where detections, exclusions and tamper settings are visible and changeable centrally, so a false positive on a deployment package shows up as a detection you can look at across the estate rather than a file that silently vanished on one desk. That is worth paying for when you deploy software regularly to machines you cannot walk up to. It is worth nothing if the refusal turned out to be elevation, policy or servicing permissions, which between them account for most of these – so identify the layer first, and only then decide whether the answer is commercial.

Every code this article covers

Code What it points at Source
0x80070005 E_ACCESSDENIED / Win32 error 5, ‘access is denied’. In servicing, Microsoft describes it as occurring if the update process cannot access required files, folders or registry entries Microsoft Learn
0x800704EC Win32 error 1260, ERROR_ACCESS_DISABLED_BY_POLICY: ‘this program is blocked by group policy. For more information, contact your system administrator’ Microsoft Learn
0x80070522 Win32 error 1314, ERROR_PRIVILEGE_NOT_HELD: ‘a required privilege is not held by the client’ Microsoft Learn
0x800700E1 Win32 error 225, ERROR_VIRUS_INFECTED: ‘operation did not complete successfully because the file contains a virus or potentially unwanted software’ Microsoft Learn
0x800700E2 Win32 error 226, ERROR_VIRUS_DELETED: the file contains a virus or potentially unwanted software and has been removed from this location Microsoft Learn

Confirm the fix worked

  1. The installer completes when run elevated by an account in the local Administrators group.
  2. No new entries appear in the AppLocker or CodeIntegrity Operational channels at the time of the run.
  3. Protection history shows no detection for the installer.
  4. For a servicing fix, DISM /Online /Cleanup-Image /RestoreHealth completes and the update installs.

Questions people ask about this

Should I take ownership of the target folder?

Almost never. The documented use of ownership here is resetting the component store back to NT SERVICE\TrustedInstaller during a servicing repair. Taking ownership yourself to force an application install through leaves system directories owned by an account servicing does not expect, and the bill arrives later.

The installer vanished from my Downloads folder.

That is 0x800700E2 – the scanner removed it. Read the detection before you re-download, because if the verdict stands you will lose the file again within seconds of it landing.

What is the difference between 0x80070005 and 0x80070522?

Access denied is a permission on an object. ERROR_PRIVILEGE_NOT_HELD is a privilege the account’s token does not carry at all – things like loading a driver or taking ownership. Widening file permissions does not grant a privilege, which is why the usual fix does nothing for it.

Windows Update returns 0x80070005. Is this the same article?

Same code, different resolution order. For servicing, Microsoft’s documented causes start with permissions on WinSxS, SoftwareDistribution and the Component Based Servicing registry key, and the fix is the icacls reset plus a component store repair – not the application-install triage above.

Related error codes

Was this article helpful?

Your feedback helps us improve our documentation.

Related articles

License Error 0x80073CFF: Sideloading and App-V Blocked by Policy or Windows Edition Free Fix MSI 1612 and 1706: Installation Source Missing When You Repair or Remove Apps Free Fix 0x800F0906 and 0x800F081F: .NET Framework 3.5 Will Not Enable on Windows License Error 0x80072EFD: Store Downloads Fail Behind a Proxy or Security Suite
← Back to Knowledge Base