FreeLibrary 耗时很长的问题

[vrace]

这我这儿有个程序，有一个 EXE 和 一堆 DLL, 其中有个动态加载的 MFC Extension DLL,
这个 DLL 使用了一个第三方的 COM 组件。

现在的问题是，EXE 使用 LoadLibrary 载入了这个 MFC Extension DLL,
在执行了这个 DLL 中的某个操作以后 (这个操作调用了第三方 COM 组件),
执行 FreeLibrary free 这个 DLL 的话，会消耗很长时间(大概 40秒),
但是如果没有执行那个操作，FreeLibrary 就会很快。

有大侠能给点解决的头绪么？

[珍惜生命远离CPP]

可能某个操作的 释放操作什么的很慢.

[vrace]

那个 DLL 的 DLL_PROCESS_DETACH 里面只有 VS 自己做的代码，郁闷。
看了 dependency, 检测了这个 DLL 调用的其他 DLL 的 DLL_PROCESS_DETACH 时间，都很短。当然，那个第三方组件没有办法改他的代码，就没检测时间。
能不能说是那个第三方库搞的鬼？

[ouyh12345]

单做一个测试程序，来调用第三方的com组件

[cnzdgs]

照你的描述就是那个第三方库卸载的时间长，不然你试试不执行FreeLibrary了，看看会不会出问题。

[CathySun118]

先测试一下第三方库

[vrace]

不执行 FreeLibrary 似乎也没出问题。本来也就程序退出的时候调 FreeLibrary。但是我删了 FreeLibrary 不好过老大那关- -！

[vrace]

第3方组件的几个对象我都创建了，但是还没调方法。。。目前测试程序退出正常中。。。继续搞。。。

[zhoujianhei]

COM服务未正常退出，第三方组件应提供此（退出/释放)接口。

[bitxinhai]

静态加载，节省时间

[DentistryDoctor]

第三方组件是不是在构造时干了什么？在析构时要做相应处理？

[cnzdgs]

感觉这个第三方组件在FreeLibrary的时候产生了异常又被自己捕获到了，可能产生异常还不只一次。

[jameshooo]

如果调用DLL时获得某个接口指针，则需要先调用该接口的Release，否则卸载DLL时会停在OleUninitialize里面。
如果EXE没有得到什么接口指针，说明DLL中没有正确释放该接口，需要修改这个DLL。

[UndefinedCoder]

最近尝试把Real VCN的VC++代码翻译成Delphi的。作者写得好晦涩啊。