Corrupt zip archives

Mar 30, 2012 at 3:44 PM

Just downloaded the latest version this morning and, though no errors are reported during the backup, the resulting zip archives are corrupt. I've tried outputting to a local drive and a UNC share - same result.

Mar 30, 2012 at 3:51 PM


did you try to open and test the zip file with 7-Zip? The Zip archiving tool integrated in Windows explorer sometimes has issues with the x64 zip format. What's the size of the zip file?

HVBackup is using DotNetZip to handle the zip archiving. In our tests we didn't find problems, but we can switch anytime to a different archiving library in case of issues. 

Mar 30, 2012 at 3:59 PM
Edited Mar 30, 2012 at 4:08 PM

Hi alexp,

I tried extracting the zip with Windows builtin extractor and with Total Commander 7.57a - same for both, corrupt.

I just tried 7-Zip and they're both still corrupt. One is 19GB and the other 13GB.

Edit: both show the vsv as being corrupt. vhd's and other files appear to be ok.

Mar 30, 2012 at 4:27 PM

I looked on DotNetZip's forums for issues related to corruption and I found a possible cause related to parallelism. 

Here's an updated TitanHVBackup.dll. Can you please replace it in the directory where you downloaded HVBackup and retry?




Mar 30, 2012 at 4:35 PM

Hmm, now I get an error:

Error: Specified argument was out of the range of valid values.
Parameter name: ParallelDeflateThreshold should be -1, 0, or > 65536
   at Ionic.Zip.ZipFile.set_ParallelDeflateThreshold(Int64 value)
   at Cloudbase.Titan.HyperV.Backup.BackupManager.BackupFiles(String backupOutputPath, String ba
ckupOutputFormat, IList`1 components, IDictionary`2 volumeMap, IDictionary`2 snapshotVolumeMap,
IDictionary`2 vmNamesMap)
   at Cloudbase.Titan.HyperV.Backup.BackupManager.BackupSubset(IDictionary`2 vmNamesMapSubset, S
tring backupOutputPath, String backupOutputFormat)
   at Cloudbase.Titan.HyperV.Backup.BackupManager.VSSBackup(IEnumerable`1 vmNames, VMNameType na
meType, String backupOutputPath, String backupOutputFormat, Boolean singleSnapshot)
   at Cloudbase.Titan.HyperV.Backup.CLI.Program.Main(String[] args) in c:\Devel\HyperVBackup\Hyp
erVBackupApp\Program.cs:line 131

Mar 30, 2012 at 4:40 PM

Ops, magics of beta testing on the fly :-)

I corrected the parameter value.

Thanks for helping in debugging this issue.

Mar 30, 2012 at 5:01 PM
Edited Mar 30, 2012 at 5:03 PM

Cool & glad to help.

Error is gone, backup is in progress... though it seems to be running a LOT slower than earlier... I wonder if the earlier crash put VSS in a strange state?

Will report back when the backup is complete.

Mar 30, 2012 at 5:12 PM

Yep, we just disabled parallel compression. We are now using only one thread to do the work. 

Mar 30, 2012 at 5:47 PM
Edited Mar 30, 2012 at 5:49 PM

That seems to have worked. The zip files are now valid!

Should I be concerned about the previous crash? I see when a backup is complete, there is a "Deleting snapshot set" afterwards. When it crashed before, that never happened - could something be left in a bad state as a result?

vssadmin shows all are [1] Stable, but that's about the extent of my knowledge of VSS...

Mar 30, 2012 at 5:56 PM
Edited Mar 30, 2012 at 5:57 PM

Thanks for helping! I'm going to update the release right now.


HVBackup deletes any pending snapshot on exit, even in case of exceptions. There's also a Ctrl+C handler to be sure to execute it even in case of explicit kills.

Beside that, unlike Diskshadow, HVBackup does voltatile (non persistent) snapshots.


You can also always use diskshadow to delete any snapshot left behind:

DISKSHADOW> delete shadows all


Mar 30, 2012 at 6:07 PM

I used the diskshadow util (I didn't know about that util) and it shows no shadow copies - everything looks ok from the previous crash.

Thank you for fixing it so quickly! HVBackup fills a long-empty void for Hyper-V backups.