Reproduced Analysis of the deadlock problem caused by improper operation in DllMain--the thread calls GetModuleFileName, GetModuleHandle and so on to lead to deadlock

(reproduced in Breaksoftware's CSDN blog)

Previous articles have explained the causes of deadlocks created in DllMain and waiting for threads to cause. Remember, we analyzed the half-day assembly before we knew the deadlock location in the thread. If the lack of debugging experience for students, may find this location a bit troublesome. So this article will introduce a few examples, they will be the obvious location of the thread deadlock.

The code in the DLL is still simple. It gets the named event that is called events, and then waits for the event to be activated. The activated action is naturally placed in the thread. Instead of creating threads in the DLL this time, we created them in the EXE.

2. Switch (Ul_reason_for_call)
4. {
6. Case Dll_process_attach: {
8. printf ("DLL dllgetmodulehandle:\tprocess attach (tid =%d) \ n", Tid);
10. HANDLE hevent = CreateEvent (NULL, False, False, L"EVENT");
12. if (NULL! = hevent) {
14. WaitForSingleObject (hevent, INFINITE);
16. }
18. } break;

1 Calling GetModuleFileName deadlock in thread

The thread function is

2. Static DWORD WINAPI threadgetmodulefilename (lpvoid h) {
4. hmodule hdll = (hmodule) H;
6. WCHAR Wszfilename[max_path] = {0};
8. GetModuleFileName (hDLL, Wszfilename, MAX_PATH);
10. HANDLE hevent = CreateEvent (NULL, False, False, L"EVENT");
12. SetEvent (hevent);
14. return 0;
16. }

After a deadlock, the deadlock location in the DLL is the same as in the previous articles and is no longer described later in this article. We focus on the thread's stack, which is

We see the getmodulefilename inside to invoke Ldrlockloderlock to enter the LoaderLock critical section of the PEB. However, the critical area is occupied by the main thread (before calling DllMain to enter the critical section), the main thread also waits for the worker thread to call GetModuleFileName after the activation event to exit, so it is deadlocked.

2 Calling GetModuleHandle deadlock in thread

The thread function is

1. Static DWORD WINAPI threadgetmodulehandle (lpvoid) {
2. Sleep (1000);
3. GetModuleHandle (L"Dllwithoutdisablethreadlibrarycalls_a.dll");
4. HANDLE hevent = CreateEvent (NULL, False, False, L"EVENT");
5. SetEvent (hevent);
6. return 0;
7. }

I'm not going to explain the content, we look directly at the thread stack.

We see that the bottom of the Getmodulehandlew is still inside the loader function. and in the loader function into the Ldrlockloderlock, the function inside to enter the PEB loaderlock critical section. However, the critical area is occupied by the main thread (before calling DllMain to enter the critical section), the main thread also waits for the worker thread to call GetModuleHandle after the activation event to exit, so it is deadlocked.

3 Calling LoadLibrary deadlock in thread

Thread functions

1. Static DWORD WINAPI threadloadlibrary (lpvoid) {
2. Sleep (1000);
3. Loadlibraryw (L"Dllwithoutdisablethreadlibrarycalls_a.dll");
4. HANDLE hevent = CreateEvent (NULL, False, False, L"EVENT");
5. SetEvent (hevent);
6. return 0;
7. }

Deadlock Post Thread stack

[]dllmain analysis of improper operation in the reprint to cause deadlock problem--call GetModuleFileName, GetModuleHandle, etc. in thread to cause deadlock