Click here to Skip to main content
Click here to Skip to main content
Go to top

Loading Win32/64 DLLs "manually" without LoadLibrary()

, 8 Mar 2014
Rate this:
Please Sign up or sign in to vote.
How to load DLLs by allocating memory and loading the DLL from file/memory and then relocating/importing.

Introduction

Sooner or later many people start thinking about loading a DLL without LoadLibrary(). OK, maybe not so many... It has only a few advantages and can introduce lots of inconvenience problems when coding the DLL (depending on what your DLL does) compared to a situation where you load the DLL with an ordinary LoadLibrary() call, so this technique has limited use. (I will aim the inconvenience problems below.) Still this tip can make good service as a tutorial if you want to understand what's going on behind the curtains... I myself used this stuff to write DLLs in C/C++ instead of coding offset independent assembly (in an anticheat engine), but that is another story.

Implementation

The most important steps of DLL loading are:

  1. Mapping or loading the DLL into memory.
  2. Relocating offsets in the DLL using the relocating table of the DLL (if present).
  3. Resolving the dependencies of the DLL, loading other DLLs needed by this DLL and resolving the offset of the needed functions.
  4. Calling its entrypoint (if present) with the DLL_PROCESS_ATTACH parameter.

I wrote the code that performed these steps but then quickly found out something is not OK: This loaded DLL doesn't have a valid HMODULE/HINSTANCE handle and many windows functions expect you to specify one (for example, GetProcAddress(), CreateDialog(), and so on...). Actually the HINSTANCE handle of a module is nothing more than the address of the DOS/PE header of the loaded DLL in memory. I tried to pass this address to the functions but it didn't work because windows checks whether this handle is really a handle and not only the contents of memory! This makes using manually loaded DLLs a bit harder! I had to write my own GetProcAddress() because the windows version didn't work with my DLLs. Later I found out that I want to use dialog resources in the DLL and CreateDialog() also requires a module handle to get the dialog resources from the DLL. For this reason I invented my custom FindResource() function that works with manually loaded DLLs and it can be used to find dialog resources that can be passed to the CreateDialogIndirect() function. You can use other types of resources as well in manually loaded DLLs if you find a function for that resource that cooperates with FindResource(). In this tip you get the code for the manual DLL loader and GetProcAddress(), but I post here the resource related functions in another tip.

Limitations

  1. The loaded DLL doesn't have a HMODULE so it makes life harder especially when its about resources.
  2. The DllMain() doesn't receive DLL_THREAD_ATTACH and DLL_THREAD_DETACH notifications. You could simulate this by creating a small DLL that you load with normal LoadLibrary() and from the DllMain() of this normally loaded DLL you could call the entrypoint of your manually loaded DLLs in case of DLL_THREAD_ATTACH/DLL_THREAD_DETACH.
  3. If your DLL imports other DLLs, then the other DLLs are loaded with the WinAPI LoadLibrary(). This is actually not a limitation, just mentioned it for your information. Actually it would be useless to start loading for example kernel32.dll with manual dll loading, most system DLLs would probably disfunction/crash!
  4. DLLs that make use of SEH *may* fail. The fact that the DLL contains SEH related code alone isn't a problem but the __try blocks in the loaded DLL won't be able to catch the exceptions because the ntdll.dll!RtlIsValidHandler() doesn't accept exception handler routines from the memory area of our manually loaded DLL (because this memory area isn't mapped from a PE file). This is a problem only if an exception is raised inside a __try block of the DLL (because windows can't run the exception handler of the DLL and raises another exception that escapes the exception handler of the DLL - the result is usually a crash).
  5. Whether the CRT works with manual DLL loading or not depends on several things. It depends on the actual CRT version you are using and the functions you call from the CRT. If you are using just a few simple functions (like printf) then the CRT may work. I've written my DLLs with /NODEFAULTLIB linker option that means you can't reach CRT functions and it reduces your DLL size considerably (like with 4K intros). But then you have to go with pure WinAPI! This can be quite inconvenient but you can overcome this by writing your own mini CRT. I've provided one such mini CRT in my C++ example without attempting to be comprehensive but it at least allows you to use the most basic C++ features: automatically initialized static variables, new/delete operators. BTW, if you are about to use this code then you should understand most of these problems and you should appreciate that writing C/C++ DLL without CRT is still much more convenient than writing something as an offset independent or relocatable assembly patch.

Using the code

Write your DLL in C/C++. If you don't want to use the default CRT then link with /NODEFAULTLIB. It's a good practice to write your code so that a define can switch between original windows LoadLibrary() and the manual loader I provided (in my example solution you can do this by switching to the "Debug LoadLibrary" configuration). This way you can easily test whether a bug or crash happens because of manual loading or not and an additional benefit of being able to switch to the original windows LoadLibrary() is that you can debug the code of the DLL only that way (as the debugger identifies code only inside normally loaded modules).

With my manual loader you have to use my custom GetProcAddress() on the loaded DLL. If you want to use dialog resources (or some other kind of resource, but dialog is the most common) then you can use the FindResource() function I provided in one of my other tips (and the CreateDialogIndirect WinAPI function) because that works with both normally and manually loaded DLLs: The inner working of FindResource() and LoadString() Win32 functions. Download the attached VC++2010 solution that contains a sample program that loads and uses 2 DLLs. One DLL has been written in C and the other in C++.

History:

  • Around 2000: The first spaghetti version of this code has born (Win32-only).
  • 2012 July: Publication on codeproject in its original form.
  • 2013 Sept: De-spaghettization of the code, adding 64 bit support and an example VC++2010 solution with DLL loading example with DLLs written in C and C++. The C++ DLL contains a mini home grown CRT.

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Share

About the Author

pasztorpisti
Software Developer (Senior) CRYTEK
Hungary Hungary
No Biography provided

Comments and Discussions

 
QuestionDebug question PinmemberTsury23-Jun-14 2:47 
AnswerRe: Debug question Pinprofessionalpasztorpisti23-Jun-14 4:06 
Questionfor getprocaddress etc to work Pinmemberevlncrn819-Apr-14 4:09 
AnswerRe: for getprocaddress etc to work Pinprofessionalpasztorpisti19-Apr-14 5:37 
QuestionIt doesn't work on 64bit PinmemberTinnyTonny16-Apr-14 15:51 
AnswerRe: It doesn't work on 64bit Pinprofessionalpasztorpisti17-Apr-14 4:44 
BugLoadDLL_ResolveImports Pinmemberjiang.jianjun7-Mar-14 15:33 
GeneralRe: LoadDLL_ResolveImports Pinmemberpasztorpisti8-Mar-14 1:04 
Questionhow to debug the crash dll Pinmember396963622-Nov-13 1:09 
AnswerRe: how to debug the crash dll Pinmemberpasztorpisti22-Nov-13 4:30 
Question16 bits dlls PinmemberMember 1024821724-Sep-13 12:11 
AnswerRe: 16 bits dlls Pinmemberpasztorpisti24-Sep-13 12:19 
GeneralInteresting - well done PinmvpEspen Harlinn22-Sep-13 13:40 
QuestionLoading from memory PinmvpMichael Haephrati22-Sep-13 9:24 
AnswerRe: Loading from memory Pinprofessional Randor 23-Sep-13 20:37 
GeneralRe: Loading from memory Pinmemberpasztorpisti23-Sep-13 22:29 
GeneralMy vote of 5 PinmvpMichael Haephrati22-Sep-13 9:17 
QuestionExcellent Article PinmemberKozmoKAllDay4-Sep-13 19:10 
AnswerRe: Excellent Article Pinmemberpasztorpisti4-Sep-13 21:39 
AnswerRe: Excellent Article Pinmemberpasztorpisti5-Sep-13 22:43 
QuestionWarning PinmemberShawn-USA5-Aug-13 14:30 
AnswerRe: Warning Pinmemberpasztorpisti5-Aug-13 22:19 
GeneralRe: Warning PinmemberShawn-USA6-Aug-13 7:41 
GeneralRe: Warning Pinmemberpasztorpisti6-Aug-13 8:05 
QuestionIs it possible? Pinmemberbejglee23-May-13 2:02 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

| Advertise | Privacy | Mobile
Web02 | 2.8.140916.1 | Last Updated 8 Mar 2014
Article Copyright 2012 by pasztorpisti
Everything else Copyright © CodeProject, 1999-2014
Terms of Service
Layout: fixed | fluid