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
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
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
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