There is a DLL, that is loaded by the main (desktop) application dynamically via `Windows.LoadLibrary`. That's because there are plenty of similar DLLs and only few to single of them are required to be loaded on runtime. So static linking is not an option.

The problem is, that every once in a while the main application hangs when loading one of those DLLs. Note, that the problem is likely to happen with every one of them. Probably because they have a lot of codebase in common.

The problem seems to be a *loader lock* ([see this SO answer on what it is](https://stackoverflow.com/a/13874632/4236400)). I found a piece of common code, that is used by all of the DLLs at startup in the `begin...end`-section of the `library`-unit (that is `project.dpr`), where `GetModuleHandle` and `GetProcAddress` are used.

I found out, that this is a totally DONT with DLLs, as the `begin...end`-section of the DLL's project file is in fact the library's `DllMain` function and calling such functions can lead to dead locks (named *loader lock*). I read that in this [Microsoft Best Practice Guide](https://msdn.microsoft.com/en-us/library/windows/desktop/dn633971(v=vs.85).aspx#general_best_practices).

So I rebuild my code, that these calls are called later on, when the call of `Windows.LoadLibrary` has been completed.

Unfortunately, the hanging problem remains. :-(

I ran the debugger then, stepping through every piece of initialization that is called even before a single line of my code is executed. I determined, that lots of third party code contravenes the guide on what to do and what not to do in DLL initialization code:

* TMS Component Package
* JEDI Component Library
* OmniThreadLibrary
* Indy Components

All of the above dynamically load other DLLs in `initialization`-code or requesting procedure pointers via `GetProcAddress`. I think that these calls cause the hanging when my DLLs are loaded.

Is it, that only few Delphi developers know about the dangers of `initialization`? What can I do about this?