Windows Update error 0x80070005 (E_ACCESSDENIED) means access was denied to a file, folder, or registry entry required during an update download or installation. This guide applies to supported Windows client versions: supported Windows 11 releases and Windows 10 devices only when they remain eligible for the affected update. The safest first action is to confirm the failure in Windows Update and review WindowsUpdate.log or CBS.log before changing permissions.

What Windows Update error 0x80070005 means

In this specific context, 0x80070005 means E_ACCESSDENIED, or “Access is denied.” Microsoft documents the failure as Windows Update being unable to access required files, folders, or registry entries. Potential documented conditions include incorrect permissions affecting WinSxS or SoftwareDistribution, incorrect Component Based Servicing registry permissions, insufficient SYSTEM permissions on the Windows directory, or update files being locked by third-party security software.

The same hexadecimal code can appear in Microsoft Store, Windows activation, licensing, and other Windows contexts. Those occurrences do not share this Windows Update repair procedure. Confirm that the failed operation was an update download or installation and that the failure appears in update history or the relevant servicing logs.

Windows 10 coverage is conditional. Use these instructions only if the device remains eligible to receive the specific failed update. Confirm update applicability and prerequisites using Microsoft’s Windows Update troubleshooting guidance. This article does not cover unsupported Windows 10 upgrades, Azure VM-only recovery, Store errors, or activation errors.

Confirm 0x80070005 in WindowsUpdate.log or CBS.log

When this applies: Use this diagnostic first after an update fails and before changing component-store permissions.

Prerequisites: Access to the affected device and the ability to open WindowsUpdate.log or CBS.log. Later command-based repairs require administrative rights, but reviewing existing logs does not itself change the system.

Risk: Low. Data-loss risk: None identified. Rollback: No rollback is needed because this path only reviews evidence.

  1. Confirm that the failure is recorded as a Windows Update download or installation failure in update history.
  2. Open WindowsUpdate.log or CBS.log and search for 0x80070005.
  3. In CBS.log, look for related entries such as Failed to create file or Failed to internally open package. These phrases can support an access-denied diagnosis, but they do not prove that every occurrence has the same underlying cause.
  4. If a static Windows Update log is needed, generate it with Get-WindowsUpdateLog.
  5. Confirm that the code belongs to Windows Update rather than Microsoft Store, activation, licensing, or another component.

Expected result: The review should establish whether 0x80070005 occurred during Windows Update and whether the logs contain access-denied evidence relevant to the later repair paths. If the code is absent or belongs to another component, stop using this guide rather than assuming a permissions failure.

Microsoft’s common Windows Update error reference also identifies this code as an access-denied condition and points to CBS.log analysis where permissions may have changed.

Use the applicable servicing repair path

The following are separate Microsoft-documented paths, not a script that should be run automatically from top to bottom. Use only the path whose stated condition applies. Every command in this section requires an elevated Command Prompt and administrative rights. The official error-specific sequence contains dependencies involving permission and component resets; those conditions are retained below even though DISM and SFC are less invasive than recursive permission changes.

Repair the component store with DISM

When this applies: Use if the error persists after the applicable permission and Windows Update component resets.

Prerequisites: Administrative rights and an elevated Command Prompt.

Risk: Medium. Data-loss risk: No direct data-loss risk is documented, but a servicing repair should not be treated as risk-free. Rollback: There is no direct rollback. Use system recovery or support if DISM introduces new servicing issues.

  1. Run DISM /Online /Cleanup-Image /RestoreHealth.
  2. Restart the computer.
  3. Try the update again.

Expected result: After the restart, retry the same update and check whether 0x80070005 returns. Microsoft does not specify a separate error-specific success message for this procedure.

Check system file integrity with SFC

When this applies: Use after DISM or when system file corruption is suspected.

Prerequisites: Administrative rights and an elevated Command Prompt.

Risk: Medium. Data-loss risk: No direct data-loss risk is documented. Rollback: There is no direct rollback; use recovery options if repairs fail repeatedly or create new problems.

  1. Run sfc /scannow.
  2. If issues are found, follow Microsoft guidance for repairing missing or corrupted system files.
  3. Restart the computer.
  4. Retry the update.

Expected result: Retry the affected update after the restart and determine whether the access-denied failure remains. Do not infer success from an undocumented message.

Reset Windows Update components

When this applies: Use if the applicable permission repair did not resolve the failure.

Prerequisites: Administrative rights and an elevated Command Prompt.

Risk: Medium. Data-loss risk: No direct data-loss risk is documented. Rollback: Rename the .old folders back only if needed and only if the update stack remains functional.

  1. Stop wuauserv, bits, and cryptSvc.
  2. Rename %windir%\SoftwareDistribution to SoftwareDistribution.old.
  3. Rename %windir%\System32\catroot2 to catroot2.old.
  4. Start cryptSvc, bits, and wuauserv.
  5. Restart the computer and retry the update.

Expected result: The update components use the renamed locations after restart. Retry the same update and check whether the exact code recurs. Do not delete the folders or add undocumented service commands.

The syntax and applicability conditions for these paths come from Microsoft’s Windows Update error 0x80070005 guidance.

Reset component-store permissions only when logs support it

When this applies: Use only when WindowsUpdate.log or CBS.log suggests access was denied on WinSxS or SoftwareDistribution. This is not a general-purpose or quick Windows Update fix.

Prerequisites: Administrative rights and an elevated Command Prompt.

Risk: High. These are recursive permission changes to Windows servicing locations. Data-loss risk: No direct data-loss risk is documented, but incorrect permissions can disrupt Windows servicing or applications. Rollback: Restore from a known-good backup or contact Microsoft Support if servicing breaks after the changes.

  1. Run icacls "%windir%\WinSxS" /reset /t /c /q.
  2. Run icacls "%windir%\SoftwareDistribution" /reset /t /c /q.
  3. Restart the computer.
  4. Try the update again.

Expected result: Retry the affected update after restarting and check whether the same access-denied code remains. The official source does not define a separate visible success state for the permission reset.

Do not change permissions on other folders or registry locations. If either operation produces new servicing or application failures, stop rather than attempting broader permission resets.

Restore TrustedInstaller ownership if the permission reset fails

When this applies: Use only if the documented component-store permission reset did not resolve the update failure.

Prerequisites: Administrative rights and an elevated Command Prompt.

Risk: High. This recursively changes ownership within WinSxS. Data-loss risk: No direct data-loss risk is documented, but an incorrect ownership state can affect servicing. Rollback: Reapply the prior owner only when a known-good backup or enterprise recovery process preserves the previous state.

  1. Run icacls "%windir%\WinSxS" /setowner "NT SERVICE\TrustedInstaller" /t /c /q.
  2. Restart the computer.
  3. Try the update again.

Expected result: Retry the affected update after restarting and check whether 0x80070005 returns. Do not substitute another owner, add takeown commands, or assume the change is reversible without a known prior state.

If the ownership change creates new servicing problems, stop and escalate to Microsoft Support or an administrator.

Check antivirus and filter drivers only after servicing repairs fail

When this applies: Use only after servicing repairs fail and the logs still suggest access denial. Third-party antivirus or another security tool can lock update-related files or folders, but the safety of unloading a particular filter driver must be verified for the affected device.

Prerequisites: Administrative access, the ability to temporarily disable security software, and device-specific verification before unloading any identified driver.

Risk: High. Disabling antivirus temporarily reduces protection, and unloading the wrong filter driver can disrupt security, encryption, backup, or storage software. Data-loss risk: No direct data-loss risk is documented for the confirmed path, but device-specific driver effects cannot be assumed safe. Rollback: Re-enable antivirus and reload the driver or reboot to restore unloaded drivers.

  1. Temporarily disable real-time antivirus protection.
  2. Run fltmc to list file-system filter drivers.
  3. If a non-Microsoft filter driver is present, unload it only by name with fltmc unload <DriverName>.
  4. Restart the computer and retry the update.

Expected result: The retry can indicate whether third-party interference was associated with the failure. Re-enable antivirus after the test. Do not unload all filters, guess a driver name, or leave protection disabled.

If you cannot verify that a specific non-Microsoft filter driver is safe to unload, do not proceed with that step. Escalate to the software vendor, an administrator, or Microsoft Support instead.

When to stop and escalate

Stop self-repair if a permission or ownership change creates new servicing or application errors. Use the rollback attached to the path attempted: restore from a known-good backup after recursive permission changes, use a known prior ownership state only where one exists, rename component folders back only under the documented condition, or reboot and re-enable security software after interference testing.

  • Preserve the relevant WindowsUpdate.log and CBS.log evidence.
  • Record which confirmed path was attempted and whether 0x80070005 remained after the retry.
  • Contact Microsoft Support or an administrator when servicing permissions remain unresolved.
  • Escalate rather than unloading a filter driver whose device-specific safety cannot be verified.
  • Do not expand the repair into broad permission resets, registry edits, a clean installation, or an in-place repair based on this guide.

Windows Update error 0x80070005 can have several access-denied causes, so no single path is guaranteed to resolve every configuration. Log evidence and the stated applicability conditions should determine which documented repair is appropriate.