LoadLibray FileNotFound depending on which application calls - c++

Question

I'm trying to impletement a C++ dll named (let's say) name.dll, which loads another dll (not mine) that is also named name.dll.
In my name.dll implementation I'm loading the real name.dll using this line :
driver_library = LoadLibrary(_T("c:\\windows\\system32\\name.dll"));
My dll is in a program.exe.local folder so that the program load mine before the real one in System32.
Depending on which program.exe uses my dll, LoadLibrary either works fine or returns my own name.dll handle as driver_library, with GetLastError() returning "file not found".
In https://msdn.microsoft.com/en-us/library/windows/desktop/ms684175(v=vs.85).aspx it is explicit stated that "If the string specifies a full path, the function searches only that path for the module." Why and how does it load itself for some applications ?
What in the program.exe application could affect LoadLibrary's behavior ?
#Franck Boyne commented :
"You have two programs - let's call them fine.exe and own.exe. The fine.exe program loads your own name.dll and then loads the other name.dll from System32. The own.exe program loads your own name.dll but when it calls LoadLibrary you get back another handle to your own name.dll instead of a handle to the one from System32."
About own.exe (which is not at all my "own" application) :
-> name.dll is located in an own.exe.local folder I created, which is located in own.exe directory.
-> own.exe had an application.manifest file that I deleted (the application still launches correctled without it if not using my dll). own.exe does not have an embedded manifest (checked using sigcheck).
-> name.dll is not one of Windows "known dlls" from HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\KnownDLLs
-> own.exe does not load name.dll using LoadLibrary() (checked by setting a breakpoint into LoadLibrary/A/W/Ex functions)
-> own.exe and name.dll are both 64 bits.
About fine.exe (it's a sample, I have access to the code):
-> name.dll is located in the fine.exe application directory.
-> No manifest file (either embedded or text).

Answer 1

Is it possible your problem program is using DLL Redirection?
From the LoadLibrary documentation (emphasis added) ...
If a path is specified and there is a redirection file for the application, the function searches for the module in the application's directory. If the module exists in the application's directory, LoadLibrary ignores the specified path and loads the module from the application's directory. If the module does not exist in the application's directory, LoadLibrary loads the module from the specified directory. For more information, see Dynamic Link Library Redirection.
Update 6/4/2018
Here's what I think is happening.
Both of your programs are using load-time dynamic linking (sometimes called implicit linking) to link to a DLL called name.dll. I'm assuming both programs just specify name.dll without a full path name. If you want to check I think you can run dumpbin /imports against fine.exe and own.exe to examine the DLL name.
fine.exe
In the case of the program that does what you expect (loads the second name.dll from \Windows\System32) there's no DLL redirection involved so the standard DLL Search Order is followed during the implicit link. The application directory is searched before the system directory so your copy of name.dll gets loaded.
Then your name.dll executes a LoadLibrary call specifying a full path to the file C:\Windows\System32\name.dll. Since there's no redirection going on, the system directory version of name.dll gets loaded as you expect.
own.exe
In the case of the program that doesn't do what you expect (gets a handle to your own version of name.dll twice) there is DLL redirection going on because you have a directory called own.exe.local in the application folder. Since there's redirection going on, during the implicit link the standard search order is ignored and name.dll is loaded from own.exe.local.
Then your name.dll executes a loadlibrary call specifying a full path to the file C:\Windows\System32\name.dll. But this time there is redirection going on. The full path specified in the LoadLibrary call is ignored and the module is loaded from the redirection folder own.exe.local.
Since that copy of name.dll has already been loaded by the implicit linking you just get another handle to the module.
As was pointed out in the comments, the GetLastError result is misleading. The LoadLibrary call didn't return NULL (it returned a handle to your own name.dll) so the value returned by GetLastError doesn't apply to the LoadLibrary call.