关于在Dll入口函数中Wait系函数死锁的解决
本帖最后由 元始天尊 于 2015-6-23 01:42 编辑众所周知，dll中如果用了等待系函数会形成死锁，《Windows核心编程》给出了一个例子
//***exe.cpp
LoadLibrary(***dll.cpp);
//***dll.cpp
DWORD __stdcall func(LPVOID)
{
Sleep(2000);
cout<<"in thread"<<endl;
return 0;
}
BOOL WINAPI DllMain(HINSTANCE hInstDll,DWORD fdwReason,PVOID fImpLoad)
{
if(fdwReason == DLL_PROCESS_ATTACH)
{
HANDLE hthread=CreateThread(NULL,0,(LPTHREAD_START_ROUTINE)func,NULL,0,NULL);
if(hthread)
WaitForSingleObject(hthread);//这里会死锁
}
else if(fdwReason == DLL_THREAD_ATTACH)
{
}
}
这是一个很常见的错误，死锁原因是这样的：在loadlibrary之后，系统加载器执行到dllmain之前，会调用EnterCriticalSection锁住进程的“加载器锁”，而dllmain中的wait函数会共用这个“加载器锁”，再次锁住该锁，因此造成死锁，，，正常的情况是：waitForsingleobject之前就执行完dllmain，之后系统加载器执行LeaveCriticalSection，之后再去wait就不会发生死锁，而现在的情况是，wait在等dllmain执行完，而dllmain在等wait执行完。dllmain中不能用wait系函数也是出自这个原因，如果读了内核代码，会更明白这一块。核心编程的作者说，他能想到的解决办法只有在dllmain中不要出现wait系函数，这种是不良设计思路。事实上msdn上也说不推荐dllmain中存在耗时操作，所以他们才这么设计的！因为加载dll本身就是很复杂的，很费时间片的工作！！！,核心编程的作者尝试DisableThreadLibraryCall来破解限制，然而没成功
而这里我提出2种方式来破解锁限制，且都可以成功，第一种比较暴力，直接leave掉加载器锁，wait之后再恢复即可，代码如下：
if(reason == DLL_PROCESS_ATTACH)
{
cout<<"inside dll!"<<endl;
PCRITICAL_SECTION loaderlock=NULL;
_asm
{
mov eax,fs:;
mov eax,;
mov eax,;
mov loaderlock,eax;
}
LeaveCriticalSection(loaderlock);
HANDLE hthread=CreateThread(NULL,0,(LPTHREAD_START_ROUTINE)func,NULL,0,NULL);
if(hthread)
{
cout<<"create succeed!"<<endl;
}
WaitForSingleObject(hthread,INFINITE);
EnterCriticalSection(loaderlock);
}
else if(reason == DLL_THREAD_ATTACH)
{
cout<<" DLL_THREAD_ATTACH"<<endl;
}
return 0;
这种做法的缺点是，无法保证可重入性，但如果dll足够简单的话，也不妨一试
第二种则采用事件等待的方法，比较规矩：
***exe.cpp
void main()
{
HANDLE hEvent=CreateEventA(NULL,TRUE,FALSE,"Initial");
HMODULE hmod=LoadLibraryA("C:\\Users\\Administrator\\Documents\\Visual Studio 2010\\Projects\\test1\\Debug\\testdl.dll");
WaitForSingleObject(hEvent,INFINITE);
CloseHandle(hEvent);
cout<<"Success!!"<<endl;
}
***dll.cpp
DWORD __stdcall func(LPVOID)
{
cout<<"in thread"<<endl;
HANDLE hEvent=OpenEventA(EVENT_ALL_ACCESS,TRUE,"Initial");
if(hEvent)
{
SetEvent(hEvent);
CloseHandle(hEvent);
}
return 0;
}
int __stdcall DllMain(int,int reason,int)
{
if(reason == DLL_PROCESS_ATTACH)
{
cout<<"inside dll!"<<endl;
CreateThread(NULL,0,(LPTHREAD_START_ROUTINE)func,NULL,0,NULL);
}
else if(reason == DLL_THREAD_ATTACH)
{
cout<<" DLL_THREAD_ATTACH"<<endl;
}
return TRUE;
}
为防止滥用，再次强调一下，在dllmain中最好不要放置耗时操作。
哈哈 这个帖子好！ 对这种代码必须表示不满：
_asm
{
mov eax,fs:;
mov eax,;
mov eax,;
mov loaderlock,eax;
}X64、ARM、MIPS平台怎么办？？？ 除了从Fs段读这个不好办以外，别的几条可以纯C搞定。 omgkaka 发表于 2015-6-23 11:58
第二种是调用方exe和被调用方dll协同处理这个问题
而一般实际需要dllmain中用这种操作的都是dll注入去处理 ...
该问题是源于“操作必须在dllmain中处理结束”而产生的，也就是LoadLibrary的时候一定要处理完
如果完全独立也可以，这种情况是创建了线程，而无需知道它是否执行完
然而如果一定要知道他执行完了的话，也就只能采用2种方式，要么等LoadLibrary执行完，这对应第一种方式，要么Load之前设置信号，load之后等待这个信号，这对应第二种方式，如果是规范的编程方式，那么其实这2种方法已经涵盖了所有方法。 0xAA55 发表于 2015-6-23 10:57
除了从Fs段读这个不好办以外，别的几条可以纯C搞定。
fs那个有NtGetPeb...等等函数，win提供了，我这篇只是揭示底层原理的 第二种搞法挺好，不过exe和dll得配合着来。
页:
[1]