Unable to allocate libiomp5md.dll in my visual studio

[Husam1]

Hello 
I have a long-standing issue in compiling my Fortran project using visual studio. the problem is as follows:

1. when running my project with release x64 I got the following error: 

the procedure entry point __kmpc_aligned_alloc could not be allocated in the dynamic link library. 

2. the problem seems to be from the lib file libiomp5md.dll. 

-it is located at this folder "C:\Program Files (x86)\Intel\oneAPI\compiler\2023.0.0\windows\redist\intel64_win\compiler"

I added the extension to the project properties linker>additional library directories.

I confirmed that the file path is included in the environment %PATH% 

but still, it seems that my visual studio is unable to allocate it. 

however, when I copy the library file to the project directory it works without any error. 

what could be the reason for the problem and what is the solution 
bwt if I run the project with x86 configuration it works without any error. and I definitely have x64 system.

[ArpanB_Intel]

Hi Husam, thank you for reaching out to us. We will move your query to the Fortran forum for support on your issue.

[Ron_Green]

Could be any number of issues.

It's interesting that it compiles as an x86 ia32 configuration.

Does this project have an external library DLL or .lib files that you use? Do you use MKL?

Some sort of solver library, for example?   Is it 32bit or 64bit DLL or .lib? 

Sometimes external libraries will have MKL calls, and MKL does use libiomp5md.dll.  

You Project Properties for x64, Fortran->Language->Process OpenMP Directives is 'enabled' right?

the symptoms would indicate that you have 32bit objects that you are trying to link into a 64bit application configuration.

[Husam1]

I am not using any external library or MKL in my project. 

and the Process OpenMP Directives is enabled. 

 its really strange since every thing seems to be okay 

[Steve_Lionel]

The most likely cause is that there is an older version of the 64-bit libiomp5md.dll on your system that is found in PATH earlier than the correct one (with the path you found.) Search your system for that file name and remove any that are not under the Intel\oneAPI folder.  possibility is C:\Program Files (x86)\Common Files\intel\Shared Libraries\intel64 which was used in earlier versions but is now used only when the redistributibles kit is separately installed. (If that folder is in PATH, remove it.)

[Husam1]

Thank you for the reply. 

I checked the PATH environment and I  found the link to the shared library. I removed it but unfortunately, this didn't solve the problem

[jimdempseyatthecove]

You can use the dependency walker to identify which DLL's  will be called. But not necessarily which ones as this will depend on the library search path(s) in effect when you run the dependency walker verses when you run the application normally (in or out of the IDE).

An alternative is to run the application in MS VS under the debugger, then look at the MS VS Output Window (not the cmd window). This will show the DLL's, with paths, as they were loaded. Look for libiomp5md.dll and check the path to it to assure it is the correct one (the one from oneAPI). On my system I see:

C:\Program Files (x86)\Intel\oneAPI\compiler\2023.0.0\windows\redist\intel64_win\compiler\libiomp5md.dll

You may or may not have the same version of oneAPI, but you should see something like this.

IIF you find that some other libiomp5md.dll was loaded, then it's path is in one of your environment variables and you will need to change that (or remove that).

Note, the location of what gets loaded is the first one that matches the name on the "Library Search Path".

Caution, the fix is not necessarily deleting the old file as you may have old/other applications that depend on that version. Instead, you need to prepare your runtime environment such that the search order finds the correct version of the DLL.

Jim Dempsey

[Husam1]

Hello 

from the debug menu in the attachment, it looks like with release and x64 it reads the library files from the system32 folder although I don't have that folder in the %PATH% environment variables. I also found that the path to the ONEAPI library is not 1st in the list so I moved it to the beginning. however, this didn't solve the problem.

[Steve_Lionel]

Windows automatically searches Windows\System and Windows\System32, as well as your current directory and the directory containing the executable. The screenshot shows a libiomp5md.dll in Windows/System, where it does not belong. Sometimes third-party installers stuff compiler DLLs there because it's "easier", but this leads to problems.

[jimdempseyatthecove]

Steve, Husam

The screenshot showed the loaded .dll was located in the Windows\System folder, not the System32 folder.

Regardless of the difference, as Steve said, it does not belong there. It is likely that someone (or someone's installer), at some earlier time, placed an earlier version of libiomp5md.dll (and possibluy libiomp5mt.dll) into that folder as a means of avoiding having to set the environment such that it locates the desired .dll.

Please rename those files (as opposed to deleting them) to something like libiomb5md.dll.old (and libiomb5mt.dll.old) such that these files will not be loaded... yet be available should you find that some older program has issues. Note, renaming these files may result in your older applications WITHOUT proper environment settings will not be able to find the proper dll or find any dll. In this event, copy those files from the System folder to your complaining application folder and then rename it to remove the additional ".old" suffix.

As an alternative, you can create a folder, such as OldDLLs, copy the dlls into there, and then set the environment prior to running the program such the the proper dll's are found (first).

Note, if this (setting environment before running old program) becomes cumbersome, you can create a batch file that sets the environment (for PATH) properly, then use the START command in the batch file to launch your program.

: Husam.bat
: setup the environment variable to fine the old dll's first
set PATH=\OldDLLs;%PATH%
: Run your program (this example will run NOTEPAD on this batch file)
START NOTEPAD Husam.bat
! leave the batch program
exit

Then you can create a shortcut to that batch file to launch your application (with the corrected PATH).

Jim Dempsey

[Husam1]

Thank you so much for the reply. 

I renamed the file in the system folder (DELETED) and now the library is read from the correct folder. 
I have one question you may help with, why the version is marked as (win32)?  Does it mean it is utilizing a 32-bit system only?

Thanks;

[Steve_Lionel]

You built the 32-bit (x86) version, so you get Win32. If you changed to an "x64" configuration, then you would (probably) see (Win64).

[jimdempseyatthecove]

FWIW on 64-bit Windows systems, and for reasons only Microsoft can explain, the folder

\Windows\System32 (yes 32) contains the 64-bit code

\Windows\SysWOW64 contains the 32-bit code.

I suspect that doing otherwise would have broken too many programs that expected to have the systems runtime library (regardless of build bitness) to be located in the System32 folder.

What Steve was referring to were the build output folder names you get from Microsoft Visual Studio.

C:\test\Console2\Console2\x64\Release

The 32-bit output folders omit the x64 (C:\test\Console2\Console2\Release)

Jim