windowsmultithreadingwinapiwin32-process

Can a DLL be statically loaded by worker thread during the process startup?

We have an application containing many (hundreds) DLLs. The EXE directly depends on part of them (via its Import Table), which in turn depend on another part (via their Import Tables) and so on. Out of all these DLLs there is one, that both the EXE and most of DLLs depend on. This DLL is one of the first to be (statically) loaded at the application startup.

According to all known to me sources describing process' loading, the DLL_PROCESS_ATTACH entry of this DLL must be called on the process' primary thread. This is also confirmed by @MSalters answer and @RbMm comment to my other question. But if this is true, then how to explain the following snapshot of the debugger's "Threads" window, that I received from one of my colleagues (this snapshot was obtained by placing the MessageBox() statement after DLL_PROCESS_ATTACH and attaching the VS debugger): enter image description here In this snapshot you can see that the primary thread is stuck in the "ThreadStart" function, while the DLL is being loaded by the worker thread. It is also strange that we see one debugger thread, whereas usually VS debugger doesn't show its threads.

If someone has an explanation, I'd be glad to hear it.

Solution

  • Can a DLL be statically loaded by worker thread during the process startup?

    no, can not

    while the DLL is being loaded by the worker thread.

    if thread entry poins is LoadLibraryWStub (this is same as LoadLibraryW) - this is mean some another process call CreateRemoteThread with LoadLibraryW as thread start routine. this is classic way of dll injection. of course - possible and some code in your process call CreateThread or CreateRemoteThread with LoadLibraryW, but this is very unusual. in any way - system/loader (ntdll code) never do this.

    It is also strange that we see one debugger thread, whereas usually VS debugger doesn't show its threads.

    DbgUiRemoteBreakin - thread with such entry point created by call DbgUiIssueRemoteBreakin which simply create thread in target process with DbgUiRemoteBreakin. and this thread simply call DbgBreakPoint and exit. the DebugActiveProcess called DbgUiDebugActiveProcess which called DbgUiIssueRemoteBreakin - so also nothing unusual. and in your case 3 threads (including DbgUiRemoteBreakin ) even not begin executed almost, because wait for loader critical section