Strange case of Dll hell

[Jugoslav_Dujic]

Our (quite complex, multi-component, multi-language) software uses MKL dlls which are distributed with Intel Composer XE Update 1 (12.1), and we redistribute these dlls in our own .\\Bin folder. We ship the software for both 32-bit and 64-bit platforms. The problem is detected on 32-bit one (we aren't sure if it occurs on 64-bit, but only the 32-bit computers have the environment suitable for reproduction)

The three dlls in question are:

mkl_def.dll (10.3.1.1)
mkl_core.dll (10.3.1.1)
mkl_intel_thread.dll (10.3.1.1)

On some computers (32-bit XP), an innocuous call to a Lapack routine (can't recall exactly which one, I think cgetrf) resulted in a process hanging. We determined that the call has never exited, and it stayed in the MKL forever. In other computers, it worked perfectly.

By a long combination of trial and error, we determined the conditions, by which the problem is also reproducible on other computers:

- The problematic computer had Intel Fortran 11.1 pro, with an older version of MKL, installed
- The path to the old MKL exists in PATH

In other words, if we got the old MKL directory out of the way (either by modifying the PATH or by renaming the directory), it worked perfectly. Otherwise, it would hang.

However, the behavior does not make sense to me. The calling process is in .\\Bin folder. According to MSDN, modules are called from the .exe's directory first, then from the working directory (also our .\\Bin, I think), and only after that from the PATH. From the calling .exe (C#), we traced the module list (EnumProcessModules or equivalent):

25.01.2011 11:28:30,546 DMS_FunctionHost.exe [TID=ExecuteHandler] - (DEBUGLOG) Module name: mkl_intel_thread.dll. Full path to the
module: C:\\Program Files\\TelventDMS\\DMS Software v3\\bin\\mkl_intel_thread.dll
25.01.2011 11:28:30,546 DMS_FunctionHost.exe [TID=ExecuteHandler] - (DEBUGLOG) Module name: mkl_core.dll. Full path to the module:
C:\\Program Files\\TelventDMS\\DMS Software v3\\bin\\mkl_core.dll

Dependency walker shows no C:\\Program Files\\...\\MKL path in used libraries. There is apparently no dependency, but there is obviously one. It seems that the MKL/Lapack tries to load something from the PATH that we don't want, but I have no idea what would that be.

We can perhaps submit the reproducer, but as I said, it's very complex software (didn't try a smaller reproducer). Before we try it, does the behavior perhaps light a bulb for someone? Is there something "hidden" that some of MKL dlls tries to load from the path? How would that cause a hang?

[VipinKumar_E_Intel]

Hi Jugoslav,

Thank you for submitting this issue, we are currently reviewing thisand will provide more details soon.

--Vipin