InjectLibrary fails if DLL is on a mapped network drive

consolo · Post by **consolo** » Thu Apr 06, 2006 7:20 pm

Hi,

if I try to InjectLibrary with a DLL which lies on a mapped network drive (the DLL is on a shared network drive of a different PC which is mapped to local d:\) it fails with LastError = 126 ("das angegebene Modul wurde nicht gefunden").

If I copy the DLL to a local drive everything works fine.

Can I somehow work around this restriction?

thanks,
carsten

PS: I need this to use my original source codes inside a VMWare-Machine on the same PC => so it is not only a theoretical problem. Of course I could always copy the complete sources on a local drive of the VM, but this would slow down development a lot.

Post by **madshi** » Fri Apr 07, 2006 8:12 am

Do you inject into one process only or system wide?

consolo · Post by **consolo** » Fri Apr 07, 2006 10:26 am

intp process only, like

InjectLibrary (hProcess, sFullPathToDLL, tTimeOut * 1000)

carsten

Post by **madshi** » Fri Apr 07, 2006 10:36 am

Does LoadLibrary return success with the same path?

consolo · Post by **consolo** » Fri Apr 07, 2006 10:58 am

You mean when the injected application and the DLL to be injected are on the same network path?

Sorry, but I can only check these only on monday => I will post result here

thx for your help

Post by **madshi** » Fri Apr 07, 2006 11:24 am

No, I mean what happens when your app calls LoadLibrary instead of InjectLibrary. Does LoadLibrary succeed?

consolo · Post by **consolo** » Tue Apr 11, 2006 1:47 am

Hi,

thx for your answer. I do not understand what is happening here, as LoadLibrary works well. Also Injecting into some processes work, only injecting into the services.exe brings the described problem.

I am very sorry, but actually I can not find the time to work on this project. Thx for your help, perhaps later you will find again time, when I can make more tests and report them here.

carsten

Post by **madshi** » Tue Apr 11, 2006 6:27 am

consolo wrote:Also Injecting into some processes work, only injecting into the services.exe brings the described problem.

Most probably this is nothing but an access rights problem. Services.exe runs under a different user account. So probably the network share simply refuses access for this process.

consolo · Post by **consolo** » Tue Apr 11, 2006 12:40 pm

Arghh, that seams very plausible -> I will have a check ..