Unable to create shadow copies (on a specific volume)

Home Forums Server Operating Systems Windows Server 2000 / 2003 / 2003 R2 Unable to create shadow copies (on a specific volume)

This topic contains 4 replies, has 3 voices, and was last updated by Avatar universal 1 year, 8 months ago.

Viewing 5 posts - 1 through 5 (of 5 total)
  • Author
  • Avatar
    Ser Olmy

    I’m experiencing a scenario I’ve seen only too often: On one particular server, VSS is unable to create a shadow copies. My question is: How can I troubleshoot this issue in order to find the underlying cause?

    Some details:

    On the affected Windows 2003 server, the problem is related to one specific volume; a drive with a single NTFS-formatted partition that holds only shared files. For all the other volumes, including the system drive and a drive hosting several MSSQL instances, the shadow copy operation completes successfully.

    As for the affected drive/volume, whether I try to create a shadow copy manually (I’ve installed vshadow.exe) or by using a backup application, the result is always the same: After several minutes, the operation times out with error 0x80042306, “VSS_E_PROVIDER_VETO”. vssadmin list writers shows all writers as “stable”. (Not that it should matter, because no application-specific VSS writers are invoked for this volume as it holds only file data.)

    I’ve tried all the usual suggestions, such as installing OS-specific hotfixes, deleting the Subscriptions subkey under HKLMSOFTWAREMicrosoftEventSystem{26c409cc-ae86-11d1-b616-00805fc79216}, rebooting multiple times etc, but the problem remains.

    Interestingly, the issue appeared after I deleted and reformatted the volume in question, which I did in order to change the partition scheme from Dynamic Disk to MBR, and also to fix a partition alignment issue. I strongly suspect there might be a reference somewhere to the old partition/volume ID, or perhaps to the now-deleted Dynamic Disk metadata, but where?


    Not something I have ever needed to use, but a quick search revealed this article: https://www.backupassist.com/support/en/knowledgebase/BA904-Volume-Shadow-Copy-Error-0x80042306-provider-veto.html


    Thanks, I actually found that article earlier while searching for possible solutions.

    There are quite a number of articles and forum posts about non-functioning VSS out there, and the suggested solutions are usually as follows:

    • Are all VSS writers reported as being in a “stable” state? (yes)
    • Have you tried rebooting? (yes)
    • Is your OS fully patched? (yes)
    • Might there be insufficient free disk space for a Shadow Copy? (no)
    • Is the server experiencing high levels of disk I/O that might interfere with VSS? (no)
    • Do you have multiple backup applications installed? (no)
    • Have you installed VSS-related hotfixes X, Y and Z? (yes)
    • Have you tried deactivating/uninstalling/updating your antivirus solution? (n/a, none is installed)
    • Have you tried deleting the (aforementioned) Event Subscription registry keys and rebooting again? (yes)

    I’ve seen this happening on several systems, running anything from Windows Server 2003 to Windows Server 2012. In some cases, one of the above suggestions will resolve the issue. If not, the suggested “solution” is to reinstall the OS, which will of course “solve” any issue one might have, since it implies causing the affected system to no longer exist.

    Usually, VSS issues are quite pressing, as they prevent backups from running properly or even at all. In this case, however, the server in question is an old VM about to be decommissioned, so I thought for once I’d spend some time trying to get to the bottom of this.


    Sounds like it may be one of those eternal mysteries. But, I hope you get it solved :)


    I have, and although I wasn’t able to definitively identify the cause, I’ve been able to narrow it down to a problem with the filesystem structure.

    What I did, was this:

    1. Powered down the virtual server
    2. Attached the disk containing the affected volume to another, freshly installed W2k3 scratch VM
    3. Created a snapshot of the volume (which succeeded without issue) by starting and then immediately canceling ntbackup
    4. Powered down the scratch VM and started the original VM again
    5. Tried creating a snapshot, which promptly succeeded

    Note that I didn’t do anything specific to change/fix/alter the filesystem structure, no reformatting or chkdsk or defragmentation or anything. I simply attached the disk to another VM, created (and deleted) the snapshot, and then moved the disk back. Obviously, the changes caused by this procedure would be limited to the filesystem of the volume in question.

    I therefore conclude that “something” inside the NTFS structure is responsible for snapshots failing in this particular fashion. Not terribly informative, perhaps, but since the procedure above seems to have actually resolved the issue, I hope this post might be of use for others finding themselves in a similar predicament.

Viewing 5 posts - 1 through 5 (of 5 total)

You must be logged in to reply to this topic.