InjectLibrary fails if DLL is on a mapped network drive
InjectLibrary fails if DLL is on a mapped network drive
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.
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.
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
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
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 wrote:Also Injecting into some processes work, only injecting into the services.exe brings the described problem.