|
|
|---|---|
|
|
2019-4-20 18:08
|
|
|
|
|
|
2019-4-20 20:21
|
|
|
|
|
|
2019-4-21 03:49
|
|
|
MT编译应该是不会附带依赖的DLL的，而且调试跟进构造函数确实没有用到其它DLL |
|
|
不是用MFC的框架也会崩溃，所以也不会是MFC 资源问题
|
|
|
确实是内存问题，跟进去是一个CALL eax 不知道call 到哪里去了，如果DLL不卸载自身是没问题的， 不过有个疑问局部变量string 等不是执行了代码才构造内存的吗，为什么还会和原来的DLL地址有关呢 |
|
|
因为string是属于C++运行时库管理的,DLL卸载了,运行时库会自动销毁string这些类申请的内存,对运行时库我一直都是这么理解的. |
|
|
2019-4-22 12:59
|
|
|
VS现在编译的DLL,默认的DLLMAIN不是真正的入口,如果你自己#pragma comment(linker,"/entry:DllMain")重定义入口函数,你会发现用到的运行时库组件(比如sting)的时候无法通过编译,因为string这些东西调用的时候,会加载运行时库并调用运行时库初始化函数(调用过程是放在vs封装好的入口里,不是DLLMAIN),用于管理运行时库组件运行过程产生的内存,当DLL卸载的时候会自动帮我们把这些内存销毁掉,这就是为什么string这些东西用着那么方便,还没有内存泄露的原因. |
|
|
多谢了，我想现在我有点明白原因了，自已应该可以调试出来 |
|
|
|
Rookietp
lononan
