EXE that isn't an exe?

[dajum]

Using the Intel(R) Fortran Intel(R) 64 Compiler Classic for applications running on Intel(R) 64, Version 2021.5.0 Build 20211109_000000

we are building executables.  It normally works fine, but we have one model that generates an .exe that won't run.  Trying to run it from the command line gives the message "The system cannot execute the specified program."  Trying to load the .exe into depends.exe says it isn't an executable.  The compiler doesn't give any warnings or errors.  Builds the .exe just like expected.  Is there any options in the compiler we can use to figure out what is happening? Or what the .exe that is created really is? 

TIA

Dave

[Steve_Lionel]

If I had to guess, it would be that the program exceeds 2GB static code and data (even on x64). This causes bizarre errors when the EXE is loaded (depends simply reports that the load failed, doesn't really tell you why.)  Set the linker option to create a link map, zip the map and attach it to a reply here - I'll take a look.

[dajum]

Here is the .map file.  Let me know.

Thanks,

Dave

[Steve_Lionel]

No, that doesn't seem to be the problem. But this map indicates a 32-bit executable, which doesn't match what you said initially.

[mecej4]

Steve, why do you think that the EXE is 32-bit, based on what you see in the map file? The preferred load address is shown in the map file as 0000 0001 4000 0000, and the .data section at 0003:0000 0000,

[Steve_Lionel]

My error - I was confused by something else. Are you able to zip and attach the EXE itself?

[jimdempseyatthecove]

FWIW, it appears you have some undefined symbols:

 0000:00000000       __AbsoluteZero             0000000000000000     <absolute>
 0000:00000000       __guard_fids_count         0000000000000000     <absolute>
 0000:00000000       __arm64x_extra_rfe_table   0000000000000000     <absolute>
 0000:00000000       ___safe_se_handler_table   0000000000000000     <absolute>
 0000:00000000       __x64_code_ranges_to_entry_points 0000000000000000     <absolute>
 0000:00000000       __volatile_metadata        0000000000000000     <absolute>
 0000:00000000       __arm64x_native_entrypoint 0000000000000000     <absolute>
 0000:00000000       __arm64x_extra_rfe_table_size 0000000000000000     <absolute>
 0000:00000000       __guard_longjmp_table      0000000000000000     <absolute>
 0000:00000000       __enclave_config           0000000000000000     <absolute>
 0000:00000000       __dynamic_value_reloc_table 0000000000000000     <absolute>
 0000:00000000       __guard_fids_table         0000000000000000     <absolute>
 0000:00000000       __guard_iat_count          0000000000000000     <absolute>
 0000:00000000       __arm64x_redirection_metadata_count 0000000000000000     <absolute>
 0000:00000000       __arm64x_redirection_metadata 0000000000000000     <absolute>
 0000:00000000       __guard_longjmp_count      0000000000000000     <absolute>
 0000:00000000       ___safe_se_handler_count   0000000000000000     <absolute>
 0000:00000000       __hybrid_code_map          0000000000000000     <absolute>
 0000:00000000       __guard_eh_cont_count      0000000000000000     <absolute>
 0000:00000000       __guard_iat_table          0000000000000000     <absolute>
 0000:00000000       __x64_code_ranges_to_entry_points_count 0000000000000000     <absolute>
 0000:00000000       __hybrid_code_map_count    0000000000000000     <absolute>
 0000:00000000       __hybrid_auxiliary_iat     0000000000000000     <absolute>
 0000:00000000       __guard_eh_cont_table      0000000000000000     <absolute>
 0000:00000100       __guard_flags              0000000000000100     <absolute>

Also, what is it with thearm64x_... symbols?

Jim Dempsey

[dajum]

Steve - I'm trying to get the .exe from the customer, but they are not sure they are allowed to transmit it.  But I'm hopeful that will get resolved.

Jim - no idea where those arm64x names come from.  But I'm not knowledgeable about everything that gets linked in.  All of those symbols are not recognizable to me right off.  Is there a way to see how they get linked in? 

Dave

[jimdempseyatthecove]

You apparently got the link map from your customer, can you get the link (and librarian) command line(s) too?

Compiler options wouldn't hurt either.

Jim Dempsey

[dajum]

The compile and link command is basically always the same:

astap.for userLogic.for /warn:declarations /warn:truncated_source /Qopenmp /fpe:0 /real-size:64 /integer-size:64 /names:lowercase /iface:cref /I:"C:\Program Files\Cullimore and Ring\SindaFluint\mod\Current" /MD /iface:mixed_str_len_arg /include:"C:\Program Files\Cullimore and Ring\SindaFluint\lib" /assume:byterecl /extend-source:132 /O3 /traceback /INCREMENTAL:NO /link /LIBPATH:"C:\Program Files\Cullimore and Ring\SindaFluint\lib" "FMI_Client.lib" "SFUtils.lib" "procesCur16.lib" "ProcessModulesDll_16.lib" "ProcessorCGlobals_16.lib" "utilityCur_16.lib" "amg_16.lib" "amg_16_interface.lib " "tdsubproc.lib"

[jimdempseyatthecove]

The only reference I've found referencing amg_16.lib is: https://studylib.net/doc/25794366/messages-case6

You might look at the link, library and export options and file lists.

Jim Dempsey

[Steve_Lionel]

I don't think those "undefined symbols" are relevant.

[dajum]

Here is the .exe

I have reproduced this same file several times on his machine. 

TIA

[Steve_Lionel]

The file is corrupt. Here is what the first part of an EXE should look like:

and here is what ASTAP.EXE looks like:

I don't know what would cause this for one specific program. It might be interesting to remove some of the options (maybe start with /O3 and go from there) to see if the behavior changes. I understand some of the options may be required to build (I hate seeing /iface in build options, but you may not be able to change those.)

[cryptogram]

It's been quite a while, but at some point in the past, we ran into a similar problem that was caused by antivirus software.

The symptom was just like what you are seeing, it would overwrite the first bit of the file, leaving the rest unchanged.  Perhaps

this was just a way of disabling executables that it didn't like.   These days,  the antivirus just deletes them.   This was all

part of a 'reputation' based trigger in the software,   which made it suspicious of new executables.  

I don't remember whether the corruption occurred right away, or whether it didn't show up until you actually tried running the

file.  The deletion behavior that we see these days, definitely only occurs when you try to run.

Our current workaround is to digitally sign all executables, whether debug or release, in a post build step, which apparently

makes the antivirus back off.

[Steve_Lionel]

That's the first time I've heard of an antivirus program that corrupts other EXEs. Harsh...  For many of them you can tell them to not scan your development directories. AV products really don't like programs that write executables (such as the linker).

[cryptogram]

Had time to find the e-mails from when this happened.   It turned out that the .exe files weren't actually corrupted.  What was actually

going on was that the virus scanner was attached to the whatever part of the OS was reading the data, and that sometimes the first bit of the data passed along was wrong.  This was subtle, because if you copied the file, the COPY of the file would have the missing data.

The only way you knew that it wasn't truly corrupted in the original executable, is that it would sometimes run the executable if you tried it again So what we were seeing was a buggy scanner with a random failure occurring at a high rate.   This got patched pretty quickly.

Took a while to dig this out from the corporate e-mail archive, as it happened in 2014.