Intel oneapi 2025.0: "Bad image" error with DLL in Visual Studio Project

[MarcGrodent]

Hello,

I recently upgraded to Intel oneapi 2025.0 and therefore switched from the ifort to the ifx compiler. I'm compiling a solution in Microsoft Visual Studio. Here are the details.

(1) Environment:

  - Windows 10

  - Intel oneapi 2025.0.4 (using ifx as the Fortran compiler)

  - Microsoft Visual Studio 2022 version 17.13.0 (community edition)

(2) Code structure (this is a very big Fortran code):

* Main program

program code3

  use mod_api

  call api_1(...)

  call api_2 (...)

...

* mod_api

The module including all the api's (subroutines & functions):

   - It is compiled as a static library (which itself is linked to a lot of other static libraries)

  - A DLL is also generated so that all api's can be called from the main program.

(3) Observations:

This code compiled and ran perfectly with an older version of intel oneapi (version 2021 using ifort) [by the way, it is also successfully compiled and launched with gfortran]. Now, I'm compiling with the new environment described in (1). The compilation is performed without any problems in both debug and release modes: no warning, nothing. When I try to run the program (regardless of the mode), a message is displayed saying that the DLL is either not designed to run on windows or it contains an error (see attached file). I've also tried to run the program from a batch terminal (with intel and visual studio environments properly configured) but same error again.

(4) What I tried:

- I compared the contents of the old DLL (obtained with ifort version 2021) and the new one with dumpbin (with different options: /headers, /exports, /dependents): the outputs are exactly the same, in particular same names of the subprograms exported through the DLL;

- I compared them also with Dependency Walker, but again exactly the same runtime libraries are called in both cases

- I then compiled the code on linux using ifx but from intel oneapi version 2024.0.0 (I didn't dare upgrade to 2025...) and no problem at all.

- I also tried to compile a minimal piece of code using a DLL. Same structure as described in (2), the difference is that the static lib encapsulating the api's is not linked to other libs (which was the case with my big code). In this case, no problem, but this minimal code does not replicate exactly what I'm doing in my big code.

As a conclusion, I suspect there might be a bug in the 2025.0 runtime libraries. Could you please provide guidance or suggest any known issues or workarounds related to this problem?

I can give further details if requested, although sharing the actual code is not possible.

Thank you for your assistance.

Regards,

  Marc Grodent

[Ron_Green]

I do not think this is specific to Intel Fortran or our runtimes.  If there were a problem with our runtimes we'd surely have heard about this already, and it would not have passed our QA/PV checks. 

HOWEVER, doing a general web search on "dll is either not designed to run on Windows" I found several hits not related to Fortran.  The general theme is that either Windows is corrupted, Visual Studio or the C++ runtime are corrupted.  Did you install the C++ components with Visual Studio?  OR the Fortran download you used to install was incomplete or corrupted.  

In all cases, the recommendation is to run a disk scan to search for corrupted DLLs.  

SFC (System File Checker) is a handy built-in tool to find and replace missing or corrupted system files on Windows. Here's how to fix the missing DLL files on Windows using the SFC tool:

1. Open Command Prompt as an administrator.
2. Type the command: sfc /scannow there and press Enter to execute it. The SFC tool will now open and automatically fix most issues it finds.

   

Note that the SFC utility is only helpful in case of errors with default Windows apps such as Microsoft Store, Photos, and Camera app.

with the number of users for Intel Fortran, an unreported runtime error, while not impossible, is not likely.  I would look at the VS installation and installer, and the Intel Fortran installers.  You could try a simple C++ hello world project in VS and see if it compiles and runs.  Similarly, does a simple console Hello world Fortran project compile and run.

[MarcGrodent]

Hi Ron,

Thanks for your answer and suggestions.

(1) I ran sfc /scannow. It seems that some files were corrupted and repaired (got the same message as shown in your screenshot). However, the reported problem was still there.

(2) Concerning Visual Studio, yes the C++ components are installed. I also installed an additional workload ("Desktop development with C++") as this had been recommended by yourself in some article a few years ago. C++ applications are running correctly.

I also launched a repair process of Visual Studio. Everything seems ok on this side. But the reported problem persists...

(3) Concerning Intel oneapi, I then uninstalled the 2025 version completely (Base and HPC toolkits) in order to reinstall them from scratch. After reinstallation of the Base toolkit, I ran the sample test to check that it was correctly installed. I did the same with the HPC toolkit.

As I told you, a minimal example of a Fortran program calling a dll runs without any problem. The problem with the "Bad image" error only occurs with my big code. This code has been under development for more than 12 years and was running smoothly with previous intel oneapi versions using ifort compiler. This is the first time we are trying to compile it with ifx under Windows. There is no problem when the code is compiled and run on linux using ifx but with intel oneapi version 2024.0.0...

I understand this is difficult for you to understand where the issue comes from. When I'll have some time I will try to reproduce the problem in a distributable test case (not sure I'll be able to do it though).

Regards

Marc

[Ron_Green]

If you give me the exact name of the oneAPI Base and HPC Toolkits I can get you the checksum info on those.

For the big code, does it have DLLs that were not recompiled?  DLLs that you are simply reusing?  Those I would suspect.  Have you examined file sizes of those to make sure they are correct size, or perhaps recopy them from another backup source?  Or if they are from a 3rd party, can you re-download those and insure the checksums are correct? 

If you have such DLLs, perhaps load them 1 by 1 to see if any are corrupted.  

Windows computers already have a registry program where you can register DLL files. Visual Studio or a decompiler are programs you can download to read your DLL files. Visual Studio online lets you look at DLLs without downloading or finding a program ahead of time. Below are four methods you can follow to open a DLL file:

Microsoft Windows 7 and newer Registry

Below are steps that may help you open a DLL file on Windows 7 computers and newer:

1. Open the command prompt. You can open the command prompt by going to the Windows Start menu or holding Windows Key+R and typing "cmd" in the prompt on the screen.
2. Open the folder with the DLL file. Once you find the folder, hold the Shift key and right-click the folder to open the command prompt directly in that folder.
3. Type "regsvr32 [DLL name].dll" and press Enter. This function can add the DLL file to your Windows Registry, helping you access your DLL file. You may use this function to add new DLL files to your computer.
4. Type "regsvr32 -u [DLL name].dll" and press Enter. This function can remove a DLL file from the registry. You may use this to remove DLL files that are not behaving correctly.

[MarcGrodent]

Base Toolkit and HPC Toolkit: version 2025.0.1 (11 Dec 2024). I downloaded these versions today...

ifx and icpx compilers: version 2025.0.4 (Build 20241205)

As an answer to your question, no everything is recompiled with ifx from scratch, so no old dll involved here.

Here is the output from Dependency Walker for the problematic dll (the second private dll is also recompiled; I'm pretty sure this one is ok since it is called by other executables that are working correctly):

Thanks for your help.

  Marc

[avinashs]

Reading through this thread, would like to add that I am experiencing similar issues as @MarcGrodent recently i.e. we have Fortran code built into dlls for over a decade with older versions of IFORT but the same code built into dlls with 2024.2 (IFORT) and IFX (2024.2 or 2025) cause various errors at the usage stage. The simple examples in the Intel Samples work fine but in large codes these errors may pop up.

We have been unable to use IFX as yet for large projects since the code that compiles with IFORT (and gfortran) fails with IFX at many locations (see for example my post https://community.intel.com/t5/Intel-Fortran-Compiler/IFX-2025-results-in-forrtl-severe-170-Program-Exception-stack/m-p/1646719). In some cases, IFX implementation of intrinsic functions such as MERGE is different from IFORT resulting in a catastrophic failure such as accessing an array element out-of-bounds.

I am in touch with other IFORT users who are not a part of this forum and are experiencing similar issues. I also agree with @MarcGrodent in that there could be something in the new redistributable files or MSVS updates that is causing an issue on some computers. Therefore, it may not be an issue with IFORT/IFX per se but VC++ and other files that are a part of MSVC and its updates.

[MarcGrodent]

Thanks for your comments @avinashs 

My colleague made the following interesting observations:

• Version 2023.2 is installed on his Windows machine (Base & HPC Toolkits) so that he can compile our code with both ifort and ifx
• He first compiled it with ifx and tried to run it: exactly same problem as the one described in my previous posts ("Bad image" message when the system wants to access the DLL)
• He then compiled it with ifort in an independent Visual Studio solution: as expected, no problem in this case, the code runs perfectly
• Now he went back to the ifx solution and replaced the problematic DLL with the one generated with ifort (we can discuss the validity of the approach, but it's just a trial ...): the code runs correctly!!

So it seems the problem is "just" due to the creation of the DLL with ifx. The big question is to determine what is going wrong. As explained in my first post, the DLL includes a number of modules which are themselves linked to many static libraries. Our feeling is that these links might be the cause of the problem... Unfortunately, so far we have not been able to reproduce this behaviour on a simple case.

Any suggestion is welcome.

  Marc (with thanks to Romain!)

[Ron_Green]

Base toolkit

intel-oneapi-base-toolkit-2025.0.1.47_offline.exe

MD5 : 1751c1518df30ea525abb71a281983b3

SHA384 : 82ca9a1848a5f92b81b57449ef5eec0d1f2933bacd46097e5f1ef8b99eea0de2f8f4b13bc75deb680f26ded424ee3008

hpc toolkit

intel-oneapi-hpc-hpc-toolkit-2025.0.1.48_offline.exe

MD5 : ec975fed836add6851d81b64a3e41ce9

SHA384 : d7b48999ecbaf0616023483e11ac6c7711ab6f65892596029a24969163ff0879740c5c7c553323171b2e2fc2b01610b4

ifx

intel-fortran-compiler-2025.0.4.19_offline.exe

MD5 : 731bb236957613cc18039a3c18711698

SHA384 : 64bc0a1b5e5a75acea160e58f3a439e4568325363e5dd0e9abe5aad86f0b7743090c532c3d9ea023b1481a24fc34339d

But it raises a question:  the Base and HPC Toolkits have everything you need for C++ and Fortran.  Although there was a 2025.0.4 Patch release, there was nothing in there for Fortran over the 2025.0.1 release of oneAPI.  There were some fixes for SYCL but I doubt you use that from the Intel C++ product.   If you have installed the ifx and icx compilers after base and hpc ... who knows, maybe something went wrong.  Also, you didn't also install the runtime libraries kit as well did. you?  Runtimes are only for computers without an installed ifx or ifort installation (where you run compiled apps, like a customer system w/o VS 2022)

Uninstall all of these, compilers, any runtimes, Base, HPC.  Then install JUST these 2 in this order
Base Toolkit 2025.0.1

HPC Toolkit 2025.0.1

Next, I need to check the VS 2022 version that we support.  VS updates so fast.  Often an update hits after our release and we've not had time to validate it against our tools.  I'll check to see what we support with 2025.0.1

[MarcGrodent]

The thing is that I've already completely uninstalled 2025.0.1 (Base and HPC). Indeed, this version is of no use to me since I'm not able to work on my code and run it with ifx.

Therefore, I downgraded to version 2023.2 (my colleague had kept the installers) for which I have at least ifort which is working fine. However, as explained in my previous post this morning, the problem we are experiencing with ifx also occurs with this old version! As explained, replacing the problematic DLL generated with ifx with the one generated with ifort seems to solve the issue (but the procedure is of course not satisfactory...). So it seems that the problem comes from the creation of the DLL with ifx.

Regards

  Marc

[MarcGrodent]

After some research, it turns out that the "bad image" problem when trying to open the DLL is due to the size of its image.

In fact, the code is quite old (mid 90's) and contains a lot of static allocations. We're currently refactoring it in order to use dynamic allocations but it takes time and it is not straightforward. Here is a summary of the current situation:

• Machine: Windows 10 (32 GB RAM)
• Intel oneapi 2023.2
• Visual Studio 2022 17.13.0
• 64-bit project compiled from scratch with ifort or ifx (a small part of the code is written in C++ and compiled with MSVC)
• Image size of the DLL obtained by means of 'dumpbin /HEADERS'
• Compilation with ifort: 
  • Image size of the DLL in debug mode: 1.5 GB
  • In release mode: 0.05 GB (!)
  • In both cases, the DLL starts without any problem
• Compilation with ifx (exactly the same code as with ifort):
  • Image size of the DLL in debug mode: 3.4 GB
  • In release mode: still 3.4 GB!

I noticed that the "bad image" error occurs as soon as the image size is greater than 2 GB (I was expecting a value higher than that... the reason is unclear). As we have only used the ifort compiler so far, the problem never appeared. However, what seems strange is that the image size obtained with ifx is approximately the same in debug and release; with ifort, the size is strongly decreased in release. Moreover, we are not using any compiler flag that could impact the image size.

Without modifying the code, our only option to use ifx would be to decrease the dimensions of some critical arrays.

Regards

  Marc

[Anders-M]

Hi MarcGrodent,

have you solved this case? I am running into the same problem (with the difference that my dll is still quite small)

Thanks,

Anders

[MarcGrodent]

Hi Anders,

No not really. Using ifx under Windows would require refactoring the current code (mainly replacing static allocations by dynamic allocations,  which is not straightforward). So I decided to keep using ifort on Windows. Using ifx under linux does not cause any problems.

Regards

Marc

[Anders-M]

Thanks a lot for the quick answer. 

Hopefully Intel will fix the issue...

Best regards
Anders

[BjörnTR]

I ran into a similar issue, and did some digging, and managed to get it to work (for me)!
TLDR: Disabling IPO in the Linker/Optimization project settings, (Interprocedural Optimization, No (/qnoipo)) worked for me. (OR Enable IPO in the Compiler/Optimization project settings! Multi-file (/Qipo))

Everything works just fine with IFort, both old and "new" versions. However with IFX I was getting the "Bad Image" error. (I tried a couple different versions, including the latest 2025.2.) And the size of the produced dll is about the same either way. (Old 32 bit builds are a LOT smaller, as in around 10-20% of the size for some unknown reason, but this seems to be the same for IFort and IFX, as in 64 bit IFort builds are also large.)
We are also building other IFX dll's that work just fine.

From dumpbin /LOADCONFIG I noticed two things when comparing the dll's, firstly that the .data was more then an order of magnitude larger. D8DAC000 (IFX) vs  BDA1000 (IFort), but also that "Volatile metadata pointer" was 0 instead of some value. (And that the entire detailed section about Volatile Metadata was missing!) (With IPO on in both compiler and linker the Volatile metadata pointer is also 0.)

We also have a lot of stack allocated stuff, and it would be non-trivial to change it at this point. And I did try to reduce how much was stack allocated by changing some hard coded values as well as the "Heap Arrays" option but it had almost no effect on the size of .data and didn't solve my problem.

Either disabling IPO in the linker setting, OR enabling IPO in the compiler settings seems to have fixed this issue for us. I do believe this is a bug with IFX, but the fact that there is seemingly a easy "workaround" so far for us makes it easier to accept for now.

[MarcGrodent]

Sorry for my late reply on this issue.

By default, the Interprocedural Optimization seems to be set to 'No' on the compiler side and to 'Yes' on the linker side. I've tried the compiler option /qnoipo (i.e. disabling Interprocedural Optimization for the linker) in Release mode, although I do not really understand the relationship with the current issue. By the way, the link to interprocedural optimization options in the online documentation returns a page-not-found error (https://www.intel.com/content/www/us/en/404.html?ref=https://www.intel.com/content/www/us/en/docs/fortran-compiler/developer-guide-reference/2025-2/interprocedural-optimization-options.html ).

The application can now be run, but this is just by chance. As explained in my previous messages, the image size of the DLL in Release mode was equal to 3.4 GB with ifx (compared to 0.05 GB with ifort!!). With option /qnoipo, the size happens to be reduced by a factor of 3 around 1.2 GB which enables the application to start. However, I do not know if there are any side effects of selecting this option. So to me this is not a valid workaround and I still believe that there is something wrong with ifx. Please note that I'm still using Intel oneapi 2023.2 (I can't do without ifort for the moment, which is why I haven't upgraded yet). However, according to the previous message, the problem still seems to be present in the latest version.

[Ron_Green]

There is an existing bug report, CMPLRLLVM-55513 "data section object file growth caused by type-bound procedure call with a CLASS passed-object".  I suspect the large size is due to this issue.  It has been reported on Windows for several clients.

We had to rework our algorithm for linkage.  There are several cases that trigger this size problem.  

The good news is we have added what we believe will fix this issue into the code for the next Update release, 2025.3.0.  It is roughly 2 months away from release.  Maybe sooner.  

[MarcGrodent]

Hi Ron. Thanks for your answer. 

Let's wait for the next update then!