I'm using the very latest release of 7-zip to compress some files from the command line on my Windows XP machine.

All the small archives work fine... but the bigger ones... always give "invalid or corrupted" messages.

I have to compress from the commmand-line (7-zip)... and I have to produce zip files that can be uncompressed with the standard unzip that's built into Windows XP. (NOT forcing all my users/customers to get 7-zip.... or anything else... just to compress these files.)

All the invalid/corrupted zip files seem to have this in common:

They are big (>7gb). (The files inside are about 600mb each)

They are compressed with a basic "a" option using 7-zip

They are trying to be uncompressed with Windows XP's standard unzipper

They all test 100% ok with 7-zip's "-test" or "-list" options

Any ideas? Maybe 7-zip is using some "big file" or "high compression" algorithm, that I need to avoid? (But the "-m" option is a nightmare to figure out.)

I don't need to "fix/repair" these "corrupted" (but actually fine) zip files. I just need a way to get FUTURE files compressed with 7-zip... that can be later safely uncompressed with a basic Windows XP machine.

  • Have you tried Info-ZIP yet? Jul 18, 2011 at 20:34
  • I am having some trouble opening large ZIP files in C#, even though they are compressed with DEFLATE, and open flawlessly in (Windows 8.1) Explorer and 7zip. zipinfo shows no issues. Did you ever find out what the issue was caused by, and is there a chance the same limitation that was still in Windows XP's Explorer code, but not in that of more recent Windows versions, is still in the .NET code for unzipping? Sep 11, 2017 at 8:59

2 Answers 2


7-ZIP has an option to make SFX archives, this allows you to compress with 7-ZIP and makes the archive an executable(exe) file. The Windows user just needs to double click the exe and select a location to extract the contents.

Also about your problem with corrupted archives, the only workaround that would come to mind is to split all the archives then have a sort of "bootstrap" to execute extraction of the first part which in turn will extract the other parts, I would only consider this if it was worth the effort to do this.

  • This was a great answer to the question. The problem is likely a 2GB or 4GB limitation. The other alternative would be to split up the data into multiple smaller ZIP files, by either compressing fewer files or splitting the large input file (before zipping), and including a batch file to use the COPY/B command to re-combine after extracting.
    – TOOGAM
    Nov 2, 2019 at 6:31

You only specified "XP", you haven't told us Service Pack level or which file system you're using ... (never assume)

You mention that the archive files are >7GB; is it possible that you're running into some filesystem limitations?

Have you tried using the -v (create volumes) switch?

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .