0

I'm writing a console app for windows that sets up an environment and launches (popen) various hpc-apps using msmpi mpiexec.exe.

I have an msmpi installation installed locally to the application I'm writing. All works fine and parallel processing is OK.

However, as soon as I happen to have a system installation of msmpi as well (as installed by e.g. msmpisetup.exe), my applications stubbornly loads the Windows/system32/msmpi.dll instead of the msmpi.dll that I point at using PATH. Since the system msmpi.dll is of a different version, my apps does not run.

The PATH env.var. is set within my app, and it is apparently inherited correctly by the child processes, including mpiexec.

The only remedy I've found is to either (1) Rename system32/msmpi.dll or (2) place a copy of "my" msmpi.dll into every folder in which I have a parallel executable. Both remedies are... not nice.

How can I prevent my apps from selecting the system32/msmpi.dll and use the instance that's in the PATH instead??

Thank you for any advice.

N

Niklas Wikström
  • 1

1 Answers1

0

The standard DLL search order in Windows is documented to be

  1. The directory from which the application loaded.
  2. The system directory. Use the GetSystemDirectory function to get the path of this directory.
  3. The 16-bit system directory. There is no function that obtains the path of this directory, but it is searched.
  4. The Windows directory. Use the GetWindowsDirectory function to get the path of this directory.
  5. The current directory.
  6. The directories that are listed in the PATH environment variable. Note that this does not include the per-application path specified by the App Paths registry key. The App Paths key is not used when computing the DLL search path.

If you want your application to check a specific location first before using the system locations, you can call SetDllDirectory in the parent application before letting it execute other binaries that require a particular DLL.

jacob
  • 1,535
  • 1
  • 11
  • 26