Memery leak in mixed mode program that use native DLLs. RRS feed

  • General discussion

  • I wrote a mixed mode program that calls the API of a third party library built using native code.  The third part library has a dependency on MFC90 and MSVCRT90/  I think there is some initialization code in the native DLLs that may allocate some memory for objects or such because if I debug my program and terminate the debug section without running to part of the code that utilizes any objects exported from the native library I get a memory leaks and just to say I get the memory leaks if the run the program normally.  I write a test program using native C++ to use the native library and after I cleaned all the objects I created I didn't have any memory leaks.  Is there something different that .net framework does when loading native libraries then the CRT does?  I would think that if the native libraries have initialization code that I can't touch then there is also shutdown code in them to deallocate  any objects created for internal usage.  Would it make sense for me to link at runtime rather than at build time i.e. "Loadlibrary" and "FreeLibrary"?


    Tuesday, October 22, 2013 8:23 PM

All replies

  • Hi Kenney,

    We embed the unmanaged dlls into an assembly and then copy them out to the executing dll location (for web apps use the shadow copy bin folder). This guarantees that the correct version is being run for a particular version of our app. You could use LoadLibrary to verify that the library is found, but beware of loading the wrong version. This may or may not be the problem you could solve. See DLL hell for more information.

    Hope useful to you.

    Best Regards,

    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.

    Thursday, October 24, 2013 2:52 AM
  • This is a old thread but I like to tie up loose ends.  I solved this by linking with the same version of VC runtime libraries as the third party dlls.  This resolved a lot of problems because at the core or object allocation and destruction is malloc and free and if the native app calls malloc with one version of the runtime library my managed code can't call free with different version of the library.


    Wednesday, April 9, 2014 8:20 PM