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!).
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.
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. :-)
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.
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
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:
http://forum.sysinternals.com/forum_posts.asp?TID=13731&KW=newsid&PN=2
By the way, DriveImage XML has been updated and now lists Vista support. Commercial use will cost, though: http://runtime.org/driveimage-xml.htm. So far I’m still using the previous free-for-all-uses version.
Run services.msc. Go to service Volume Shadow Copy. STOP it. Then use your program, and it should work fine.
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.
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