[Bug 14699] New:=?UTF-8?Q?=20DLL=20loading=20prolem=20when=20injecting=20into=20another=20process=E2=80=8F?=

http://bugs.winehq.org/show_bug.cgi?id=14699

Summary: DLL loading prolem when injecting into another
                    process‏
           Product: Wine
           Version: 1.1.2
          Platform: PC
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P2
         Component: kernel32
        AssignedTo: [e-mail]
        ReportedBy: [e-mail]

I have observed a DLL loading prolem when injecting into another process.

For example,

In folder C:\DirA, I have A.exe which is linked to B.dll, and B.dll is linked
to C.dll.
B.dll and C.dll are in same folder as A.exe.

If I run A.exe, B.dll and C.dll will be loaded without problem since they are
in same folder.

Support there is a process running C:\DirX\X.exe, and C:\DirX\ is not the
current folder and 
it's not on PATH.

Now I inject B.dll from A.exe into process X.exe, the System will map
C:\DirA\B.dll into process X.exe.

Since B.dll is linked to C.dll, the system will try to load C.dll for process
X.exe. But because C.dll is not in same folder of process X.exe, wine failed to
load C.dll for X.exe. This cause DLL injection to fail.

Wine rror message:

err:module:import_dll Libary C.dll (which is needed by L"C:\DirA\B.dll) not
found.

Windows does not have this problem. So I am trying to find a solution.

I think when processing the imports for C:\DirA\B.dll to load C.dll, it should
try C:\DirA\C.dll first,
then form the standard load locations.

I think it should call load_library( "C:\DirA\C.dll ",
LOAD_WITH_ALTERED_SEARCH_PATH)
so C.dll can be loaded into C:\DirX\X.exe process.

I may also look into import_dll where the error occured.

[Bug 14699]=?UTF-8?Q?=20DLL=20loading=20prolem=20when=20injecting=20into=20another=20process=E2=80=8F?=

http://bugs.winehq.org/show_bug.cgi?id=14699

--- Comment #1 from Hongbo Ni   2008-08-01 02:00:14 ---
Rolf Kalbermatter (r.kalbermatter-at-hccnet.nl) describe the problem in another
way which is easier to understand.

"Not sure about what you mean with injecting here but in normal
applicationoperationwhen loading a DLL explicitedly from a specific directory
(which is not thecurrentdirectory nor the application directory or one of the
standard searchpaths), Windowswill not resolve to other DLLs implicitedly
loaded by that DLL eventhoughthey are inthe same directory than the referencing
DLL."

Basically it says, if your application X in c:\DirX\ calls 
LoadLibrary('c:\DirA\B.dll');

It will fail under Wine since it can not find C.dll.

[Bug 14699]=?UTF-8?Q?=20DLL=20loading=20prolem=20when=20injecting=20into=20another=20process=E2=80=8F?=

http://bugs.winehq.org/show_bug.cgi?id=14699

--- Comment #2 from Hongbo Ni   2008-08-06 22:33:14 ---

DLL load problem described by Rolf Kalbermatter (r.kalbermatter-at-hccnet.nl) 
can be easily solved by calling

LoadLibraryExW("c:\DirA\A.dll", NULL, LOAD_WITH_ALTERED_SEARCH_PATH);

I have located the problem in my first post to SetWindowsHoolEx,
so I filed a more specific bug 17784.

http://bugs.winehq.org/show_bug.cgi?id=14784

This bug is closed.

[Bug 14699]=?UTF-8?Q?=20DLL=20loading=20prolem=20when=20injecting=20into=20another=20process=E2=80=8F?=

http://bugs.winehq.org/show_bug.cgi?id=14699

Hongbo Ni  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |DUPLICATE

--- Comment #3 from Hongbo Ni   2008-08-06 22:37:13 ---
problem is in user32.

*** This bug has been marked as a duplicate of bug 14784 ***

[Bug 14699]=?UTF-8?Q?=20DLL=20loading=20prolem=20when=20injecting=20into=20another=20process=E2=80=8F?=

http://bugs.winehq.org/show_bug.cgi?id=14699

Dmitry Timoshkov  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED

--- Comment #4 from Dmitry Timoshkov   2008-08-07 00:04:36 ---
Closing dup.