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

dll made with compiler 2016 and above fails in Win 10 LTSB

rorban
Beginner
1,850 Views

I am running into a very peculiar issue. We make a commercial product that uses certain dlls made with the Intel Fortran compiler. It includes the standard Intel Fortran runtime dlls. Because this is an embedded product for realtime signal processing, we use Windows 10 iOT LTSB (Internet of Things Long Term Service Branch), which is a special release of Windows 10 Enterprise intended for mission-critical appliances, where interruption of the appliance's operation to do feature upgrades is unacceptable. (Think ATMs or medical equipment.) Specifically, the version we currently use is "Windows 10 Enterprise 2016 LTSB."

 

The dlls made with versions 2015-2019 of the iFort compiler all work fine with "normal" Windows 10 Professional. However, only the dll made with the 2015 compiler works with Win 10 LTSB. All other builds, starting with those made with iFort 2016, fail to run, and do so "silently" (without any error messages). The dll is called by a Windows Service (written in MS C++), and when one looks at the "CPU" analysis of the Service in Windows Resource Manager, the 2015 dll appears as expected in the list of "Associated Modules," but the 2016 module does not, so it appears that the 2016 dll is not even starting up.

 

Does anyone have any insight into this issue? Needless to say, the seeming fragility of the situation is worrisome, given that this is a revenue-generating product.

0 Kudos
10 Replies
rorban
Beginner
1,850 Views

Looking at this problem further with a dependency analyzer (the software is called Dependencies, and it's a update of Dependency Walker that works on Windows 10), I see that one significant difference between the dll produced with iFort2015 and iFort2017 is that the former includes a dependency on MSVCR110.dll, and the latter includes MSVCR120.dll. Both are supposed to be in Windows\SysWOW64\. Originally, only MSVCR110.dll was present on the failing machine, but when I added MSVCR120.dll via the Microsoft Visual C++ 2013 Redistributable installer, my iFort 16 and higher -built software will still not run, so I'm stumped.

Another question is why either MSCVRxxx.dll is a dependency of a pure Fortran dll. They are both Microsoft C++ redistributables, and the Intel Fortran redistributable installer does not install at least MSVCR120. (I don't know about MSVCR110, because that was already present on the computer.)

0 Kudos
Lorri_M_Intel
Employee
1,850 Views

I can answer the second question; the Fortran Run-time library is written in C, and requires the Microsoft C/C++ libraries.    These libraries are available from Microsoft, as you've already noted, so Intel does not repackage them in their redist kits.

Once you added MSVCR120.dll, did you run the dependency analyzer again?

                   --Lorri

0 Kudos
Steve_Lionel
Honored Contributor III
1,850 Views

Does the Windows Event Viewer have an entry for the failure? It may have useful information. Note that simply copying MSVCR120.DLL won’t be sufficient - you need to install the Visual C++ 2015 Redistributables as it uses a Side by Side Assembly.

You could also build your DLL to link against static libraries and, probably, eliminate DLL dependencies.

0 Kudos
rorban
Beginner
1,850 Views

Thanks for everyone's suggestions.

Lorri -- I did not run dependency analyzer on the same LTSB machine that has the problem because the "Dependencies" program requires a C++ runtime, and this did not seem to work either. So I ran Dependencies on a normal Windows 10 Pro machine that has MSVCR120.dll installed (and on which my dll works OK). In my dll, MSVCR120.dll consistently appears as a dependency; here is the complete list: 

C:\Program Files (x86)\Common Files\Intel\Shared Libraries\redist\ia32\compiler\libifcoremd.dll

C:\Program Files (x86)\Common Files\Intel\Shared Libraries\redist\ia32\compiler\libmmd.dll

C:\WINDOWS\SysWOW64\MSVCR120.dll

C:\Program Files (x86)\Common Files\Intel\Shared Libraries\redist\ia32\compiler\svml_dispmd.dll

C:\WINDOWS\SysWOW64\kernel32.dll

Steve -- The only errors shown in Event Viewer were system errors of type 10016 (distributed COM), one referring to ShellServiceHost and one referring to Immersive Shell. Mr. Google suggests that these are very common Win 10 errors (I see similar errors on my normal Windows 10 Pro machines that run the program OK). I tried installing the VS 2015 redistributable, but this did not help.

I DID find a work-around today. By replacing VS2013 with VS2012 and reinstalling iFort 2017, I WAS able to build a working dll for the LTSB machine (with a MSVCR110.dll dependency). So the key to the problem seems to be the choice of Visual Studio, not the specific iFort compiler running in it. However, this is not a viable long-term solution because VS2012 is deprecated with the iFort 2019 compiler. I would hope that Intel would bring this VS2012/VS2013 issue to Microsoft's attention, just because of Intel's influence compared to a lone MS customer like yrs. truly.

0 Kudos
rorban
Beginner
1,850 Views

Steve -- Regarding building to link against static libraries, I would need a bit more info. The Fortran Library Properties now shows Runtime Library as "Multithread DLL." I tried selecting "Yes" for "Use Common Windows Libraries," but this did not eliminate the MSVCRxxx.dll dependency. Is there a specific option I should choose here, with the constraint that the result still has to be a dll (because of the overall software architecture of my product)?

0 Kudos
Steve_Lionel
Honored Contributor III
1,850 Views

Select "Multithreaded (/MT)", not "Multithread DLL". The "Use Common Windows Libraries" option is unrelated to this.

0 Kudos
rorban
Beginner
1,850 Views

The file does need to be a dll because of the overall software architecture of the product. Does  "Multithreaded (/MT)" allow the file to remain a dll?

0 Kudos
andrew_4619
Honored Contributor III
1,850 Views

rorban wrote:

The file does need to be a dll because of the overall software architecture of the product. Does  "Multithreaded (/MT)" allow the file to remain a dll?

Yes. The difference is just static vs dynamic linking it will make your dll bigger as more stuff will be built in. In you have any parallel options you cannot have a fully static link BTW.

0 Kudos
rorban
Beginner
1,850 Views

I tried Steve's suggestion (changing the linking to "Multithreaded" instead of "Multithread DLL," and it worked! The dll now runs OK, and MSVCR120.dll no longer show up as a dependency. The only two dependencies left are kernel32.dll and IMAGEHLP.dll.

0 Kudos
Steve_Lionel
Honored Contributor III
1,850 Views

Excellent!

0 Kudos
Reply