Change DLL dependency

Question

I am trying to compile a testprogram for libpqxx on Visual Studio 2019, unfortunately, after a check with Dependency Walker, some of the DLLs I need are dependent on the 64-bit version, the dependency path leads to the System32 folder instead of to the same named files in SysWOW64. Now I have no idea how to change the paths for the DLLs so I can get the program running. Is there a way to change the dependency paths for the DLLs I need?

Thanks in advance!

edit:

When I try to run the program I get the error messages "libssl-1_1.dll" and "libcrypto-1_1.dll" are missing. When I add them to the project folder, the project gets built and the program gets stopped right away, with the message "the application was unable to start correctly 0xc00007b". Assuming that the problem comes from dependent x64 DLLs I checked the DLLs used by Visual Studio with Dependency Walker and there are a lot of dependent ones that are x64 and located in the System32 folder.

ntdl.dll - fine
kernel32.dll -
    c:\windows\system32\KERNELBASE.DLL
    c:\windows\system32\NTDLL.DLL
    c:\windows\system32\BCRYPTPRIMITIVES.DLL
    c:\windows\system32\NSI.DLL
    c:\windows\system32\RPCRT4.DLL
    c:\windows\system32\WS2_32.DLL

KernelBase.dll-
    c:\windows\system32\NTDLL.DLL

ws2_32.dll-
    c:\windows\system32\KERNELBASE.DLL
    c:\windows\system32\NTDLL.DLL
    c:\windows\system32\RPCRT4.DLL
    c:\windows\system32\BCRYPTPRIMITIVES.DLL
    c:\windows\system32\NSI.DLL
    c:\windows\system32\WS2_32.DLL

rpcrt4.dll-
    c:\windows\system32\KERNELBASE.DLL
    c:\windows\system32\NTDLL.DLL
    c:\windows\system32\RPCRT4.DLL
    c:\windows\system32\BCRYPTPRIMITIVES.DLL
    c:\windows\system32\NSI.DLL
    c:\windows\system32\WS2_32.DLL

msvcp140d.dll-
    c:\windows\system32\KERNELBASE.DLL
    c:\windows\system32\NTDLL.DLL
    c:\windows\system32\RPCRT4.DLL
    c:\windows\system32\BCRYPTPRIMITIVES.DLL
    c:\windows\system32\NSI.DLL
    c:\windows\system32\WS2_32.DLL

vcruntime140d.dll-
    c:\windows\system32\KERNELBASE.DLL
    c:\windows\system32\NTDLL.DLL
    c:\windows\system32\RPCRT4.DLL
    c:\windows\system32\BCRYPTPRIMITIVES.DLL
    c:\windows\system32\NSI.DLL
    c:\windows\system32\WS2_32.DLL

ucrtbased.dll- fine

So these are the DLLs and the dependencies that are 64-bit. Am I correct in that is what causes the problem? Do I need to change any dependencies to 32-bit?

Dump of file C:\...\libpq.dll

PE signature found

File Type: DLL

FILE HEADER VALUES
             14C machine (x86)

Dump of file C:\...\lib\libpq.lib

File Type: LIBRARY

FILE HEADER VALUES
             14C machine (x86)

Dump of file C:\...\lib\pqxx.lib

File Type: LIBRARY

FILE HEADER VALUES
             14C machine (x86)

dependencies from dumpbin /dependents

kernel32.dll-
    ntdll.dll
    KERNELBASE.dll
    bunch of api-ms-win-core
    ext-ms-win-oobe-query-l1-1-0.dll
    RPCRT4.dll

KernelBase.dll-
    bunch of ext-ms-win
    ntdll.dll
    api-ms-win-eventing-provider-l1-1-0.dll

ws2_32.dll-
    bunch of api-ms-win-core
    ntdll.dll
    RPCRT4.dll

rpcrt4.dll-
    ntdll.dll
    KERNELBASE.dll
    bunch of api.ms.win

msvcp140d.dll-
    CONCRT140D.dll
    VCRUNTIME140D.dll
    ucrtbased.dll
    KERNEL32.dll

vcruntime140d.dll-
    ucrtbased.dll
    KERNEL32.dll

ucrtbased.dll-
    bunch of api-ms-win-core

System32 *is* where the 64-bit DLLs are, SysWOW64 has the 32-bit ones. Whatever the problem is, it's not about Windows mistakenly loading the wrong bitness of DLLs because that does not and cannot happen. Check the settings of your build and the libraries you link against for consistency. — dxiv, Oct 28 '20 at 23:24
But the question says "*some of the DLLs I need are dependent on the 64-bit version*". Regardless, the bitness of the DLLs you need is determined by your build, and whether/where the problem is with the build cannot be guessed since you provided no context or details. — dxiv, Oct 29 '20 at 00:46
Oh I see, a little poor wording. I checked the DLL files that Visual Studio uses with Dependency Walker and saw that some of the DLLs are dependent on other, 64-bit, DLLs from the system32 folder, instead of using them from the sysWOW64 folder. Therefore my thinking was that this is causing the "the application was unable to start correctly 0xc00007b" error and I need to find a way to have them find the DLLs from the sysWOW64 instead. — Pascal G, Oct 29 '20 at 00:56
There is no "*instead of*". The DLLs in System32 *are* the 64-bit ones, and those in SysWOW64 could not be used anyway since they are 32-bit. The problem is most likely that you link by mistake to a 32-bit library in a 64-bit build, or the other way around but, again, it's impossible to tell for sure without knowing the details. Search for 0xc000007b and you'll find several examples of such mixups. — dxiv, Oct 29 '20 at 01:36
Ok, I read in other places that for this error the DLLs should be checked via Dependency Walker because that could cause the issue. The libraries I link are libpq, which I got from the 32-bit download from PostgreSQL 10, the libpqxx.lib which I built for the VS compiler and WS2_32.lib. When I try to run the testprogram from the libpqxx doc the build is successful but as soon as the console pops up I get the 0x00007b error message. So to be clear, the dependencies of the linked DLLs can't be the problem here? I'm kinda out of ideas otherwise. — Pascal G, Oct 29 '20 at 01:50
Since you are using a prebuilt 32-bit library, make sure that everything *you* built was compiled with the target platform set to 32-bit x86. Also make sure that any DLLs you copied to the program directory are the same/correct bitness i.e. 32-bit. You shouldn't have copied anything to the PATH, least of all to the System32/SysWOW64 directories, but if you did then undo it. After all this, if you still find a reference to a 64-bit DLL, follow it and track down *where* it comes from. — dxiv, Oct 29 '20 at 02:46
I undid and checked it all, built the library in 32-bit again and still the same errors and dependency walker check. I guess I'll open a new question with all the details. Thanks for your help! — Pascal G, Oct 29 '20 at 20:01
You can click the [edit](https://stackoverflow.com/posts/64582650/edit) link under this question and add the necessary details here. — dxiv, Oct 29 '20 at 20:14
Also a good idea, I edited and added some more context now, hope this is enough. — Pascal G, Oct 29 '20 at 20:35
Where in Dependency Walker are you looking to determine the load path? Run it from VS with F5 (Debug / Start) and the Output window will display the full path of each module as they are loaded. And you still don't say if you checked the modules to make sure all are 32-bit compiles. You could use for example [dumpbin](https://superuser.com/a/358459) for that. — dxiv, Oct 29 '20 at 21:15
Yeah the libs are 32-bit, I added the dumpbin output in the post. In the dependency walker I looked up all the dlls i got from the visual studio debugging console and copypasted the paths below "Module" in the post above. "CPU" section on the right says "x64" too. — Pascal G, Oct 29 '20 at 21:40
The paths you see there are not reliable as far as 32b/64b [folder redirection](https://learn.microsoft.com/en-us/windows/win32/winprog64/file-system-redirector) goes. Use `dumpbin` to determine bitness and static/import dependencies, use [Process Explorer](https://learn.microsoft.com/en-us/sysinternals/downloads/process-explorer) and/or [Process Monitor](https://learn.microsoft.com/en-us/sysinternals/downloads/procmon) to collect dynamic/load-time information. Beyond that, there is not enough context and detail to go on. — dxiv, Oct 30 '20 at 02:59
I've edited the dependencies from I got from dumpbin. I checked them all with /headers and they are all x86, checked the api and ext ones too, all x86. I'm not really sure what to look for in the process monitor, I started the program in VS and then get a lot of deven.exe processes from VS, some of them show "Result: Name not found" with "Desired Access: Read". I gets ntdll.dll from both system32 and syswow64, which should be ok i guess. Otherwise it gets its DLLs mostly from syswow64, from system32 it gets "wow64.dll" "wow64cpu.dll" and "wow64win.dll". — Pascal G, Oct 30 '20 at 21:49
ProcMon can tell you where Windows is looking for the dependent DLLs, and ProcExp can tell you what gets actually loaded. Assuming you checked everything right and all dependents are 32-bit as they should be, the problem may not even be about a 64-bit mixup after all. Nobody can guess, though, unless you provide an actual [MCVE](https://stackoverflow.com/help/minimal-reproducible-example) with code, project settings and a step-by-step of what it takes to make it happen. — dxiv, Oct 31 '20 at 00:18
Alright, I really hate to give up but that looks like it is going nowhere. I think I will use another Database tool then. Thanks a lot for your help, really learned a lot from this. I wish you all the best. — Pascal G, Oct 31 '20 at 01:20

Change DLL dependency

0 Answers0