Loading symbols from a DLL loaded with a non-standard path that forward to another DLL

Question

I'm trying to dynamically load a DLL (python3.dll) which isn't on the normal search path. I can load it with an altered search path, but when I do GetProcAddress, it's failing (because the function I'm loading forwards to another DLL, python37.dll).

I think what I need to do is get GetProcAddress to follow the same search logic as in my original DLL load, but I don't know how to so that without altering the system PATH (which has all sorts of other potential issues, as my code goes on to let the user run their own code, which needs the original path).

Is there a clean solution for this?

Here's the code I tried:

HMODULE py_dll = LoadLibraryW(L"python3.dll");
if (!py_dll) {
    py_dll = LoadLibraryExW(L"C:\\Work\\Projects\\pylaunch\\py3embed\\python3.dll", NULL, LOAD_WITH_ALTERED_SEARCH_PATH);
}

if (!py_dll) {
    printf("Cannot load Python DLL\n");
    err();
    return 1;
}
char buf[1000];
GetModuleFileName(py_dll, buf, 1000);
printf("DLL is %s\n", buf);
Py_Main_t Py_Main = (Py_Main_t)GetProcAddress(py_dll, "Py_Main");
if (!Py_Main) {
    printf("Cannot load Py_Main\n");
    err();
    return 1;
}

Adding SetDllDirectory() didn't seem to help, but I just dumped a call to it into the code, as I wasn't 100% clear on how it worked, so it's possible I did something wrong.

For reference, the definition of the Py_Main symbol is

 747  2EA          Py_Main (forwarded to python37.Py_Main)

Answer 1

It appears that this is a problem with Windows 7. The discussion here gives more details.

Basically, GetProcAddress doesn't appear to respect changes to the search path using SetDllDirectory when loading additional DLLs to resolve forwarded symbols. If the DLL containing the forwarding symbol has a dependency on the target DLL, it does work, but python3.dll doesn't have such a dependency.

From a report in the Python issue linked above, it appears that this behaviour has been fixed in Windows 10, so you need to be on Windows 7 to see the problem.

The solution seems to be to update Windows, or avoid using GetProcAddress with forwarded functions (unless the forwarder has a dependency on the target).