Not a valid win32 application

Not a valid win32 application

After installing the latest IFC on my Windows 7 computer and compiling our code unter the 32bit compiler, the exe will not run on WinXP but will run on Win7.

Version 2013 update 1

When I try to run it in WinXP, it says, "Not a valid win32 application"

Windows 7 works just fine

On anotgher computer running windows 7, I have the IFC version of 12.1.4.325 Build 20120410 and the code compiled on the 32bit compiler on that version works fine on WInXP and Win7.

31 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.
Steve Lionel (Intel)'s picture

That's a new one for me. Usually that error indicates a corrupted file. Would you please attach a ZIP of the EXE that fails on XP to a reply here, or you can use "Send Author A Message" to send it to me privately. Make sure that it is exactly the EXE that fails on XP (ZIP it on the XP system.)

Steve
Ferdinando Alde's picture

Hi Steve,

I got the same problem with a module compiled in VS12. Recompiling the same code in VS10 all run well also in Windows XP.

Nando Media Consultants - Italy
Ferdinando Alde's picture

Ops!

I attached the exe wich fails. You can run it .... it only ask to choose a file. With a couple of 'Cancel' ends the execution.

Nando Media Consultants - Italy
Ferdinando Alde's picture

Is it arrived? I hope yes .... at the last try.

Attachments: 

AttachmentSize
Download creprob.zip337.1 KB
Nando Media Consultants - Italy
Steve Lionel (Intel)'s picture

Ok, finally got the ability to test this. I can reproduce the problem, and it appears to be that the program uses several Windows API routines that do not exist in XP. Normally I would expect XP to give an "ordinal not found" error, which it usually does for DLLs, but I guess this is different. What I can't tell is whether the references are from the user code or some static library it links to, but there are a dozen or more. One example is CompareStringEx. I don't find references to this or the other missing routines in the Intel Fortran libraries.

Please rebuild the application and enable the creation of a link map in the Linker properties, and attach the map to a reply here. (You'll have to ZIP it.)

Steve
Ferdinando Alde's picture

Hi Steve, here is the link map. Thank for all.

Ciao

Attachments: 

AttachmentSize
Download creprob.zip62.34 KB
Nando Media Consultants - Italy

I used Dependency Walker and found the two DLL files that are not on XP. Problem solved.

Steve Lionel (Intel)'s picture

Which were those? I didn't see any missing DLLs. I did see the typical two "delayed load" DLLs that are usually reported. It looks as if the API reference is coming from the MSVC library.

Steve

mpr.dll and shlwapi.dll

Steve Lionel (Intel)'s picture

Interesting. My XP system has shlwapi.dll and I see no reference to mpr.dll in your EXE.

Steve

ok so I created a map file.

here is the file.

Attachments: 

AttachmentSize
Download relap5.7z193.93 KB
Steve Lionel (Intel)'s picture

Brian,

The only thing that looks like it might be a problem is that you have nearly a gigabyte of static data (COMMONs, local arrays and the like). This may combine with other sizable contributions to push you over the 2GB limit, and this can cause bizarre symptoms including the one you described. If you're right "on the edge" then small differences, such as less user address space taken by the OS, can make the difference between running and not running.

I don't see any other issues here - the program is statically linked, as it has to be since you are using Quickwin.

Steve

Quote:

Steve Lionel (Intel) wrote:

Brian,

The only thing that looks like it might be a problem is that you have nearly a gigabyte of static data (COMMONs, local arrays and the like). This may combine with other sizable contributions to push you over the 2GB limit, and this can cause bizarre symptoms including the one you described. If you're right "on the edge" then small differences, such as less user address space taken by the OS, can make the difference between running and not running.

I don't see any other issues here - the program is statically linked, as it has to be since you are using Quickwin.

When you say 1gb of static data, how is that possible when the code will run on a machine with less than 1gb of hard drive space.? Also everything ran just fine on the previous release of the IFC, but now with the latest release it does not run on Windows XP.

Steve Lionel (Intel)'s picture

As I said, the size of static data was the only unusual thing I noticed from the link map. Whether or not that's really the issue, I can't say. It does appear to be an address space issue - why changing compiler versions made a difference, I don't know. This isn't normally something affected by that. Can you attach the EXE (in a ZIP)? Or the .dwi file saved from Dependency Walker?

Steve

I have attached the depends files for a version that runs and doesn't run.
I have attached a comparison of map files for the good exe and the bad exe
I have attached the map files as well.

What does not make sense is I can take the same coding and compile it with version IFC 12.1.4.325 and it runs just fine on WinXP. Then I take the same coding and compile it on version IFC 13.0.0.089 and it fails on WinXP.
I do not change how I compile it.
Also the file sizes are different. The one that runs is 8,759kb and the one that fails is 9,367kb.

Attachments: 

ok I narrowed it down to my MAC. I am running Windows 7 on Paralells and I am compiling using the 32-bit compiler but I think the 64bit machine is interfering. I just compiled on my Win7 computer at the office with the latest compiler and it works fine.

Steve Lionel (Intel)'s picture

Ah, so you don't have "a Windows 7 computer" after all...

Steve

Quote:

Steve Lionel (Intel) wrote:

Ah, so you don't have "a Windows 7 computer" after all...

I do have a Win7 machine, but I had discovered the problem on my Mac running virtually Win7. Why though if my computer at the office that is a Win7 machine compile a 32bit app just fine, even though the machine is a 64bit machine. My mac is a 64bit machine but does not compile the 32bit version that runs on WinXP. I am using the 32bit compiler on both machines, but my Win7 machine the exe runs just fine on XP.

Steve Lionel (Intel)'s picture

What do you mean "does not compile the 32bit version"?

Steve

I recently updated from Intel Fortran Composer XE 2011 to Fortran Studio XE 2013, and I have SP1 installed. I am building on 64-bit Windows 7. I opened one of the several projects that we have that were for Fortran Composer XE 2011, and I compiled the application. When running the resulting exe on 32-bit Windows XP with Service Pack 3, I get a dialog box that says that the application is not a valid Win32 application. This sounds like the same problem that was being discussed in this thread. However, if the same application is built with the same project file on another developer's machine that is running Fortran Composer XE 2011, the resulting executable runs fine on 32-bit Windows XP with Service Pack 3.

I have premium support. Should I submit a request through that channel, or is it better to work through this problem here, first?

Thanks.

 

Steve Lionel (Intel)'s picture
Steve

Thank you, Steve.

Most of our applications are console apps, so this portion applies

For Fortran projects, right click on the project and select Properties. Change Configuration to "All Configurations". Go to Linker > System.  Change Subsystem to "Not Set".  Now go to Linker > Command Line. If it is a Console application, type in the Additional Options field:

/SUBSYSTEM:CONSOLE,"5.01"

Because of the heterogeneous development environment we still have amongst several different developers, it concerns me that there is what appears to be a target windows version number in the command-line parameters. I have two questions regarding this:

  1. Will these settings affect the developers that we have who are still using Fortran Composer XE 2011 in VS 2010? Right now, the project and solution files are compatible between XE 2013 and XE 2011 so that they work on both (Personally, I like this and considered it a desireable feature). If I change the project file and other developers use it with XE 2011 on Windows 7, will it work without problems?
  2. Will these settings have an effect on the developers that we have that are still developing on Windows XP with Composer XE 2011?

Thanks.

Steve Lionel (Intel)'s picture

I don't know the answer to these questions (I am away from the office so can't test these.) The settings are all linker settings and are intended for use with the VS2012 linker. It may be that the older linker in VS2010 won't care about this. Note that this is strictly  VS2012 issue, the Intel Fortran version isn't relevant other than that older versions don't support VS2012.

Steve

I was able to check it myself, and it seems to be ignored in VS2010.

Thanks.

 

I just puchased the latest versions Parallel Studio XE 2013 with VS2013 to compile my fortran code on August 15, 2014. I have Windows7 Enterprise.

I compiled and linked the code form a command line in both IA-32 Visual Studio mode, and Intel 64 Visual Studio mode. I also used Visual Studio to Build the executable. All executables did not run and gave the same error: *.exe is not a valid win32 application.

I am not a developer, I am a modeler. I need help with clear directions of what to do.

Thank you in advance

 

Steve Lionel (Intel)'s picture

If you are running on Windows 7 it is likely not the issue described earlier in this thread. Were there ANY error or warning messages during compile and link? Usually the case here is exceeding Windows' 2GB limit on static code and data - this almost always is hinted at by a linker error about the size of the program being too large.

Steve

Steve,

I compiled, linked, and produced the executable with no errors. When I tried to run the executable it gave the error: file-name.exe is not a valid Win32 application. I just submitted the issue to Intel(R) Premier Support. Your help is highly appreciated Steve.

Mohamed

Have you created a x64 program and tried to run it on a 32-bit windows platform? Are you sure that you have created a 32-bit program? If you indeed have, that will run on both 32-bit and 64-bit platforms I think.
Look at the configuration manager and show us a screen shot of what you see.

Steve Lionel (Intel)'s picture

I'm waiting for Mohamed to provide, through Intel Premier Support, a ZIP of his project including build logs and executable. It would also be instructive to download Dependency Walker and have it analyze the EXE to see what it complains about. I have to assume that Mohamed is using an x64 system, in which case both 32-bit and 64-bit applications would run. My bet is still on too large static data - sometimes the linker doesn't complain if the size is way too big.

Steve

Login to leave a comment.