- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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)?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Select "Multithreaded (/MT)", not "Multithread DLL". The "Use Common Windows Libraries" option is unrelated to this.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Excellent!
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page