Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
27431 Discussions

The ordinal 747 could not be located in the dynamic link library error message

New Contributor I

I am using the Intel Visual Fortran 2017 update 2 compiler to generate an application called "Solver64.exe" that gets shipped to our clients. It is working fine for most of the clients but a few of them are reporting an error message "The ordinal 747 could not be located in the dynamic link library Solver64.exe".

We know that this is caused by Windows locating and using an Intel Fortran redistributable library that is incompatible with the Intel Fortran 2017 update 2 compiler we have used. The incompatible redist has been installed by some other application in a different folder to where our redist gets installed. The problem is that Windows seems to have some haphazard way of finding redistributables and simply uses the first one that it finds, regardless of where it is and whether it's compatible or not. Is there any way to control this so that the correct redistributable for our application always gets used?


0 Kudos
3 Replies
Black Belt Retired Employee
The search order is not "haphazard". The order is (usually): 1. Current folder 2. Folder containing the EXE 3. Folders on PATH 4. Windows folder 5. Windows System folder The simplest approach is to put the necessary DLLs alongside your EXE. You could also have your installer include the Intel compiler redistributables merge module which, I think, would cause the later ones to be found first, though there is no guarantee. Side by side assemblies would be another approach, but Intel doesn't offer this as an option. (You might be able to roll it yourself, but I have never done this.)
New Contributor I

Correct that putting dependant DLLs alongside the exe does fix the issue but we are preferring  to use the dynamic link to the common intel runtimes and not to 'bloat' the installation any further.

​The windows search path according to their documentation (and this varies slightly depending which windows document you look at and is
1. application path
​2. system directory
3. 16 bit system directory
4. windows directory
5. current directory
6. environment path directories

It seems that the environment PATH is always the last, and different to what you stated!!!!

​Haphazard also because in reality you never know if windows is giving the correct version of the dll. It is only because the latest 2017 dll has an additional function ordinal 747 that an error is produced before. Previously you could be using an old 2013 dll if it was the first one found instead of say the 2015 version you were expecting.

​So the issues that have been occurring to users is that the dependency file libiompmd.dll
​1. has been found in c:\windows, c:\windows\system32 The files in these folders have been older than the 2017 version and do not contain the ordinal function 747. As windows looks at these first, it returns the error. Am not sure how the dependency got into those folders but I assume it was an old location used by old intel runtimes, or another program had installed them there. To overcome this we are getting users to rename the libiompmd.dll​ to enforce windows to keep searching through  its list

​2. We have had a few users that have a 2015 version of libiompmd.dll ​in C:\Program Files (x86)\Common Files\Intel\Shared Libraries\redist\intel64\compiler but in C:\Program Files (x86)\Common Files\Intel\Shared Libraries\redist\intel64_win\compiler they have had the 2017 version of libiompmd.dll​. I suspect this has something to do with the 2017 runtime installer not overwriting previous versions?? So when it comes to reading the environment path, the path to the intel64 folder is before the intel64_win folder so windows finds the older 2015 dll first and returns the ordinal 747 error because it is not in the older versions of the dll. By renaming the intel64 folder, windows then finds the correct dll in the intel_win folder.

​I am not comfortable with having to rename these folders and files as it may cause issues to other programs so only reliable option seems to put the dlls into the application folder.

​All the above have been confirmed using dependency walker.


Black Belt

Applications that install the runtimes into windows system directories are applications with badly broken installations.

Applications that install the runtimes in their own program files directory, and then add their own program files directory to the system PATH, are also applications with badly broken installations.

Unfortunately, it isn't too hard to find examples of both, from vendors that really should know better.  Obliterating the offending DLLs is the most practical solution (particularly for the first sort - for the second sort you can reorder the system path) I am aware of, but it can be difficult to arrange/explain that in controlled IT environments.