这个经典的同步问题，有很多文章讲过，写这篇博客，权当是疏理一下相关的技术概念和分析方法。

问题的现象：

如果在一个DLL的DllMain()函数中创建一个线程，那么当该DLL被引导时，就会导致主（host）进程陷入死锁。

问题重现方法：

用VS生成一个DLL工程，在DllMain()函数里创建一个线程，并等待该进程结束。简单起见，子线程函数不必包含任何工作逻辑，直接返回即可。

DLL工程源代码：

#include <windows.h>
#include <stdio.h>
WINAPI InitDllProc LPVOID lpParam )
{
	return 1;
}
BOOL WINAPI DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpvReserved)
{
	BOOL bRet=FALSE;
	switch(fdwReason)
	{
	case DLL_PROCESS_ATTACH:
		{
			DWORD dwId=0;
			HANDLE hThread=NULL;
			hThread = CreateThread(NULL, 0, InitDllProc, NULL, 0, &dwId);
			if(hThread)
			{
				WaitForSingleObject(hThread, INFINITE);
				CloseHandle(hThread);
				bRet=TRUE;
			}
		}
		break;
	}
	return bRet;
}

另生成一个普通的console程序工程，在main()函数里调用LoadLibrary()引导DLL工程生成的DLL。

console程序源代码。

#include <windows.h>
#include <stdio.h>
int _tmain(int argc, _TCHAR* argv[])
{
	_tprintf(L"Load library ...\n");
	LoadLibrary(L"DllMain.dll");
	_tprintf(L"Load library done.\n");
	return 0;
}

把创建的DllMain.dll和LoadDll.exe放在同一个目录下，并双击运行LoadDll.exe。可以看到主进程输出"Load library ..."之后就再也没有动作。

用任务管理器看到该进程的CPU使用率一直保持0不变。

据此可以判断，LoadDll.exe进程陷入了某种死锁状态。

问题调试

0:002> !cs -l
-----------------------------------------
DebugInfo          = 0x779f7540
Critical section   = 0x779f7340 (ntdll!LdrpLoaderLock+0x0)
LOCKED
LockCount          = 0x1
WaiterWoken        = No
OwningThread       = 0x00000fa0
RecursionCount     = 0x1
LockSemaphore      = 0x30
SpinCount          = 0x000000000:002> ~* kv
   0  Id: f9c. fa0 Suspend: 1 Teb: 7ffde000 Unfrozen
ChildEBP RetAddr  Args to Child              
0015f934 77966a24 75af179c 0000002c 00000000 ntdll!KiFastSystemCallRet (FPO: [0,0,0])
0015f938 75af179c 0000002c 00000000 00000000 ntdll!ZwWaitForSingleObject+0xc (FPO: [3,0,0])
0015f9a4 7739baf3 0000002c ffffffff 00000000 KERNELBASE!WaitForSingleObjectEx+0x98 (FPO: [Non-Fpo])
0015f9bc 7739baa2 0000002c ffffffff 00000000 kernel32!WaitForSingleObjectExImplementation+0x75 (FPO: [Non-Fpo])
0015f9d0 70731044 0000002c ffffffff 00000001 kernel32!WaitForSingleObject+0x12 (FPO: [Non-Fpo])
0015f9e4 7073135e 70730000 0000008c 00000000 DllMain!DllMain+0x34 (FPO: [3,0,1]) (CONV: stdcall) [d:\for_work\taskforce\sharing\etp_couse\advancedwindowsdebugging\slides\multi-thread analyze materials\sourcecode\dllmain\dllmain\dllmain.cpp @ 25]
0015fa28 70731418 70730000 0015fa54 779789d8 DllMain!__DllMainCRTStartup+0x7a (FPO: [Non-Fpo]) (CONV: cdecl) [f:\dd\vctools\crt_bld\self_x86\crt\src\crtdll.c @ 543]
: : :
0015fd34 00e5101c 00e52118 00000001 00e51193 kernel32!LoadLibraryW+0x11 (FPO: [Non-Fpo])
0015fd40 00e51193 00000001 00472b78 00471228 LoadDll!wmain+0x1c (FPO: [2,0,1]) (CONV: cdecl) [d:\programming\vc++\loaddll\loaddll\loaddll.cpp @ 12]

   1  Id: f9c.8c Suspend: 1 Teb: 7ffdd000 Unfrozen
ChildEBP RetAddr  Args to Child              
005af624 77966a24 77952264 00000030 00000000 ntdll!KiFastSystemCallRet (FPO: [0,0,0])
005af628 77952264 00000030 00000000 00000000 ntdll!ZwWaitForSingleObject+0xc (FPO: [3,0,0])
005af68c 77952148 00000000 00000000 00000000 ntdll!RtlpWaitOnCriticalSection+0x13e (FPO: [Non-Fpo])
005af6b4 77983795 779f7340 77c6147b 7ffdd000 ntdll!RtlEnterCriticalSection+0x150 (FPO: [Non-Fpo])
005af748 77983636 005af7b8 77c614a7 00000000 ntdll!LdrpInitializeThread+0xc6 (FPO: [Non-Fpo])
005af794 77983663 005af7b8 77920000 00000000 ntdll!_LdrpInitialize+0x1ad (FPO: [Non-Fpo])
005af7a4 00000000 005af7b8 77920000 00000000 ntdll!LdrInitializeThunk+0x10 (FPO: [Non-Fpo])

至此，我们知道了主线程在LoadLibrary函数里会进入LdrpLoaderLock这个关键区，以保护后续对ntdll!PebLdr的访问。而DllMain里创建的子线程在初始化时，也需要进入该关键区以访问PebLdr。

在下一个章节，我们将分析PebLdr是什么？为什么LoadLibrary和线程初始化都需要访问它？还有哪些操作需要用到它？