XXX.exe 不是有效的 Win32 应用程序

Question

Configuration: Windows server 2008 x64.

Software is cross platform c++ 64bit.

The previous installer defaulted to asking the user to install to

c:\Program Files (x86)\company\version

For the last release I changed the installer using a path override to install to

c:\Program Files\company\version

The guys who does testing for us said that with the new install to c:\Program Files\ sub processes don't start. Override installing to c:\Program Files (x86)\xxx everything runs fine. Going to cmd.exe and running from C:\Program Files\xxx gives the "yyy.exe is not a valid Win32 application" error. Again this is not an issue with c:\Program Files (x86).

A customer also installed to default location and gets the same errors.

My build/dev machine does not show any of these errors. It runs a demo version of server 2008 (and visual studio express) that never updates and is never rebooted.

Is there something special about the "x86" tacked onto the Program Files?

NOTE:

This is NOT a problem on my dev machine which is also server 2008 x86_64.

dumbin /headers clearly indicates these programs are 64bit.

At this point there is no answer. Workaround is to just install to Program Files (x86) or elsewhere and be done with it. Will put in an FAQ that users should NOT install to Program Files (they'll look at a faq if stuff goes nuclear).

This could be a problem with the installer, it could be a classic case of "quack.exe" but applied to "Program Files". There's good reason why I generally hate windows.

Answer 1

The Program Files (x86) directory is where 32-bit programs are installed. When a 32-bit application is running, the %ProgramFiles% environment variable is set to C:\Program Files (x86)\ (by default; this could actually be located on a different drive).

Are you absolutely sure this program is being compiled as 64-bit?

Answer 2

Maybe the exe finds a dll in a 32-bit somehow in that particular configuration? Eg when sb managed to mess up his 64-bits dir with 32-bit dlls.

Remember that not loadlibraried dll's are also loaded on startup.

Answer 3

I think this is related to the manifest of the application. Have you changed this somehow? I got the same error when I was switching back and forth between compilers. vc9 (vs2008) created a manifest which we normally never use when we compile on .net 2003.