Getting Past VSS Error 80042316 from DriveImage XML

I’m using Runtime Software’s free DriveImage XML to back up several XP machines over a network to Windows 2003 server. Scheduled tasks run DriveImage XML in command-line mode and are set to
try VSS before drive locking. Another scheduled task collects logs and emails them to me.

Today I noticed that one of the backups did not complete. When I tried to run the backup interactively, DriveImage XML told me that it “Could not initialize Windows Volume Shadow Copy Service (VSS)” and that the error code was 80042316. The Volume Shadow Copy service was running. I tried stopping and starting the service and re-running the backup, but it still could not proceed.

Some Google research turned up the meaning of 80042316 as “another snapshot creation is in progress. Please retry later your snapshot creation.” However to the best of my knowledge there are no other backups or other VSS-aware processes running. 

I thought perhaps the recent change from Trend CS 3.6 to NOD 32 2.7 might have caused a problem, but DriveImage XML completed fine on several other machines running NOD32.

Finally I remembered that there is a command-line utility to look into VSS on a machine. I typed

vssadmin list shadows

at a command prompt and it showed that there is a shadow copy on some kind of virtual volume (\\?\Volume{2eb5f062-fd3d-11d8-8bb5-806d6172696f}\). Stopping and starting the Volume Shadow Copy service did not remove the shadow copy.

Maybe this is a remnant from an old backup? I don’t know how to directly delete shadow copies under Windows XP, but let’s see if a reboot helps…

Bingo! After the reboot, the “vssadmin list shadows” command showed “No shadow copies present in the system,” and DriveImage XML was able to create a new shadow copy and do the backup.

Not Fixed

Alas, when DriveImage XML completed and exited, I still had a volume shadow copy on the volume, and the next time I ran DriveImage XML, it  gave me the same message but a slightly different error code:  80042317. Google isn’t so helpful in finding a description for 80042317. But rebooting the machine again killed the shadow copy and let DriveImage XML run, so I’m assuming it’s the same issue.

Bummer! So why can’t DriveImage XML release/delete its shadow copies on this machine? The Microsoft storage team lists three recommended hotfixes for VSS in this blog entry, but they are all for Windows Server 2003, not XP.

Excluding the C:\System Volume Information folder (where volume shadow copies are stored, I believe) from NOD32 didn’t help.

Excluding dixml.exe (the DriveImage XML executable) from NOD32 didn’t help.

I’ll update this if I find a solution (other than rebooting the machine after every backup!). 

8 thoughts on “Getting Past VSS Error 80042316 from DriveImage XML

  1. Mark Berry

    Still no solution on this one. I only have this problem on one of about nine machines. It’s a low-priority machine, so I can’t spend much time on it. I just reboot it every few weeks to make sure the DriveImage XML backup is relatively recent.

  2. Paul

    I had this problem too. Found a shadow was active – how strange!

    Played with msconfig and found a service “SQL Server VSS Writer”. I disabled this and everything now works great.

    Hope this helps you too.

    Paul. :-)

  3. Mark Berry

    Thanks Paul. Good idea! Unfortunately, this machine doesn’t have that VSS writer installed. When I type

    vssadmin list writers

    at a command prompt, I see Microsoft Writer (Service State), MSDEWriter, Microsoft Writer (Bootable State), and WMI Writer. That the exact list of writers that I see on another workstation that is not experiencing this problem.

  4. Roel Broersma

    I’ve experiences a lot of problems with DriveImageXML and am now thinking about chaning to Paragon (although it costs some money).

    However, i found out that:
    – You need to STOP any SQL (Desktop) Engines, otherwise it won’t work, try: net stop mssql
    – Try deleting: HKREY_LOCAL_MACHINESoftwareMicrosoftEventSystem{xxxx}Subscriptions key (don’t worry, it will be added automatically again… these keys in here are all created-shado actions). On X64 systems it’s: HKEY_LOCAL_MACHINESoftwareWow6432NodeMicrosoftEventSystem{xxxx}Subscriptions

    Good luck !

    Roel Broersma

  5. Mark Berry

    Roel – Thanks very much, that seems to have worked! What I did:

    1. Checked for SQL/MSDE. None found.
    2. Deleted the Subscriptions key that you identified and restarted the computer.
    3. Ran “vssadmin list writers” and saw the Subscriptions key repopulate.
    4. MSDEWriter is still listed as a writer. Could it be from the Backup Exec Remote Agent? I’m no longer using that, so uninstall it and reboot the computer.
    5. “vssadmin list writers” still shows the MSDEWriter. Checked another “bare bones” WinXP SP3 machine, and even on that empty machine, the MSDEWriter is installed. It must be part of the default installation.
    6. Re-ran my DriveImage XML job. Did NOT reboot.
    7. “vssadmin list shadows” now says “No shadow copies present in the system”! Hooray!

    Hopefully that clears up this problem.

    A helpful thread on the Subscriptions key:

    By the way, DriveImage XML has been updated and now lists Vista support. Commercial use will cost, though: So far I’m still using the previous free-for-all-uses version.

  6. tommy

    Run services.msc. Go to service Volume Shadow Copy. STOP it. Then use your program, and it should work fine.

  7. Mark Berry Post author

    Tommy, the point of doing an image backup with VSS is to be able to back up files that are in use, so the machine could be restored completely e.g. if the hard drive dies . Stopping VSS might allow the backup to complete but it would be incomplete.

  8. Kevin Carney

    I’m having this issue on Windows 7 32bit as well. Tried all above suggestions but have been forced to run DriveImageXML in an XP vm

Leave a Reply

Your email address will not be published. Required fields are marked *

Notify me of followup comments via e-mail. You can also subscribe without commenting.

This site uses Akismet to reduce spam. Learn how your comment data is processed.