VS2010 reports false memory leaks for static classes in a DLL

If you are calling _CrtDumpMemoryLeaks() at the end of the main function the behaviour is expected, since mp_data will be deleted after _CrtDumpMemoryLeaks() was called.

You would need to call _CrtDumpMemoryLeaks() after the last destructor of you static objects has been called (or rather in the last destructor after the memory has been freed) if you don't want to see these leaks (quite a difficult task, I wouldn't try it).

The cleaner approach is to allocate all your static objects on the heap instead (at the beginning of main), and de-allocate them at the end of main, and then you can call _CrtDumpMemoryLeaks() and won't see any memory leaks.

FYI static objects with constructors and destructors are considered bad anyways, because the order in which they are constructed/destructed is not deterministic, and because of that static objects often introduce bugs which can't be debugged easily.

Edit regarding Andrey's comment: You could try to deactivate the automatic call to _CrtDumpMemoryLeaks by calling _CrtSetDbgFlag to unset the _CRTDBG_LEAK_CHECK_DF flag. If that works, you can add a static object which calls _CrtDumpMemoryLeaks() in its destructor. To make sure that this object is destructed last, you can use the #pragma init_seg(compiler) directive.

No clue if this will work... Other than that, all other solutions will most likely require you to modify the ITK library (which should be possible, it's an open source library after all?!).

Any of following solves the problem.

(1) Create a fake dependency of the DLL on MFC, or

(2) Use the solution suggested by smerlin: add this code next to DllMain

struct _DEBUG_STATE
  {
  _DEBUG_STATE() {}
  ~_DEBUG_STATE() { _CrtDumpMemoryLeaks(); }
  };

#pragma init_seg(compiler)
_DEBUG_STATE ds;

I hit the same symptom in the course of migrating an internal library from static linking to load-time dynamic linking, and it turned out that the problem in my case was that the DLL project and the EXE project were linked to different versions of VC++'s runtime/MFC libraries (one was MBCS and one was Unicode).

In my case, the application and library were both using MFC, and the _AFX_DEBUG_STATE destructor which activates the CRT memory leak dump was being called twice, for two separate objects -- since the DLL and EXE linked to different runtime DLLs, static state in the runtime was effectively duplicated. One of the DLLs would unload and dump leaks too early and show a bunch of false leaks. Switching both projects to use the same character set resolved the separate runtime linkage and also resolved the false leak reports.

In my case, linkage to the two separate runtimes was unintentional and may have caused other problems anyway. This obviously wouldn't be the case when consuming third party libraries with a well-defined ABI where you have no control over what CRT the library is linked to.

Not sure if this would've be applicable in your case but I wanted to post in case it's helpful to others.