Volume Shadow Copy Service errors from backups using Windows Task Scheduler

edited August 31 in AOMEI Products Support
There are numerous 'Volume Shadow Copy Service' errors from a full backup and the first incremental backup.

Event Viewer at the times specified of the backups coincide with the errors logged.
The schedule settings in Backupper are invoked to "Don't install this service, directly use Windows Task Scheduler to run scheduled tasks" 

The errors are the result of the third party backup application AOEMEI Backupper. 
Errors repeat themselves numerous times again and again.  
The logged event are:   

Volume Shadow Copy Service error: Unexpected error calling routine CoCreateInstance. hr=0x8007045b, a system shutdown is in progress

Volume Shadow Copy Service Information: The COM server with CLSID{.....} and name CEventSystem cannot be started [0x8007045b, a system shutdown is in progress]

Volume Shadow Copy Service error: Unexpected error querying for the IVssWriterCallback interface hr=0x80070005, access is denied
This is often caused by incorrect security settings in either the writer or requestor process.

In the third error (above), Backupper should be responsible for properly handling the security context of COM callbacks from VSS. It looks like Backupper is not allowing system writer to call back into their process.
 
The security options in Task Scheduler appear to be set correct (refer to attached screen shots) 
Its not clear as to the message logged in Task Scheduler: "The operator or Administrator has refused the request 0x800710E0"


 






Volume Shadow Copy in Services is enabled (manual):

Tagged:

Comments

  • Hi Ariel,
    Thanks for your feedback. Does the Backup generate successfully? 
    Generally, if AOMEI Backupper calls Vss failed, it will switch to AOMEI Service to back up.
  • edited September 1
    Yes. the backups generate successully, 
    but if I have Windows Task Scheduler To Run Scheduled Tasks selected in Backupper, are you telling me this is an issue or this is not an issue where Backupper automatically switches to AOMEI service at every backup in the (Standard version)?

    If this is going to happen with every backup as long as I have Windows Task Scheduler selected, is there a workaround to correct this so that when I have Windows Task Scheduler To Run Scheduled Tasks selected in Backupper, a dozen error events do not become created at every backup ?  
  • @Ariel, it seems that it is the error of Windows Task Scheduler.
    Could you check if other schedule tasks in the Task Scheduler have the same error when they run?

  • edited September 5

    The times specified when AOMEI backups ran coincide with when the VSS errors logged in Event Viewer.
    VSS events logged at 7:15 p.m. Sunday, starting 08/30/2020. They continued for several more hours after the backups, up to 9:16 p.m.Sunday 08/30/2020

    Here are the complete list of scheduled tasks and when they run in Task Scheduler:
    As you can see, no other schedule tasks are run when AOMEI ran.
    No other scheduled task ran after AOMEI until NVIDIA Tm Rep_Crash Report ran at 12:25 a.m.
    By the time NVIDIA ran, all VSS events had ended  
    There were no VSS events logged at the times when all other scheduled tasks triggered    


    Adobe Acrobat                      Daily @ 10:00 a.m  and @ log on
    AOMEI DATA                        Weekly @ 7:15 p.m.every Sunday of the week, starting 08/30/2020 
    Intel Update Manager           Daily @ 5:14 p.m.
    MS Edge Update Task...       Daily @ 8:22 a.m.   and @log on
    NVIDIA battery Boost...                                               @log on
    NVIDIA Driver Update...        Daily @12:25 p.m.
    NVIDIA Node Launcher                                               @log on
    NVIDIA Profile Updater         Daily @12:25 p.m.  and @ log on
    NVIDIA Tm Rep_Crash Re.. Daily @6:25 p.m.
    NVIDIA Tm Rep_Crash Re.. Daily @12:25 a.m. 
    User Feed Synchronization   Daily @ 3:20 p.m.
     



  • For the IVssWriterCallback error, try solution 2 at https://www.ryadel.com/en/volume-shadow-copy-service-error-unexpected-error-querying-for-the-ivsswritercallback-interface-how-to-fix-that/ .  We saw this a lot at work and the permissions change fixed it.

    For the CEventSystem error, try stopping cryptsvc (Cryptographic Services) during the backup.  I'm less certain about this, but I've seen this suggested.  I've also seen claims that this will be fixed by the Win/10 2004 feature update.

    We saw the CoCreateInstance error a few times, but I think it went away without us doing anything.
  • edited September 7
    @Wssddc,

    Thank you for your attached link and input on how you resolved these errors at work

    In regard to the IVssWriterCallback error:

    Solution 1: Registry Settings, suggest on the ryadel page to first try setting VSS to Automatic. The issues with changing the default (manual) setting in services.msc can leave several less desirable results. 

    If changed to Auto:   

    1.)   Windows will create a shadow copy every day or so. I'd have to resort to deleting shadow copies quite often to save hard disk space 

    2.)   The antivirus program, in this case Windows Defender, would scan the shadow copy (the same items again) it already scanned for viruses

    3.)   I back up and maintain everything manually on an external hard drive. The primary (C:\) drive is for programs only, Hence, I have no data to loose.

    Solution 1 also suggests changing the registry for VSSAccessControl to resolve the IVssWriterCallback error. I have doubt about why it should be necessary to make a registry change to resolve an incorrect security setting in either the writer or requestor process.

     

    Solution 2: COM Security Settings, suggest granting to SYSTEM local access permission. I found this suggestion on another site, however, after carefully reading the steps as worded on ryadel.com it says:  ”add the SYSTEM and Network Service users (if not already there).” In Windows Component Services on my machine, under Access Permissions, Network Service is not listed, only SYSTEM is listed. I have doubt on the reason to add Network Service to resolve an incorrect security setting mentioned as often being the cause for the VSS writer Callback error.

     

    In regard to the CEventSystem error:

    Your comment sounding less certain to resolve this error by stopping Cryptographic Services during the backup had led me to (assume), this change performed at work is necessary 'each time' during a backup, or am I misinterpreting this?

    I updated to Win 10, Version 2004 three months ago.    


    This is a list of troubleshooting solutions I recently found.  https://www.tweaking.com/articles/pages/microsoft_volume_shadow_copy_(vss)_troubleshooting,1.html

    Although not all solutions are relevant for Windows 10 Home, some even are dated as far back to Win XP. However,  solutions #2, #3, #5, #6, #7 have been tried but to no avail toward resolving the VSS errors. 
       
  • Regarding IVssWriterCallback errors and com security settings, we did have to add network service; it wasn't there by default.  I don't understand why, but giving rights here did help.
  • @Ariel, As for the error, we can only find these solutions you had tried from the Internet. The error is not caused by our program directly. Our technician can't solve it further. Maybe you can try to use AOMEI Service to perform backup.
  • edited September 8
    @admin, as for the CoCreateInstance and CEventSystem errors, chances may be these two are not a result. But as for the IVSSWriter Callback errors, I don't believe the claim Backupper not being the cause of that error, leaving two options - either to add network service to access permission, or use the AOMEI service.            
  • @Ariel, As for the IVSSWriter Callback errors, it might that AOMEI Backupper call  Vss service failed due to unknown reasons. When calling Vss failed, AOMEI Backupper will switch to AOMEI Service to complete backup.
    As for "The operator or Administrator has refused the request 0x800710E0" , it seems that it is not caused by our program directly. We can't know the reason for the error. 
Sign In or Register to comment.