Repairing the Volume Shadow Copy Service (VSS)

 

The errors history

 

  1. I was constantly getting the following error with certain profiles where the VSS was required to copy open files, showing that VV could not locate the shadow copy:

2016-03-31 10:16:38 : Creating shadow set {e14de76d-9f91-41ea-9b25-b63e3a061a96} ...
2016-03-31 10:16:38 : Adding volume \\?\Volume{8d8abd46-67a2-11e4-bef7-00241dc239ef}\ [Z:\] to the shadow set...
2016-03-31 10:16:40 : Creating the Volume Shadow Copy...
2016-03-31 10:16:45 : Volume Shadow Copy successfully created.
2016-03-31 10:16:56 : Done. Volume Shadow Copy is at
2016-03-31 10:16:56 : Copying file Z:\J drive\autoarchive\Autoarchive.pst <to> V:\Clones of Z\Z1 to V\J\autoarchive\Autoarchive.pst (9.95MB) (Overwriting) ... [Can not open "\J drive\autoarchive\Autoarchive.pst". The system cannot find the path specified.] [ERROR].
2016-03-31 10:16:56 : Copying file Z:\J drive\current\CURRENT.pst <to> V:\Clones of Z\Z1 to V\J\current\CURRENT.pst (2.39GB) (Overwriting) ... [Can not open "\J drive\current\CURRENT.pst". The system cannot find the path specified.] [ERROR].
2016-03-31 10:16:56 : Copying file Z:\J drive\current\PKI EMAIL.pst <to> V:\Clones of Z\Z1 to V\J\current\PKI EMAIL.pst (347.56MB) (Overwriting) ... [Can not open "\J drive\current\PKI EMAIL.pst". The system cannot find the path specified.] [ERROR].

 

 

  1. I was constantly getting the following error in the VV logs with certain profiles where the VSS was required to copy open files, suggesting that even when the shadow could be located by VV, VV was having difficulty reading it:

2016-03-22 05:07:30 : Done. Volume Shadow Copy is at \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1
2016-03-22 05:07:30 : Copying file Z:\D drive\dtSearch files\autoarchive\history.ix <to> V:\Clones of Z\Z0 to V\D drive\dtSearch files\autoarchive\history.ix (184.72KB) (Overwriting) ... [Can not open "\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\D drive\dtSearch files\autoarchive\history.ix". The system cannot find the path specified.] [ERROR].
2016-03-22 05:07:30 : Copying file Z:\D drive\dtSearch files\autoarchive\index_d_1.ix <to> V:\Clones of Z\Z0 to V\D drive\dtSearch files\autoarchive\index_d_1.ix (128.00KB) (Overwriting) ... [Can not open "\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\D drive\dtSearch files\autoarchive\index_d_1.ix". The system cannot find the path specified.] [ERROR].
2016-03-22 05:07:30 : Copying file Z:\D drive\dtSearch files\autoarchive\index_i_50.ix <to> V:\Clones of Z\Z0 to V\D drive\dtSearch files\autoarchive\index_i_50.ix (7.40KB) [Can not open "\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\D drive\dtSearch files\autoarchive\index_i_50.ix". The system cannot find the path specified.] [ERROR].
[and several other file paths that could not be copied, apparently for the same reason - the system cannot find the path specified]

 

 

  1. After fixing the above issues with fixes numbered 1 to 3 below, I was still getting the following errors:

2016-05-07 11:18:44 : Creating shadow set {a091b628-25e6-445d-be3a-8dbc90c386a3} ...
2016-05-07 11:18:44 : Adding volume \\?\Volume{8d8abd46-67a2-11e4-bef7-00241dc239ef}\ [Z:\] to the shadow set...
2016-05-07 11:18:47 : Creating the Volume Shadow Copy...
2016-05-07 11:18:49 : Error during the last asynchronous operation.
2016-05-07 11:18:49 : - Returned HRESULT = 0x80042306
2016-05-07 11:18:49 : - Error text: VSS_E_PROVIDER_VETO [Volume Shadow Copy creation failed for Z:\. E_UNEXPECTED]
2016-05-07 11:18:49 : [Volume Shadow Copy creation failed for Z:\. E_UNEXPECTED] Error.

 

It is not clear whether this was fixed by fix no 4 below, but in any case VV was still unable to synchronise open .pst files until I adopted fix no 5 below.

 

The fixes

 

The process included:

  1. Reinstalling the VSS in the COM+ Applications
  2. During the course of reinstalling the VSS, repairing the COM+ Catalogue
  3. Re-registering the VSS components
  4. Deleting and rebuilding HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\EventSystem\{26c409cc-ae86-11d1-b616-00805fc79216}\Subscriptions
  5. Uninstalling AJSOpenFileManager and running registry cleaner

 

The above stages in the process were carried out in the order mentioned above, although the instructions for rebuilding the registry key contemplate re-registering the components after doing so if necessary.

 

My computer diary notes dated 1 and 7 May 2016 refer to the repair process.

 

It may take a couple of reboots, or at least more than one reboot, to get the VSS working again properly after the above procedures have been carried out.

 

 

  1. Reinstalling the VSS in the COM+ Applications

 

The re-installation of the VSS was done on 1 May following the instructions at www.pcreview.co.uk/threads/swprv-dll-register-failed-solution.3290037/

 

Those instructions are:

 

I found that I was not alone with the above problem when trying to

re-install the Volume Shadow Copy Service. There were many articles with

instruction on how to re-install / repair it, however they all said

essentially the same thing and I noticed that many people were having

trouble getting swprv.dll to register during the process.

 

Unfortunately, there was no working solution offered by anyone to this

problem, other than to re-install windows. I WILL NOW DESCRIBE THE SOLUTION

THAT WORKED FOR ME!!

 

(this solution was used in XP - not sure about other OS's)

 

1) Launch the Component Services window, which is under Administrative tools.

 

2) Expand Component Services > Computers > My Computer > COM+ Applications

 

3) In there locate the item called "MS Software Shadow Copy Provider" and

right click it, choose 'Export'.  (I elected to export with user permissions)

 

4) On the wizard that opens, click 'Next'.

 

5) type a location eg. c:\MS_shadow_temp and click 'Next'

 

6) Click 'Finish'

 

7) Right click the item called "MS Software Shadow Copy Provider" again but

this time choose 'delete'. If delete is not an option, then choose

'Properties', go to the advanced tab and remove the tick from the box with

says 'Disable deletion'. Then you can delete it after you have pressed 'OK'.

 

8) Delete the following key from the registry:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SwPrv

 

9) Rebuilt the COM+ catalogue using the instruction available commonly

online.

 

10) Restart

 

11) Launch the Component Services window, which is under Administrative

tools.

 

12) Expand Component Services > Computers > My Computer > COM+ Applications

 

13) Right click on 'COM+ Applications' and click 'new' > then 'Application'.

 

14) Click Next on the window that opens, then 'Install pre-built

application'. Click next.

 

15) Browse for the file e.g. c:\MS_shadow_temp.msi

 

16) Complete the wizard (I can't follow beyond this point or I might mess up

my system again).

 

17) Restart your machine.

 

18) run " regsvr32 /i swprv.dll " at the cmd prompt after changing to the

windows/system32 directory (otherwise apparently it fails).

 

19) Restart and you should find it all working. If not, try installing the

COM+ catalogue and restarting again.

 

 

 

  1. Repairing the COM+ Catalogue

 

In May 2016 followed the instructions at: searchwindowsserver.techtarget.com/tip/Repairing-a-damaged-COM-catalog.  There are however more comprehensive instructions at https://support.microsoft.com/en-us/kb/315296, which appear to be the instructions I followed on 090913.

 

The instructions I followed in May 2016 are:

 

The COM+ catalog is a catalog of all the available COM+ applications, classes and attributes on a given system. Windows keeps this catalog to make sure that there's consistency between the various COM+ attributes and exposes it through various programming interfaces. If the catalog becomes damaged, programs that rely on COM+ won't work properly (or at all!).

 

One example of such a service that depends on COM+ is the Volume Shadow Copy Service used by (among other programs) the Microsoft NTBACKUP application. NTBACKUP can make backups of system files or other locked files by using Volume Shadow Copy. However, if NTBACKUP fails with an error in the Volume Shadow Copy COM+ service, odds are the catalog has been damaged and needs to be repaired. (Another symptom of a damaged COM+ catalog is when many programs hang continuously for minutes on end, but this is a minor, less well-documented symptom.)

 

To repair a damaged COM+ catalog, do the following:

 

    Locate the file %WinDir%\System32\Clbcatq.dll and rename it to ~Clbcatq.dll (note the tilde). %Windir% is an environment variable that usually translates to C:\Windows.

    Reboot the computer in Safe Mode.

    Open the Registry and delete the key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\COM3.

    Look in the %WinDir% directory for a subdirectory named Registration. Delete Registration entirely, including any files inside it.

    Reboot the machine normally.

    At a command line, type regsvr32 %windir%\system32\ole32.dll, and click OK on the acknowledgement that comes up.

    Open Control Panel | Add/Remove Programs | Add/Remove Windows Components.

    Click Next to reinstall COM+. You do not need to select any components to add or remove; COM+ is reinstalled automatically as a matter of course.

 

You shouldn't have to reboot after this; the re-registered COM+ services should work immediately.

 

 

  1. Re-registering the VSS components

When I carried out the repair, I re-registered the VSS components before rebuilding the registry key mentioned below.  I do not know whether it is necessary to do that, or whether the registry key can be rebuilt before the VSS components have been re-registered.  The process of re-registering the VSS components is mentioned below.  I used my own .bat file, which re-registered msxml2.dll and msxml6.dll, which do not appear to be part of the VSS according to the instructions on the net.

 

The instructions in my .bat file are:

 

cd /d %windir%\system32

Net stop vss

Net stop swprv

regsvr32 ole32.dll

regsvr32 oleaut32.dll

regsvr32 vss_ps.dll

vssvc /register

regsvr32 /i swprv.dll

regsvr32 /i eventcls.dll

regsvr32 es.dll

regsvr32 stdprov.dll

regsvr32 msxml.dll

regsvr32 msxml2.dll

regsvr32 msxml3.dll

regsvr32 msxml4.dll

regsvr32 msxml6.dll

 

 

  1. Re-building the subscriptions registry key

 

I followed advice at advice at:

www.procompgroup.com/library/entry/how-to_repair_vss_on_2003_xp/

 

That advice is:

 

Run Regedit, back up and then delete this key:

    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\EventSystem\{26c409cc-ae86-11d1-b616-00805fc79216}\Subscriptions

    Restart (or start, then stop) these services:

 

        COM+ Event System

        COM+ System Application

        Microsoft Software Shadow Copy Provider

        Volume Shadow Copy

 

 After doing so, open a command prompt, type “vssadmin list writers”.  If they are listed, you are done.  If they are not, type the following commands (vssui.dll does not work in Windows XP):

 

        cd /d %windir%\system32

        net stop vss

        net stop swprv

        regsvr32 ole32.dll

        regsvr32 oleaut32.dll

        regsvr32 vss_ps.dll

        vssvc /register

        regsvr32 /i swprv.dll

        regsvr32 /i eventcls.dll

        regsvr32 es.dll

        regsvr32 stdprov.dll

        regsvr32 vssui.dll

        regsvr32 msxml.dll

        regsvr32 msxml3.dll

        regsvr32 msxml4.dll

 

    Type “vssadmin list writers” again, confirm that writers are listed and ready.

    Type “vssadmin list shadows” to view existing shadow copies, check for errors.

 

The result of vssadmin list writers on my system is to show 4 writers.

 

Footnote:

 

My final .bat for re-registering the vss components had the following commands:

 

cd /d %windir%\system32

 

Net stop vss

 

Net stop swprv

 

regsvr32 ole32.dll

 

regsvr32 oleaut32.dll

 

regsvr32 vss_ps.dll

 

vssvc /register

 

regsvr32 /i swprv.dll

 

regsvr32 /i eventcls.dll

 

regsvr32 es.dll

 

regsvr32 stdprov.dll

 

regsvr32 msxml.dll

 

regsvr32 msxml2.dll

 

regsvr32 msxml3.dll

 

regsvr32 msxml4.dll

 

regsvr32 msxml6.dll

 

 

Note however the good advice mentioned at www.procompgroup.com/library/entry/how-to_repair_vss_on_2003_xp/ and in my computer diary post, dated 7 May 2016, which suggests that msxml2 and 6 do not need to be re-registered.

 

 

  1. Uninstalling AJSOpenFileManager and running registry cleaner

 

I had been using anther sync program to synchronise the profiles I had been having trouble with, and asked for their comments on an intermittent problem synching open .pst files.  They replied this is VSS error 80042306 and referred me to:
backupassist.com/support/en/knowledgebase/BA904-Volume-Shadow-Copy-Error-0x80042306-provider-veto.html?cshid=BA904

 

Where I found the following:

Volume Shadow Copy Error 0x80042306 - provider veto

Error code

Product

Applies to

BA904

BackupAssist

BackupAssist v4 and later

Description

This error occurs when the Volume Shadow Copy Service (VSS) is unable to run due to another snapshot management provider being installed on the system.

Resolution

The error's known causes and resolutions are described below.

Known Cause 1 - Multiple backup solutions installed

Many backup solutions have their own proprietary snapshot manager which can cause conflicts with other backup solutions installed on the system.

If you have (or had) more than one backup program installed on your system, disable/uninstall all of the programs except for BackupAssist, and run the backup job again.

It is best practice to only have one backup solution installed at any one time.

You should also run a registry cleaner after the other backup solutions have been uninstalled: backupassist.com/blog/support/how-to-resolve-a-ba910-volume-shadow-copy-error-0x80004230/.

Etc.

 

Given that the files I could not copy when open were .pst files, I thought that the AJ Systems open file manager would be a strong candidate for the hypothesis advanced by BackupAssist.  After following the above advice by uninstalling AJSOpenFileManager and running Registry Healer and rebooting, I was able at last to synchronise open .pst files in Altaro and VV without errors.  Evidently, the AJS open file manager was preventing the VSS from doing its job in relation to .pst files.

 

 

Incidental matters

 

It was suggested that VeraCrypt was the cause of the problems with VV and the VSS, since errors apparently related to VeraCrypt volumes were appearing in the Applications section of the Event Viewer.

 

This proved to be false – these errors appear to be harmless, and are characterised by ID 12293 and a statement “Cannot ask provider {00000000-0000-0000-0000-000000000000} if volume is supported. [0x8000ffff] [hr = 0x8000ffff]” or Routine details IVssSnapshotProvider::IsVolumeSupported() failed with 0x8000ffff [hr = 0x8000ffff].  This does not interfere with the VSS or the backup that results.

 

And after a VeraCrypt volume has been mounted and then removed, it leaves another type of error in the Applications section of the event viewer, in the following form:

ID 12289 - Volume Shadow Copy Service error: Unexpected error GetVolumeNameForVolumeMountPointW( \\?\Volume{588bb4c2-1a82-11e6-8333-00241dc239ef}\, ...).  hr = 0x80070003.

This does not interfere with the VSS or the backup that results, and appears to be the VSS response to finding that the VeraCrypt mounted drive is no longer present.  The missing volume is identified by the volume id in the error, and it is not clear why it refers to MountPointW.  It can be cleaned up by running Drivecleanup (by Uwe Sieber) and rebooting.

 

Prior to uninstalling AJSOpenFileManager, but not afterwards, I was also getting errors in the event viewer in the following form:

 

Event Source:  VSS

Event Category:          None

Event ID:          12289

Date:               13/05/2016

Time:               20:01:02

User:                N/A

Computer:       TOM-I7

Description:

Volume Shadow Copy Service error: Unexpected error DeviceIoControl(00000200,0x0053c008,0003A350,0,00039348,4096,[0]).  hr = 0x800705aa.

 

 

ViceVersa PRO can be found at: http://www.tgrmn.com