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?
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.
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,
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?
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?
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.
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"
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.)
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.
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).
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.