Here is my diary note of the complete fix. References to VV are to Vice Versa, which is one of the applications in which the VSS problems were showing up.
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Repairing the Volume Shadow Copy Service (VSS)
The errors history
- 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].
- 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]
- 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:
- Reinstalling the VSS in the COM+ Applications
- During the course of reinstalling the VSS, repairing the COM+ Catalogue
- Re-registering the VSS components
- Deleting and rebuilding HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\EventSystem\{26c409cc-ae86-11d1-b616-00805fc79216}\Subscriptions
- 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.
- Reinstalling the VSS in the COM+ Applications
The re-installation of the VSS was done on 1 May following the instructions at
https://www.pcreview.co.uk/threads/swprv-dll-register-failed-solution.3290037/
Those instructions are:
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
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.
- Repairing the COM+ Catalogue
In May 2016 followed the instructions at:
http://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:
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
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.
Xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
- 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
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
- Re-building the subscriptions registry key
I followed advice at advice at
http://www.procompgroup.com/library/entry/how-to_repair_vss_on_2003_xp/.
That advice is:
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
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:
Xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
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
http://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.
- Uninstalling AJSOpenFileManager and running registry cleaner
I had been using GoodSync 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:
https://www.backupassist.com/suppor...ror-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:
https://www.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 GoodSync, 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.
