Fails to recognize DLL

[Carstensen]

Hi,

I have a big Fortran project which I compile into a multithreaded DLL using Fortran Compiler 2020.4.311 in Microsoft Visual Studio Professional 2019 16.11.27. This DLL is used for various calculations in Excel and it works perfectly fine on my computer.

I made a new release of this DLL before summer, and it was working fine on my colleagues computers. But when we are back in office after vacation, it is suddenly not working on my colleagues computers, but it still works on mine. 

Any ideas what is going on? Any Windows or Office updates that could explain this? We have crosschecked that the Excel options are the same on all computers, and the Excel sheet is working perfectly fine with older versions of the DLL.

Regards,
Carl

[jimdempseyatthecove]

You need to be more specific as to what you mean by "Fails to recognize DLL".

What is the error message?

The second paragraph (... was working, ... bacdk in office... not working) implies that your System Administrator (or Windows Update) has:

a) changed PATH or environment variable such that the DLL is not findable when called

b) System Anti-Virus moved the DLL to the virus chest (making it not findable)

c) You (someone) uninstalled a component that the DLL requires (The Intel OpenMP Library)

d) You (someone) installed a different (incompatible) component that the DLL requires

Jim Dempsey

[Carstensen]

There is no error message. The Excel functions which are calling the DLL fail to provide outputs - only get #VALUE!

a) The path to the DLL is specifically given in the Excel sheets, so the user has full control of that themselves. And we are 100% sure that the path is correct. But the environment variable I'm not sure about. What variable could cause this?

b) Path is given, ref. a)

c) I haven't uninstalled anything, but I have added the MKL library as part of the build. Could that be causing anything?

d) The DLL is not depending on any other components

\Carl

[jimdempseyatthecove]

And if you re-install your DLL, does it work?

Note, you may need to "Register" your DLL.  See: https://blog.pcrisk.com/windows/13557-how-to-register-dll-files

Jim Dempsey

[Carstensen]

Don't understand what you mean by re-install. We have used this DLL for several years and it has never been necessary to install or register the DLL. The only thing that has been done is to ensure you point to the correct path of the DLL when you use it through Excel.

I actually tried to register the DLL yesterday, but it didnt' manage to do it. I got an error saying: "The module was loaded but the entry-point dllregisterserver was not found." I asked ChatGPT about this and it said that this is usually caused by the DLL not being COM (Component Object Model). Further, it said that Fortran DLLs are typically not COM DLLs, so they do not have the required entry points for registration using 'regsvr32'. If this is true or not, I don't know. Something I can change in the compiler options?

This whole thing is very weird. I haven't changed anything on my side in the compiler options except including the MKL library. The only thing I can think of that has changed is Windows updates, Office updates, and Fortran compiler updates.

\Carl

[jimdempseyatthecove]

>>Don't understand what you mean by re-install.

This could be as simple as copying a fresh copy of the DLL to the system having problems.

If the DLL runs on your development system, but not on "the other" system, then

a) the new DLL wasn't loaded on the other system (different copy was loaded instead)

b) The DLL was built on your system using the CPU architecture of the development system for its instruction set .AND. the other system did not support some of the used instructions. For example, you compiled using AVX2 and the other system only supports AVX. The usual symptom of this is a report of illegal instruction. However, Excel is built with exception handling, and as a result, instead of reporting illegal instruction, it reports an invalid result (due to the DLL function aborting).

Jim Dempsey

[jimdempseyatthecove]

It may be useful to run the Excel program to get a fresh error, then immediately run the System Event viewer to see what was logged.

Jim Dempsey

[avinashs]

Here are some suggestions that you may check:

1. The latest Excel updates by Office 365/Windows are by default 64-bit. You may want to check whether the dll is compatible with 64-bit (I may have missed whether you mentioned this in your post). I will note that some features do not work reliably with 64-bit as they did with 32-bit (Excel and IFORT).

2. Build the dll with /iface:cvf /libs:static options for compilation with ifort in addition to other options you may have.

3. Perhaps try connecting an example dll with your Excel to see if it is specific to your main dll.

[Carstensen]

Thank you for your replies. Seems like I've narrowed it down to the MKL library. I disabled this in the compiler, and then it worked. But I need this library, so I don't know what to do.

I use the "Parallel" option for the MKL. Do the users of the DLL require anything on their computers when I activate the MKL? Sounds weird to me, but that seems to be the case. Any suggestions on what I can do?

[mecej4]

Applications and DLLs built using the Intel Fortran compiler may require certain runtime components to be present and in places where they can be found. Likewise, using MKL may add dependencies on MKL runtime components. Such dependencies are minimized when you use /libs:static, but they are not eliminated completely.

In a VS-configured command prompt, run the command 

     dumpbin /dependents <myExcelDll.dll>

In the command line, replace "<myExcelDll.dll>" by the name of the DLL that you expect to be called from Excel. If you report the output of the command in your reply, we can interpret that and decide on the next steps.

[Carstensen]

This is what I got when I ran the dumpbin:

[mecej4]

The output that you posted leads to the following question: In the environment that exists when your DLL is called from Excel, does libiomp5md.dll exist and is it accessible through the PATH environment variable?

[Carstensen]

Seems you are correct - it's caused by libiomp5md.dll. I built my dll without the MKL library, and then libiomp5md.dll was not part of the dependency. Can I somehow build my dll including the MKL library and not have a dependency to libiomp5md.dll? Or do I just have to include this dll as part of the package I send to the users of the Excel tool?

[mecej4 · Accepted solution]

If your DLL is multithreaded and uses MKL, as documented here (expand and read the last bullet item on that page), you will need to provide libiomp5md.dll to your users, or ask them to download and install the MKL runtime package. 

[Carstensen]

Thank you for your help!