>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.

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