FreeLiaray并不释放代码,只是减少引用计数
FreeLibrary
The FreeLibrary function decrements the reference count of the loaded dynamic-link library (DLL) module. When the reference count reaches zero, the module is unmapped from the address space of the calling process and the handle is no longer valid. BOOL FreeLibrary(
  HMODULE hLibModule   // handle to loaded library module
);

解决方案 »

  1.   

    CreateThread(假设你用它来创建线程)的实现在kernel32.dll里而不在你的dll里。
    可以推断:即使你的dll被释放了,只要kernel32.dll还没有被释放(进程结束时会释放),线程应该不会结束。
    当然kernel32.dll如何管理线程我就不知道了。
      

  2.   


    当应用计数为0时,会把DLL代码从进程的地址空间给移除。
      

  3.   

    1,提前释放了dll,如果其后的操作需要dll的调用,运行肯定崩溃(保护错误)
    2,进程是空间的概念,线程是时间的概念,所谓进程运行实质是线程运行,进程内的所有线程都结束,进程也就结束,dll本身是没有线程的(你在dll中创建另外的线程,也是进程里的一个线程)。
      

  4.   


    你说的没错,但是线程函数时属于dll,也就是说dll释放掉后,线程函数的代码也随着一起释放掉,由于线程还在,线程内核对象同样还在,所以单CPU时间片切换为线程去执行时,那么这时IP指针执行的代码不存在,所以会导致程序挂掉。
      

  5.   

    代码空间,内存空间我觉得都是内存上的一块数据,DLL释放相当于DLL的代码空间内存释放掉了,在执行时,EIP指向的内存就不可读或者是其它压根不正常的数据了。
    这个跟进程结束是两个不同数量级的问题,进程本身要靠一个或多个线程去执行,进程结束
    必须是所有线程被强制结束。
      

  6.   

    这样的帖子才有技术含量,围观ing
      

  7.   


    你说的没错,但是线程函数时属于dll,也就是说dll释放掉后,线程函数的代码也随着一起释放掉,由于线程还在,线程内核对象同样还在,所以单CPU时间片切换为线程去执行时,那么这时IP指针执行的代码不存在,所以会导致程序挂掉。线程结束前,dll被非法卸载后,只要访问到肯定崩溃,那是毫无疑问的
      

  8.   

    1、进程结束与dll卸载的不同
    进程结束可以认为干了至少两件事,一是结束所有线程,而是卸载所有模块
    dll卸载只是卸载了一个模块
    2、dll的卸载没有任何内建机制保证dll创建的线程被停止,事实上,dll根本不知道自己内部有哪些线程。这些线程可能是dll入口函数创建的,可能是dll导出函数创建的,可能是宿主中的某个既有线程执行过程中调用了dll中的某个函数----这也是线程运行到dll中代码的情形。
    3、dll卸载后依然有线程企图执行dll中的代码,基本是必死无疑。一般情况下,原来代码处于的那块内存已经被系统回收,读写都甚至不能保证,更不用说执行代码了。
    4、dll卸载时的安全性应该由应用开发者来确保。比如dll中在入口处创建的线程,安全起见,要在DLL_PROCESS_DETACH或更早的时候予以结束(主动结束或强制终止)。还比如可以利用FreeLibraryAndExitThread通过调整dll引用计数来提高安全性。