DLL load failure when ipps.dll is the only reference

[gast128]

Hello all,

we upgraded recently to oneAPI 2025.3 / IPP 2022 and encounter now mysterious DLL load failures. It seems to be related to ippcore.dll not be loaded before any other IPP DLL. If ipps.dll is loaded before ippcore.dll the load of ippcore.dll fails. This is reproducible by making a small console app with the following code (tested on Windows 10):

#include <windows.h>
#include <filesystem>


int main()
{
    std::filesystem::current_path("D:\\Develop\\Bin\\x64\\Debug");

    const HMODULE h = ::LoadLibraryA("ipps.dll");
    
    if (h == 0)
    {
       //126: ERROR_MOD_NOT_FOUND 
       std::cerr << "Error " << ::GetLastError() << std::endl;
    }
    else
    {
       ::FreeLibrary(h);
    }

    return 0;
}

Although above example is artificial in real world applications this can easily emerge when only ipps functions are used. Workarounds are not easy: with implicit loading and link to 'ippcore.lib' the linker removes the reference to ippcore.dll if there are no functions used. This can be hacked by artificially add a a dependency  (e.g. invoke ippGetLibVersion somewhere) but the problems are not over then. I see now that sometimes the Windows loader reorders the DLL loads and ipps.dll might be loaded before ippcore.dll resulting in the original failure.

Can anyone help? The best solution is that ippcore.dll just loads independent of the order.

[gast128]

...I can't edit my own post. There might be a reason why ippcore.dll is only 'loaded' (actually memory mapped in the process space) after ipps.dll. It seems that Windows parallel loads all indirect DLL's through its thread pool. The order is non deterministic resulting in spurious failures. Forcing a memory mapping load order is not possible besides the direct order in the PE executable. It would be nice if Intel would fix this IPP issue; it already costs us a week.

The parallel loading can be by HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\<YourApp.exe>\MaxLoaderThreads registry value on Windows but this is not a workable solution (i.e. costs performance and per PC / exe). 

[Chao_Y_Intel]

Hello，

can you check the new 2026 IPP release? I can not reproduce this issue.  I also add DLL search directory like bellow:

std::filesystem::current_path("D:\\Develop\\Bin\\x64\\Debug");

SetDllDirectoryA("D:\\Develop\\Bin\\x64\\Debug"); // ADD THIS

const HMODULE h = ::LoadLibraryA("ipps.dll");

please check if this work for you. 

thanks,

Chao

[gast128]

Hello Chao,

busy with other things right now but when I have time again I can try IPP 2026. Be aware though that we use implicit linking so solution with setting DLL directories wouldn't solve our problem.

wkr

[gerard_verbiest]

Well, I just tried with the 2026 version but the problem persists.
I used a slightly different program to reproduce the problem:

#include <windows.h>
#include <iostream>


int main()
{
	const HMODULE h = ::LoadLibraryExA("d:\\workdir\\temp\\bin\\ipps.dll", nullptr, LOAD_WITH_ALTERED_SEARCH_PATH);
    
    if (h == 0)
    {
       //126: ERROR_MOD_NOT_FOUND 
       std::cerr << "Error " << ::GetLastError() << std::endl;
    }
    else
    {
       ::FreeLibrary(h);
    }

    return 0;
}

Here ipps.dll and ippcore.dll reside on the same folder.

This folder does not occur in the PATH environment variable, but according to the docs of LOAD_WITH_ALTERED_SEARCH_PATH, ippcore.dll should be found then.

Somehow, when the Windows Loader tries to resolve the dependency from ipps.dll to ippcore.dll, it calls LdrpSearchPath().

This function on its turn calls LdrpComputeLazyDllPath() to generate a path on which ippcore.dll will be searched.

The resultant path equals the original PATH environment variable, prefixed with:

• the path of the calling .exe (i.e. the C++ program at the top of this post)
• some windows folders: 
  • C:\WINDOWS\SYSTEM32
  • C:\WINDOWS\system
  • C:\WINDOWS
• the working directory '.'

Since ippcore.dll resides on none of the folders in the aforementioned extended path, the load fails.