Interactive Troubleshooter

Published: Oct 28, 2026

System Restore Failed 0x80070005 Antivirus Conflict Tree

Time: 15 mins Level: Beginner

By StepDiag Engineering Team

Reviewed by Ibraheem Taofeeq Opeyemi

An exhaustive troubleshooting guide addressing Windows System Restore error 0x80070005 ('Access is denied') triggered by third-party security software, Volume Shadow Copy Service permission blocks, and file filter driver locks.

Full Diagnostic Tree & Step-by-Step Overview

How is the System Restore error 0x80070005 manifesting across your Windows environment?

Fails immediately upon starting restore with active third-party antivirus running
Fails midway during registry rollback due to file lock or access denied permission faults
Fails when attempting restore from Windows Recovery Environment (WinRE) or Safe Mode
Fails persistently across all environments with Volume Shadow Copy Service (VSS) errors

Select the specific behavior observed with your third-party security suite during the restore attempt:

Real-time protection actively quarantines temporary staging files in System Volume Information
Self-protection or anti-tamper modules block changes to protected system registry hives
Antivirus kernel filter driver intercepts and blocks VSS snapshot mount operations
Error persists even after temporarily disabling standard real-time scanning features

Select the permission or file lock symptom encountered during the registry or file restoration phase:

Access Denied on specific registry keys under HKEY_LOCAL_MACHINE\SYSTEM
Insufficient privileges on the System Volume Information directory structure
TrustedInstaller or SYSTEM account ownership conflicts on staging files
Corrupted access control lists (ACLs) inherited from third-party backup software

Select the specific behavior when attempting recovery actions from WinRE or Safe Mode:

Safe Mode boot loads conflicting security drivers that continue blocking restoration
WinRE environment lacks necessary catalog drivers to access encrypted system drives
System Restore points are missing or reported as corrupted in the recovery interface
Command-line rstrui.exe execution fails with error 0x80070005 directly in WinRE

Select the VSS or subsystem symptom observed during the diagnostic check:

Volume Shadow Copy service crashes or throws access denied during writer status enumeration
Software Protection service (sppsvc) lacks necessary network service permissions
COM+ Event System or Distributed Transaction Coordinator permission corruption
Shadow storage allocation limit exceeded or quota access restricted

Solution:

Root Cause: Antivirus Real-Time Quarantine Interference

Third-party security suites feature aggressive real-time behavioral monitors that scan temporary staging files created inside the System Volume Information directory during restore initialization. When restore processes attempt to unpack or write back archived system states, the security software misidentifies these rapid modifications as suspicious activity or ransomware-like behavior, resulting in an access denied error (0x80070005).

Diagnostic Verification:

Open Event Viewer via Win + X and navigate to Applications and Services Logs -> Microsoft -> Windows -> System Restore -> Operational.

Look for Event ID 10 or 101 showing access denied codes during the staging phase.

Review your third-party antivirus quarantine history or threat log for blocked paths matching System Volume Information\\*.

Step-by-Step Fix:

1Configure Antivirus Exclusions:

Open your third-party antivirus management console.

Add an exclusion for the System Volume Information folder on all local system drives, as well as the executable path C:\\Windows\\System32\\rstrui.exe.

2Clean Boot Windows to Eliminate Interference:

Press Win + R, type msconfig, and press Enter.

Under the Services tab, check 'Hide all Microsoft services', then click 'Disable all'.

Go to the Startup tab, click 'Open Task Manager', and disable all startup items.

Restart your computer.

3Execute System Restore:

Open Command Prompt as Administrator and run rstrui.exe to initiate the restore process without background security filter interference.

Prevention & Long-Term Monitoring:

Maintain permanent exclusions for critical OS diagnostic tools in your security suite.

Regularly update your antivirus software to prevent behavioral false positives on native Windows maintenance routines.

Solution:

Root Cause: Security Suite Self-Protection Registry Locking

Advanced endpoint protection and security suites implement self-protection drivers that secure kernel-level registry keys from modification. During a System Restore, the engine attempts to overwrite protected subkeys under HKEY_LOCAL_MACHINE\\SYSTEM and HKEY_LOCAL_MACHINE\\SOFTWARE. The security driver intercepts these write requests, treating them as unauthorized tampering, and throws error 0x80070005.

Diagnostic Verification:

Check the Windows Setup or System event logs for registry hive rollback failures coinciding with third-party driver initialization.

Run fltmc in an elevated Command Prompt to list active file system filter drivers and identify security product filters.

Step-by-Step Fix:

1Disable Self-Protection Temporarily:

Open your antivirus settings panel and locate the 'Self-Defense', 'Tamper Protection', or 'Secure Boot Protection' toggle.

Disable this feature temporarily (note that a reboot may be required for full driver disengagement).

2Boot into Safe Mode:

Hold Shift while clicking Restart in the Windows Start menu.

Navigate to Troubleshoot -> Advanced options -> Startup Settings -> Restart, then press 4 or F4 to enable Safe Mode.

3Run System Restore:

In Safe Mode, launch rstrui.exe and select your restore point. Because third-party self-protection drivers do not load in Safe Mode, registry hive modification will succeed.

Prevention & Long-Term Monitoring:

Re-enable tamper protection immediately following a successful system restore.

Consult vendor documentation (such as Microsoft Official Support Guide) for recommended procedures when performing major system recovery tasks.

Solution:

Root Cause: Filter Driver Interception of VSS Snapshot Mounts

Third-party backup and security software install lower and upper file system filter drivers that hook into the Volume Shadow Copy Service (VSS) storage stack. When System Restore attempts to mount and read from a shadow snapshot, these conflicting filter drivers disrupt IOCTL communication, denying access to the snapshot storage blocks.

Diagnostic Verification:

Run vssadmin list writers in an elevated command prompt to verify writer stability.

Review registry path HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\Class\\{71a27cdd-812a-11d0-bec7-08002be2092f} (UpperFilters / LowerFilters) for third-party driver attachments.

Step-by-Step Fix:

1Purge Conflicting Filter Drivers:

Open Registry Editor (regedit) as Administrator.

Navigate to HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\Class\\{71a27cdd-812a-11d0-bec7-08002be2092f}.

Check the UpperFilters and LowerFilters multi-string values. Remove rogue entries injected by third-party software, leaving standard Microsoft drivers intact.

2Restart VSS and Associated Services:

Open PowerShell as Administrator and run Restart-Service VSS, Restart-Service swprv.

3Validate Restoration Path:

Retry running rstrui.exe to verify that filter driver communication is restored.

Prevention & Long-Term Monitoring:

Audit newly installed backup or security utilities that modify storage stack filter drivers.

Solution:

Root Cause: Stubborn Background Security Services and Hooks

Even when standard user interfaces for third-party security software are disabled, kernel-mode service hooks and watchdogs remain active in memory, enforcing strict access controls on system files and causing error 0x80070005 during restore operations.

Diagnostic Verification:

Use PowerShell to inspect running non-Microsoft services: Get-Service | Where-Object {$_.Status -eq 'Running'} | Select-Object Name, DisplayName.

Cross-reference active services with known security vendor service names.

Step-by-Step Fix:

1Stop Security Services via PowerShell:

Open an elevated PowerShell prompt.

Stop specific security services using command: Stop-Service -Name "ServiceName" -Force (replace with your specific antivirus service name).

2Execute Offline System Restore:

Boot into WinRE via advanced startup.

Open Command Prompt from the recovery menu and execute rstrui.exe directly from the offline environment where third-party service hooks are completely absent.

3Verify System Integrity:

Run sfc /scannow after recovery to ensure all system files are intact.

Prevention & Long-Term Monitoring:

Utilize official vendor uninstallation tools if a security suite leaves persistent kernel hooks after removal.

Solution:

Root Cause: Registry Key Permission Corruption on HKLM\\SYSTEM

During system restore, the restoration engine must replace active registry hives. If specific subkeys under HKEY_LOCAL_MACHINE\\SYSTEM have had their Access Control Lists (ACLs) altered by malware, security software, or aggressive tweaking utilities, the SYSTEM account loses write privileges, triggering error 0x80070005.

Diagnostic Verification:

Open Registry Editor and navigate to HKEY_LOCAL_MACHINE\\SYSTEM\\Setup or related hives.

Right-click the key, select Permissions, and verify that SYSTEM and Administrators possess Full Control.

Step-by-Step Fix:

1Take Ownership and Reset Permissions:

Open an elevated Command Prompt.

Run takeown /f C:\\Windows\\System32\\config\\SYSTEM /a to assign ownership to the Administrators group.

Run icacls C:\\Windows\\System32\\config\\SYSTEM /grant administrators:F /t to restore full control permissions.

2Reset Default Registry ACLs:

Use an administrative script or safe utility to reapply default security descriptors to protected system hives.

3Retry System Restore:

Launch rstrui.exe to complete the rollback.

Prevention & Long-Term Monitoring:

Avoid running unauthorized registry permission hardening scripts that strip system-level access rights.

Solution:

Root Cause: System Volume Information Directory ACL Corruption

The hidden System Volume Information folder at the root of protected drives requires strict security descriptors owned exclusively by the SYSTEM account. If permissions on this folder are modified or corrupted, restore points cannot be unpacked, resulting in access denied errors.

Diagnostic Verification:

Run icacls "C:\\System Volume Information" in an elevated Command Prompt and inspect the output for missing SYSTEM or Administrator access rights.

Step-by-Step Fix:

1Take Ownership of System Volume Information:

Run takeown /f "C:\\System Volume Information" /r /d y in an elevated Command Prompt.

2Grant Full Control to SYSTEM:

Run icacls "C:\\System Volume Information" /grant:r SYSTEM:F /t /c to restore necessary permissions.

3Reinitialize Restore Store:

Disable and re-enable System Protection via SystemPropertiesProtection GUI or PowerShell commands to recreate a clean folder structure.

Prevention & Long-Term Monitoring:

Never manually alter permissions or delete files directly inside the System Volume Information directory.

Solution:

Root Cause: TrustedInstaller vs. SYSTEM Ownership Conflicts

Protected operating system files and staging directories are managed by the TrustedInstaller security principal. When System Restore attempts to replace core system components using the SYSTEM security context, ownership mismatches between TrustedInstaller and SYSTEM cause permission denial errors (0x80070005).

Diagnostic Verification:

Check ownership of locked target files using icacls <filepath> in an elevated command prompt.

Step-by-Step Fix:

1Restore TrustedInstaller Ownership:

Open an elevated Command Prompt.

Run icacls <target_path> /setowner "NT SERVICE\\TrustedInstaller" for affected system binaries.

2Grant Explicit SYSTEM Access:

Run icacls <target_path> /grant "NT AUTHORITY\\SYSTEM:(OI)(CI)F".

3Initiate Restore:

Run rstrui.exe to execute the system rollback with verified access descriptors.

Prevention & Long-Term Monitoring:

Ensure standard system maintenance utilities retain default Windows service security principals.

Solution:

Root Cause: Third-Party Backup Utility ACL Inheritance Overwrites

Third-party backup and disk imaging software often modify folder and file inheritance settings across the operating system drive during snapshot creation or file-level replication, inadvertently blocking Windows native restore operations.

Diagnostic Verification:

Inspect folder properties in File Explorer for broken inheritance markers on system directories.

Step-by-Step Fix:

1Re-enable Inheritance on System Folders:

Open File Explorer, right-click C:\\Windows, and select Properties -> Security -> Advanced.

Click 'Enable inheritance' if inheritance has been disabled.

2Apply Permissions to Child Objects:

Check 'Replace all child object permission entries with inheritable permission entries from this object' and click Apply.

3Run System File Checker:

Open an elevated Command Prompt and execute sfc /scannow to repair any underlying permission anomalies.

Prevention & Long-Term Monitoring:

Verify that backup software settings do not alter default Windows directory security descriptors.

Solution:

Root Cause: Safe Mode Persistence of Conflicting Security Drivers

In certain configurations, aggressive security software installs boot-start drivers (SERVICE_BOOT_START) that load even during Safe Mode initialization, continuing to block system recovery tasks and triggering error 0x80070005.

Diagnostic Verification:

Run sc query type= driver state= active in Safe Mode and check for active third-party security drivers.

Step-by-Step Fix:

1Disable Boot-Start Security Drivers:

Open an elevated Command Prompt in Safe Mode.

Run sc config <DriverName> start= disabled for the conflicting security driver.

2Restart and Restore:

Reboot the system into normal mode (or clean boot) and run rstrui.exe.

3Re-enable Driver:

Once restore completes successfully, re-enable the driver using sc config <DriverName> start= demand if necessary.

Prevention & Long-Term Monitoring:

Keep security suite drivers updated to prevent persistent boot-start locking behaviors.

Solution:

Root Cause: WinRE Environment Missing Storage Controller Drivers

When attempting recovery from the Windows Recovery Environment (WinRE), missing storage controller or BitLocker volume drivers prevent the restore engine from accessing encrypted restore point containers, leading to access failure codes.

Diagnostic Verification:

In WinRE Command Prompt, run manage-bde -status to check drive encryption states and mounting accessibility.

Step-by-Step Fix:

1Unlock BitLocker Volume Manually:

In WinRE command prompt, run manage-bde -unlock C: -RecoveryPassword <Your48DigitRecoveryKey>.

2Inject Storage Drivers:

If drives are not detected, mount the WinRE image (winre.wim) and use DISM to inject necessary storage controller drivers (dism /image:C:\\mount /add-driver /driver:path\\to\\driver.inf).

3Execute System Restore:

Launch rstrui.exe once the volume is fully accessible and unlocked.

Prevention & Long-Term Monitoring:

Keep recovery media updated with current motherboard chipset and storage drivers.

Solution:

Root Cause: Corrupted VSS Catalog Metadata in Recovery Environment

Recovery environment instances may fail to read restore point catalogs due to corrupted shadow copy metadata stores or permission restrictions on shadow storage associations.

Diagnostic Verification:

Run vssadmin list shadows in an elevated prompt to check shadow storage integrity and presence.

Step-by-Step Fix:

1Resize Shadow Storage Allocation:

Run vssadmin resize shadowstorage /for=C: /on=C: /maxsize=15% to reallocate shadow storage space.

2Clear Corrupt Metadata:

Delete old corrupted shadows using vssadmin delete shadows /for=C: /oldest.

3Retry Restore Point Selection:

Launch rstrui.exe to verify that valid restore points are now recognized.

Prevention & Long-Term Monitoring:

Allocate adequate shadow storage space (at least 10-15% of total drive capacity) for reliable restore point retention.

Solution:

Root Cause: WinRE Subsystem Account Permission Restriction

Executing rstrui.exe directly within WinRE can occasionally fail due to temporary account privilege tokens not possessing full access to system hives mounted from external system paths.

Diagnostic Verification:

Check the current user identity in WinRE command prompt by running whoami to ensure SYSTEM level execution.

Step-by-Step Fix:

1Elevate WinRE Command Prompt:

Ensure you launch Command Prompt from WinRE via Troubleshoot -> Advanced options -> Command Prompt while logged in with an administrator account.

2Set Target OS Path Explicitly:

Run rstrui.exe /offline:C:\\Windows=0 to target the offline operating system directory correctly.

3Complete Restoration Wizard:

Follow the graphical wizard prompts to finalize the system rollback.

Prevention & Long-Term Monitoring:

Verify administrative credentials before initiating offline recovery procedures.

Solution:

Root Cause: Volume Shadow Copy Service Permission Failure

The Volume Shadow Copy Service (VSS) lacks necessary COM+ security permissions to execute snapshot creation and restoration tasks under the Local System or Network Service accounts.

Diagnostic Verification:

Open Component Services (dcomcnfg) via Win + R, navigate to Computers -> My Computer -> DCOM Config, and check permissions for Volume Shadow Copy Server.

Step-by-Step Fix:

1Reset COM+ Security Permissions:

Open dcomcnfg, expand Component Services -> Computers -> My Computer.

Right-click My Computer and select Properties -> Default Properties tab.

Ensure Default Access Permissions and Default Launch Permissions include SYSTEM and Administrators with Full Control.

2Restart VSS Service:

Open PowerShell as Administrator and run Restart-Service VSS.

3Verify Status:

Run vssadmin list writers to confirm all writers are in a stable, non-failed state.

Prevention & Long-Term Monitoring:

Avoid modifying default DCOM and COM+ security settings across system components.

Solution:

Root Cause: Software Protection Service (sppsvc) Access Restriction

The Software Protection Service (sppsvc), which manages digital licenses and interfaces with System Restore verification checks, fails with error 0x80070005 due to missing Network Service account permissions on its registry keys and token stores.

Diagnostic Verification:

Check Event Viewer for Application log errors referencing Service Control Manager failing to start sppsvc with access denied.

Step-by-Step Fix:

1Grant Permissions to sppsvc Registry Keys:

Open Registry Editor (regedit) and navigate to HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\ProtectedStorage or SoftwareProtectionPlatform.

Right-click and grant FULL CONTROL to NETWORK SERVICE.

2Restart Software Protection Service:

Open an elevated Command Prompt and run net start sppsvc.

3Retry Restoration:

Initiate System Restore via rstrui.exe.

Prevention & Long-Term Monitoring:

Ensure built-in service accounts retain default access permissions to core licensing and protection registry hives.

Solution:

Root Cause: COM+ Event System & DTC Access Denied

System Restore relies on the COM+ Event System and Distributed Transaction Coordinator (DTC) to coordinate transaction rollbacks. Permission corruption in these subsystems causes immediate access denied aborts.

Diagnostic Verification:

Open services.msc and verify that COM+ Event System and MSDTC are running and set to Automatic startup.

Step-by-Step Fix:

1Re-register COM+ and VSS Components:

Open an elevated Command Prompt and run the following registration commands:

regsvr32 /s ole32.dll

regsvr32 /s vss_ps.dll

vssvc /register

2Restart Services:

Restart both COM+ Event System and Volume Shadow Copy services.

3Execute System Restore:

Run rstrui.exe to verify successful subsystem coordination.

Prevention & Long-Term Monitoring:

Perform periodic system file checks using sfc /scannow to maintain component registration integrity.

Solution:

Root Cause: Shadow Storage Quota Restriction and Access Denied

When shadow storage space is improperly configured or restricted by group policy quotas, the system cannot allocate temporary space for restore staging, resulting in write permission faults.

Diagnostic Verification:

Run vssadmin list shadowstorage in an elevated Command Prompt to review allocated versus maximum shadow storage space.

Step-by-Step Fix:

1Expand Shadow Storage Quota:

Open an elevated Command Prompt.

Run vssadmin resize shadowstorage /for=C: /on=C: /maxsize=20GB (adjust size as needed).

2Clear Outdated Snapshots:

Delete stale shadow copies using vssadmin delete shadows /for=C: /all.

3Recreate Restore Point:

Create a fresh manual restore point using PowerShell: Checkpoint-Computer -Description "Clean Restore Point" -RestorePointType MODIFY_SETTINGS.

Prevention & Long-Term Monitoring:

Monitor disk space utilization and maintain adequate shadow storage allocation to prevent quota exhaustion.

Related Diagnostic Guides

Windows Update Error 0x80070002 Missing Files Diagnostic Guide

Windows Photo Viewer Not Showing Thumbnails: Codec Diagnostic

Safe Mode Password Not Working With Microsoft Account Fix

Clipboard History Not Working Windows 11: Sync Service Tree

Windows Shows Wrong Time After Reboot Despite Sync Enabled

Subscribe to StepDiag

Embed Guide on Your Website