Old dll in SYSWOW64

[Matthias_Schumacher]

My 32Bit-Fortran program breaks due to an unsolved symbol in libmmd.dll.

The entry point pow2o3f seems to be quite new in this dll.

So I updated the redistributable libraries with the msi-package, but the file in SYSWOW64 remains the old one.

Obvoiusly the OS looks first in this directory to find the dll, then the program fails.

When I rename this dll in SYSWOW64 to something temp., it works.

Should I freshen up SYSWOW64 by myself or what to do?

Kind regards

  Matthias

[Steve_Lionel · Accepted solution]

That DLL should never have been placed in SYSWOW64 - Intel installers don't do that. Remove it from there. I have seen third-party installers copy language runtime DLLs to the Windows System folder because they don't want to add to PATH or use side-by-side installs.

[Matthias_Schumacher]

Hello Steve,

thanks for yur valuable reply.

I meantime I found out, that deleteing or renaming the dll is not enough, because some of our third party software recreates the missing dll from the installation package.

Is it possible to create an application config in an easy manner to ensure that DLLs with a minimum version are used?

It seems to me, that this for a .NET-application, but not for a console aqpplication, as mine it is.

Kind regards

  Matthias

[Steve_Lionel]

It's possible, sure. This is what Microsoft's side-by-side installs with application manifest does for you. Microsoft uses this itself for MSVC DLLs and has for many years.

A long time ago, the Intel libraries team looked into this and was discouraged from doing so by Microsoft, saying something better was coming along. It never did. I repeatedly asked the libraries folk to revisit this, but was unsuccessful.

I'm unsure if you can set things up yourself to use SxS for the Intel DLLs, as I think those DLLs themselves need to be built with the proper manifests. I may be wrong about this, so it's something to investigate. But even if you could, you'd have to "install" those DLLs yourself which isn't really any better.

Please complain to the third-party tool developers - what they are doing is blatantly wrong and will break applications for their customers. Rather than blindly copying other vendors' DLLs into the Windows system areas, they should use the appropriate redistributables installers. Intel provides one for its DLLs that can be integrated into product installs.

Unfortunately, the Windows System folder is searched before PATH. I looked for various ways around this but didn't find any, other than copying the correct DLL into the same folder as your EXE, which is almost as awful a solution.

[jimdempseyatthecove]

>>libmmd.dll ...  because some of our third party software recreates the missing dll

Does that version of libmmd.dll exist elsewhere on the system?
If so, can you rename that (or move it to a safe place).

Does the application that re-installed libmmd.dll run without the renamed/moved libmmd.dll?
IOW, does it re-create the old version of libmmd.dll from an archive? Or complain about missing .dll and quits. Or behaves badly using the new .dll?

The .NET application may include a "download missing .DLL" feature. If so, and it downloads and installs libmmd.dll from somewhere try deleting the SYSWOW version, and add to PATH your preferred version's folder and see what happens. (Note, the ...\IntelSWTools\... should already be there).

Jim Dempsey

[Matthias_Schumacher]

So the easy way is to use static linking?

[Steve_Lionel]

Static linking would certainly be a way around this, though I hate to recommend it in general.

[Matthias_Schumacher]

@Jim: I renamed it, but it came again...

[jimdempseyatthecove]

Have you determined where it is coming from?

       C:\>DIR \libmmd.dll /s /b

That will find it (and all libmmd.dll's) that are in plain view (even in hidden folders). Also the CMD window version is much faster than Windows Explorer (which won't search hidden folders below the start point)..

If that fails to identify the file, then the dll is likely in a compressed archive (Windows Explorer may find that as it searches archives too).

If you are unable to locate the source, then try to identify which application performs the copy. Once identified, you can write a shortcut .bat file that launches this application, and then on application close, delete the syswow version of the dll.

Jim Dempsey