Hello!

I have done a proxy dll called user32.dll.
When you load it, it loads the system version of user32.dll,
and every call to functions in that
dll will be transferred to calls in the system dll, also
called user32.dll.
The problem is that the DLL is never loaded, even if it is
in the same directory as the exe-file
that is supposed to use it. The exe-file has static linkage
to the dll, and is only named as USER32.dll in the exe-file
image.

My proxy dll called kernel32.dll is giving the same results.
It is never used. The host application uses the system
version of kernel32.dll even if a kernel32.dll is in the
same directory as it.

However, when I did wsock32.dll and ws2_32.dll, the
application used them instead of the system variants!
(I have put a Beep in DllMain so I can tell).

Is this a dllcache thing, or what is it?

This problem also arises if I load DLL:s dynamically, with
LoadLibrary.

/Anders

Here's what happening as I suspect.
When your EXE loads USER32.dll, system directory is searched 1st: BEFORE
current directory. So, default version of USER32.dll being loaded.
It's very difficult to overwrite a system DLL, because those DLLs are in use
at all times (after OS was loaded).
I suggest the following test:

In you EXE hardcode LoadLibrary() path for USER32.dll as 'c:\temp'. You
should be able to load your DLL that way, because when you specify path it's
used before any default directories.

Boris

"Anders Lindén" <nomail@nomail.nomail> wrote in message
news:3fe8ea3a$1@puffinus.its.uu.se...

"Anders Lindén" <nomail@nomail.nomail> wrote in message news:<3fe8ea3a$1@puffinus.its.uu.se>...
What did you do that for?

user32 and kernel32 are two of the system dlls that are only ever
loaded once (look in the registry for "KnownDlls")

"Boris Dynin" <spam@noplease.com> wrote in message
news:uuOGb.4970$XF6.109429@typhoon.sonic.net...

But in the help page for LoadLibrary sais that:

When no path is specified, the function searches for the
file in the following sequence:

1. The directory from which the application loaded.
2. The current directory.
3. Windows 95: The Windows system directory. Use the
GetSystemDirectory function to get the path of this
directory.

Windows NT: The 32-bit Windows system directory. Use the
GetSystemDirectory function to get the path of this
directory. The name of this directory is SYSTEM32.

4. Windows NT: The 16-bit Windows system directory. There is
no Win32 function that obtains the path of this directory,
but it is searched. The name of this directory is SYSTEM.
5. The Windows directory. Use the GetWindowsDirectory
function to get the path of this directory.
6. The directories that are listed in the PATH environment
variable.



Note that I have also been able to have a proxy dll for
winsock32.dll even if another application had loaded that
dll meanwhile.




/Anders

"Dim St Thomas" <dimstthomas@yahoo.com> wrote in message
news:1e94d380.0312252041.786aa98@posting.google.co m...
Because I want to log the calls to functions in that DLL:s.


Aha, that may be the answer! Seems like the rules for DLL
loading are more intricate that I first thought.


/Anders

"Dim St Thomas" <dimstthomas@yahoo.com> wrote in message
news:1e94d380.0312252041.786aa98@posting.google.co m...
I tried to remove DLL:s from that registry key
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Contro l\Session
Manager\KnownDLLs
and reboot.

The dll imagehlp.dll was still treated differently, even if
I had removed its key under the mentioned key.

I also tried the with
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Curr entVersion
\SharedDLLs
but that entries are probably there to see how many
applications that uses a certain DLL and nothing else.
When I had rebooted, it was all the same as before.

still out of luck then, it seems
/Anders

Right. It seems I was wrong.
See also Q164501: "
INFO: Windows NT/2000/XP Uses KnownDLLs Registry Entry to Find DLLs
".

Boris
"Anders Lindén" <nomail@nomail.nomail> wrote in message
news:3fec448b$1@puffinus.its.uu.se...

"Anders Lindén" <nomail@nomail.nomail> wrote in message news:<3fec78f3$1@puffinus.its.uu.se>...
<http://www.microsoft.com/technet/security/bulletin/ms99-006.asp>