LoadLibrary on DLL file that's not on disk

I need to download a DLL from a web site on an Intranet and call an exported function in it.  The client cannot leave temp files around.

>>The client cannot leave temp files around.

Why not?  Most systems today have megabytes of temp files lying about all over the place.  

I also don't understand why you can't delete the DLL when you are finished with it.  The file should be free to be deleted after you call FreeLibrary() on it.  But I'll have to admit that I've not tried this.

You know what, this is why I didn't originally state the reason behind it.

I am looking for a technical solution not someone's opinion of what I ought to do or not do.  Keep your opinions to yourself if you don't have a constructive solution to my problem.

I am only looking for technical answers -- I am not interested in whether you feel I should or shouldn't do something.

Thank you!

Regards,
    Thanks.  I'll give you more info on not being able to delete the DLL.  Okay, the new DLL is called temp.dll.  I have another DLL call main.dll.  Say a process implictly loads main.dll (by linking to main.lib, the import library).  When the process is invoked, main.dll's DllMain() gets called.  In there, in the "process attach", I create temp.dll and call LoadLibrary on it, caching the returned hinstance.  When the process terminates, it calls main.dll's DllMain() with "process detach".  In there, I call FreeLibrary on the cached hinstance of temp.dll and verify that no one else has the DLL loaded.  Right after the call to FreeLibrary, I attempt to delete temp.dll, but it fails.  However, if the process invokes some well-known routine in main.dll, which in turns does the same logic as above, calling FreeLibrary on the hinstance, then temp.dll *can* be deleted.

I believe that the same behavior occurs when the process loads main.dll explictly (via a call to LoadLibrary).

Now, I did this first about 6 years ago and at the time I was testing under NT 3.51 and the newly released Windows 95 and don't recall if the behavior was on both systems.  Suffice it to say, the solution should work on all Win32 systems.

Thanks for madCodeHook -- I'll check it out.

FengYuan,
     I'm not sure if reimplementing much of the loader is really the best strategy -- I wouldn't really know where to start doing something like that.

>> In there, I call FreeLibrary on the cached hinstance of temp.dll and verify that no one else has the DLL loaded.

Please call GetModuleFileName(cachedhinstance) before calling FreeLibrary to verify that the cached hinstance is correct (probably it is, just to be sure). Then please after having called FreeLibrary call GetModuleHandle('test.dll') to check whether the dll is still loaded. It should not.

>> Right after the call to FreeLibrary, I attempt to delete temp.dll, but it fails.

What does GetLastError say?

Regards, Madshi.

Hi FengYuan,

hmmm... what if the dll internally calls GetModuleFileName with its own HInstance value to find out the full path where the dll file is loaded from? That call would fail, would it not? I mean, your suggestion is not guaranteed to work with all dlls, some dlls might not work correctly because GetModuleFileName (and related APIs) fail, or am I wrong? Apart from that I do like your suggestion...

Regards, Madshi.

I like it!  I'll try this out in a test project and let you guys know.

Good link, Zoppo! What does that mean? It's evidently not recommended to do any LoadLibrary/FreeLibrary calls in DllMain within PROCESS_ATTACH/DETACH events. So the solution to the problem is "simply" to do the loading & freeing at another location in your program.

Regards, Madshi.

>>>I am looking for a technical solution not someone's
>>>opinion of what I ought to do or not do.  Keep your
>>>opinions to yourself if you don't have a constructive
>>>solution to my problem.

>>>I am only looking for technical answers -- I am not
>>>erested in whether you feel I should or shouldn't
>>>do something.


Well just EXCUSE ME for trying to understand your problem and help!@

6. Dummy DLL.

   6.1 Wipe out code/data in the DLL.
   6.2 Write to disk.
   6.3 LoadLibrary the DLL.
   6.4 Restore old code/data.

www.fengyuan.com

There is no way to really free another dll inside DLL_PROCESS_DETACH, so the bat file is the only option, in my humble opinion. CreateProcess() should use DETACHED_PROCESS of course.

This solution is a universal one for any vesion of Windows, and it is much more reliable that any API interception - detour etc.

Of course if you have time you can improve your skills by writting URL monikers or network redirectors. The only disadvantage is that they are separate programs that need to be distributed, installed etc.

As to the memory-based DDLs, I wish this could be possible. Unfortunately the 100% emulation is not possible, at least without a need to hack Windows. It means this way is not reliable as well.

Thanks Nick.
The batch file way is my current approach.  I actually use a tiny win16 program that gets launched and waits and tries 256 times to delete a given exe.  It's win16 because the same solution was used for both win16/win32 programs (yes, this is old code.)

Madshi,
     Your madCodeHook looks pretty awesome.  I'll give it a try.  If it works, I'll use that approach.  I'll let you know.

Thanks.

Madshi,
     Your madCodeHook looks pretty awesome.  I'll give it a try.  If it works, I'll use that approach.  I'll let you know.

Thanks.

my earlier code snippet - shows that FreeLibrary does unload the dll - I even experimented by adding GetProc addresses and calling code before calling FreeLibrary - still unloaded and deleted.

do you have anything else in your code keeping the library loaded or file locked? Have you closed all the handles that you used to create the file on the disk?

Shaunn, when you posted the comment of which you speak, it was obvious that you didn't read the previous comments because there I explained the conditions under which FreeLibrary wasn't working with me.  I didn't bother to respond to you because I just got through explaining it in a comment prior to yours.

Then, another user, Zoppo, confirmed my findings by posting the knowledgebase article describing the scenario.

Did you miss that comment, too?

Some thoughts:

(1) Are both the process and the main.dll written by you? Then why don't you simply export a function from main.dll, which unloads and deletes test.dll. You can then call this exported function from the process, before you close the process. That would be by far the easiest and cleanest solution (at least IMHO).

(2) If you want to play with madCodeHook, I would suggest using a different approach then the one you thought about. Simulating a DLL load from memory is too difficult, I think. Why not hooking PostQuitMessage and ExitProcess? You can then in the callback function unload the test.dll and delete it - and then thereafter call continue with PostQuitMessage/ExitProcess. However, I think this is overkill. I like (1) much more. Or alternatively Nick's batch solution.

Regards, Madshi.

Shaun, as far as I understand your code (I'm not too sure, because I'm a Delphi programmer) you're doing all the stuff in the initialization of an application. The problem that shrif has occurs in the finalization of a dll. That are quite different things.

Shrif

> it was obvious that you didn't read the previous
> comments because there I explained the conditions under
> which FreeLibrary wasn't working with me

I was responding to the comment

<snip>

4.  Write the memory contents to disk and then call LoadLibrary.
   NEGATIVES:  There's no way to delete the file after calling LoadLibrary on it.  At least it didn't
work when I tried it (yes, I called FreeLibrary on it.)

</snip>


the fact I missed your ramble about app -> dll -> dll - was due to the fact I didn't refresh seeing the question - and then posting the comment

However since the comment about not using FreeLibrary in DllMan is mentioned in the helpfile see FreeLibrary (which I assumed you read) and that you didn't respond to Zoppos comment - I assumed that it didn't apply in your case

so no it wasn't obvious that I hadn't read the above comments quite the opposite - I had read them but misinterprted you lack of response to other comments

The fact is you might as well do what madshi suggested and rework your code - something jhance would have mentioned earlier - eg tell us what you want to do and we'll see how to do it - rather then go a really complex route - a slight rework of your code would be a lot easier

There is another possibility, but it is a hack.

UnmapViewOfFile(LPCVOID(hTempDll));
CloseHandle(hSomeInternalFileHandleForTempDll);
DeleteFile("temp.dll")

hSomeInternalFileHandleForTempDll is a file handle which is obtained via CreateFile("Temp.Dll") by Windows loader. It is possible to enumerate all opened handles and find the handle which is associated with a given file name.

This works on my NT4

#include <windows.h>
#include <iostream.h>
#include <conio.h>

void main()
{
   HINSTANCE hTempDll=LoadLibrary("b.dll");
   if(!hTempDll)
   {
      cout<<"Cannot load DLL"<<endl;
      return;
   }

   CHAR buf[MAX_PATH];
   GetModuleFileName(hTempDll,buf,sizeof(buf));

   if(!DeleteFile(buf))
   {
      cout<<"1st DeleteFile failed - as expected"<<endl;
   }

   UnmapViewOfFile(hTempDll);
   
   if(DeleteFile(buf))
   {
      cout<<"Deleted!"<<endl;
      FreeLibrary(hTempDll);
   }
}