Go Analysis of the deadlock problem caused by improper operation in DllMain--dllmain write code carefully (end of article)

Found in csdn This article, explained in more detail, so here back one. Original link: http://blog.csdn.net/breaksoftware/article/details/8167641

DllMain related Properties

This paper first lists the 11 characteristics of the analysis of the deadlock problem caused by improper operation in DllMain--the research and analysis of the process on the call rule of DllMain function:

1. DLL loading does not cause the previously created thread to call its DllMain function.
   
2. When the thread is created, it calls the DllMain of the DLL that has already been loaded, and the reason for the call is Dll_thread_attach. (DisableThreadLibraryCalls will cause the procedure not to be called)
   
3. The TerminateThread way to terminate a thread is not to let the thread call the DllMain of the DLL that is loaded in the process.
   
4. When a thread exits normally, the DllMain of a DLL that is not unloaded in the process is called, and the reason for the call is Dll_thread_detach.
   
5. When a process exits gracefully, it calls (not necessarily the main thread) the DllMain of the DLL that was not unloaded in the process, and the reason for the call is Dll_process_detach.
   
6. When the DLL is loaded into process space (and which thread is LoadLibrary), the thread that loads it calls DllMain and the reason for the call is Dll_process_attach.
   
7. Before the DLL is unloaded from the process space, its dllmain is called by the thread that unloaded it, and the reason for the call is Dll_process_detach.
   
8. TerminateProcess will cause threads and processes to not make DllMain calls to unloaded DLLs when exiting.
   
9. ExitProcess causes the main thread to exit unexpectedly, and the child thread makes a DllMain call to a DLL that is not unloaded, and the reason for the call is Dll_process_detach.
   
10. ExitThread is the most peaceful way to exit, and it will let the thread exit before calling DllMain on an unloaded DLL.
    
11. The creation and exit of threads does not call DllMain on DLLs that call DisableThreadLibraryCalls.

don't do things in the DllMain.One, direct or indirect call LoadLibrary (EX)

If we DllMain receive Dll_process_attach in A.dll, the B.dll is loaded, and B.dll in DllMain is loaded dll_process_attach when it receives A.dll. Generates a cyclic dependency. But be careful not to assume that this process is A.dll DllMain calls the DllMain of B.dll Dllmain,b.dll and then calls the A.dll DllMain such a dead loop. Even if there is no cyclic dependency, if there is an analysis of the deadlock problem caused by improper operation in the DllMain-the third example in a thread called GetModuleFileName, GetModuleHandle, and so on, it will deadlock.

Second, the use of CoInitializeEx

LoadLibraryEx is called at the bottom of the CoInitializeEx for the same reason as a.

Third, the use of CreateProcess

The CreateProcess performs a load DLL operation at the bottom. I used IDA to look at the CreateProcess in Kernel32 to see the CREATEPROCESSINTERNALW in its underlying call

Iv. using functions in User32 or GDI32

Some functions in User32 and GDI32 load other DLLs at the bottom of the call.

V. Using managed code

Running managed code requires loading additional DLLs.

Vi. synchronous execution with other threads

The analysis of the deadlock problem caused by improper operation in the DllMain-load unload DLL and DllMain deadlock, analysis of the deadlock problem caused by improper operation in DllMain-the key hiding factor of deadlock in DllMain and Analysis of the deadlock problem caused by improper operation in DllMain--the deadlock generated when the thread exits, the process creation and destruction as well as the loading of the DLL are entered into the PEB loadlock critical section. If the thread that occupies the LoaderLock critical section waits for a thread that needs to pass through the critical section to end, a deadlock occurs. There are cases in the above 3 blog posts.

Vii. Synchronizing objects

If the release of the synchronization object requires the LoaderLock in Peb, and the thread that occupies the critical section waits for the synchronization object, it will deadlock. In fact, the thread in F is also a synchronous object. The case is described in the analysis of improper operation in DllMain, which causes deadlock problems in threads, such as GetModuleFileName, GetModuleHandle, etc.

Viii. Use of CreateThread

Reason for the same six.

Ix. Use of ExitThread

Reason for the same six.

Ten, hope to solve the deadlock problem in DisableThreadLibraryCalls

The analysis of the deadlock problem caused by improper operation in the DllMain--disablethreadlibrarycalls the effect on the deadlock in DllMain. The implementation logic for DisableThreadLibraryCalls is to find the structure object in the PEB structure that holds the loader information in LDR.

The inmemoryordermodulelist user of the Ldr object saves the linked list of DLLs that have already been loaded.

It iterates through the list, finds information about the DLL that called DisableThreadLibraryCalls, sets the Flags field in the message, or 0x40000.

The creation thread will call Ldrpinitializethread at the bottom (see the analysis of the deadlock problem caused by improper operation in DllMain--disablethreadlibrarycalls the effect of deadlock in DllMain). The function begins by entering the LoaderLock critical section in the PEB, which iterates through the loaded DLL based on the inmemoryordermodulelist of Ldr in Peb, and then determines whether the flags field of the DLL information is or is 0x40000. If or above, do not call DllMain. If not, call DllMain. This indicates whether the DisableThreadLibraryCalls is independent of the critical section when creating the thread.

The underlying will invoke ldrshutdownthread when exiting the thread (see the analysis of improper operation in DllMain, which results in a deadlock when the thread exits). The function logic is similar to Ldrpinitializethread, except that the Dll_thread_detach is called DllMain simultaneous. So DisableThreadLibraryCalls has no effect on whether the Ldrshutdownthread enters the critical area.

Go Analysis of the deadlock problem caused by improper operation in DllMain--dllmain write code carefully (end of article)