I'm working with two machines.
On Machine1, I create a self-extracting executable, using 7-zip. Machine1 is 32-bit (Windows XP), while Machine2 is a 64-bit Windows-7 machine.

On Machine2, I launch the self-extracting executable.

Sometimes this works, but sometimes this is giving an error message:

This version of <executable> is not compatible with the version of Windows you're running.
Check your computer's system information to see whether you need 
a x86 (32-bit) or x64 (64-bit) version of the program, 
and then contact the software publisher.

On Machine1, the 7-zip version I'm running is 4.52 Beta. I've already tried using latest version 16.04, but this version uses that much memory of my (virtual) Machine1 that it is unusable.

Does anybody have an idea what to do?

  • Did you try extracting the archive in Window XP compatibility mode and set 'run as administrator' ?
    – Overmind
    Jan 9 '17 at 13:57
  • Can you tell me how to do this? In fact, the launching of the self-extracting executable is done within a batch-file. Is there a parameter I can set in the batchfile for working in Windows XP compatibility mode? (I suppose it's not possible to have a parameter which can "run as administrator")
    – Dominique
    Jan 9 '17 at 14:02
  • 1
    There are multiple methods to run it as admin. You can make a shortcut of the .bat file and put the option there, or you can task schedule it with highest privileges or you can make a script to bypass UAC.
    – Overmind
    Jan 11 '17 at 8:11
  • Or you can even convert the .bat to an .exe.
    – Overmind
    Jan 11 '17 at 8:17

System architecture has nothing to do with your problem. There's no reason a 32 bit program shouldn't work in Windows x64.

4.52 beta is like.. what? 10 years old? For god's sake, try some newer version.

And if you even manage to find where this alleged memory "explosion" appeared (hoping it's not just different dictionary default settings).. congratulations, you are ready to fill Igor a nice bug report!


Thanks for the quick replies, but in the meanwhile the real source of the problem has popped up: Machine1 was putting the mentioned file on NAS1, Machine2 was getting the mentioned file on NAS2, and now it seems that the synchronisation between both NASes corrupted the file, resulting in the mentioned error message.

@Mirh, thanks for the URL to Igor's buglist. I'll continue testing the new 7-zip version and in case the memory explosion keeps happening, I'll enter a new bug entry for it.

  • Make sure you don't exaggerate with your compression settings on the old machine.
    – Overmind
    Jan 11 '17 at 8:18
  • Sorry, @Overmind, I don't understand what you mean: are you saying that certain compression settings might cause NAS synchronisation to corrupt files? (for your information, the NASes I'm talking about are Synology ones) I also give you the 7-zip command we are using: "%ProgramFiles%\7-Zip\7z.exe" a -mx7 -mmt -sfx %ARCHIVE%\<self_extracting_executable>.exe <source_directory>\*
    – Dominique
    Jan 11 '17 at 8:51
  • No, certain compression settings will cause some memory problems, nothing to do with corruption. You will have to investigate why the file gets corrupted. Try copying it with Teracopy and perform the CRC check when you do.
    – Overmind
    Jan 11 '17 at 8:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.