>>Do you have a reliable repro for the problem, or is it intermittent?
>>
>>If the former, maybe the contents of one or more of the files you're zipping is causing problems. In that case you can use a binary-style search to narrow it down quickly i.e. try zipping half the files, if still bad try zipping half of those etc.
>>
>>If it's intermittent - is there any chance that two WZZip instances could be running simultaneously? Some zip utilities create temp files. If the temp file names are not unique you could get a collision if two instances run at the same time.
>>
>>Another possibility might be if you're making successive calls to WZZip back-to-back. WZZip may report that it has completed, and behind the scenes instructed the file system to delete temp file(s), but the file system may not have finished deleting temp files from the last run before the next one starts. ISTR in some cases zip utility temp files can be large, up to twice the uncompressed size of the files you're zipping. So, it could take a while to delete large temp file(s).
>>
>>Finally, if temp files get large, could you be hitting disk space limitations, or space quotas that may have been set?
>
>When being executed from the .NET Process class, there seems to be a problem with the CRC32 or something like that this utility is doing. As, when adding a duplicate file in the file list to be zipped (same file under a different file name), in this case a JPG file, this was causing the issue. I simulated that everytime. Once the non necessary file removed from the list, all is ok. This happens only from the .NET Process class. If from the CMD window, this works. The command being executed is simply a cut and paste in the CMD window and in the .NET environment.

Shooting in the dark: What happens if the WinZip command is not worked directly from Dotnet,
but written into a .Bat file, which in turn is called from Dotnet, perhaps after and before REM/Echo commands?

Even further going on a limb:

- Have you tried a forced wait before the Dotnet call is made ?
- Have you tried pruning the file list of files with identical file size, 
  adding the files, which are non-filesizedistinct to a second, third and so on command line, 
  which will be ***added*** to zip from preivious command line if it exists ?
- had the copied file causing the error in Dotnet identical time info as well
  or would a "touch" altering this info allow the Dotnet process to work in 1 shot ?

>We'll run more tests on Monday. But, so far, this was a direct cause to the situation we had today.

IAC add a logging module call to be written out before every zip call,
so that each failing dotnet-command line can be tested again under dotnet
and in the command line, if you have not done so already.

regards

thomas