Use DLL on another machine

Use DLL on another machine

My apologies if this has been asked before/recently, especially if it was asked by me. :-)

I am testing calling a Fortran DLL from Python, and it works fine on the machine (Windows XP, SP2) where it is built. But when I try it on another machine (Windows XP, SP3) I get this error:

WindowsError: [Error 14001] This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem.

The error occurs when I attempt to load the DLL, i.e. before calling a subroutine.

Does this message mean that I need to copy some Intel DLLs onto this machine? There was a trial version of ifort installed, but it has expired.

12 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

Try to look at dependencies of your dll (on my PC i use right-hand mouse button and "View dependencies") search for all lib*.dll which are most probably fortran libraries used by your dll.

Or link dll against static libraries.


Yes! Static linking did the trick. Thanks a lot.

I'm not sure how to use the right mouse click to view dependencies, though. Do you mean in Explorer? R-click doesn't show such an option in XP.

Yes, I meant right click in explorer on dll file. It works fine with my installation of Fortran, may be it depends on installation.


A command line alternative is dumpbin /dependents some.dll

The .dll collection you got from a trial installation won't stop working when the trial period ends. Current versions of ifort have a companion redistributable .dll package of which you can make unlimited use while the version is covered by your license. Older versions entitle you to copy those which your application requires.

Amazing the timeliness of this thread. I am struggling with exactly the same problem.

I have an app that links at run time with multiple or no DLL's depending on the simulation setup. I had the same problem in the past when using an older version of Visual FORTRAN that I fixed by adding the FORTRAN libraries. I now am using VF 11.0 and can't get it to work.

Here is what I have done, using the dependency walker I isolated the DLL's and put them in the directory with the executable on the target machine. Still get the same error # 14001.

Not sure what you mean link statically.

Thanks in advance,


That does it. Thanks.

Project > Properties > Fortran > Libraries > Runtime Library

select Multithreaded instead of Multithread DLL (or the Debug versions thereof).

This links the libraries into the executable (i.e. statically), otherwise the executable will use the DLLs (dynamic libraries) on the host machine, which might not be compatible. I don't understand why copying the appropriate DLLs into the working directory doesn't work.

The error noted in this thread is due to needing the Visual C++ redistributables shared assembly installed on the target system. Those DLLs use manifest files and simply copying DLLs does not work. See this article for more information - particularly the PDF attached to it.

Retired 12/31/2016

Steve, in that pdf, under building a program with statically-linked runtime libraries from the command line, it says:

Use Qopenmp-link:static to link the static OpenMP runtime library. ... Linking static OpenMP runtime library is not recommended.

How is that statement to be interpreted?

It should be interpreted as "do this if you think you have to, but it can cause other problems". Generally, the issue is that if you are mixing with other code that references the DLL OpenMP libraries, bad things can happen by having two OpenMP libraries active. (Usually you get an error message about this but not always.)

For people who absolutely want everything static, we provide the option, but we'd prefer that you didn't use it.

Retired 12/31/2016

OK, I think I can avoid that OpenMP problem.

Leave a Comment

Please sign in to add a comment. Not a member? Join today