How to correctly write a C++ DLL that will load in debug mode too without crashing

Question

Hi, my problems deals with native C++ DLLs (Visual Studio 2005, if it matters) and how to write them in order to insure that:

• when the DLL is compiled in release mode, it will be correctly loaded by an EXE compiled in release or debug mode (first priority)
• when the DLL is compiled in debug mode, it will be correctly loaded by an EXE compiled in debug mode too.

Today I have a C++ native DLL that loads and works fine in DLL-release/EXE-release mode. The DLL loads but doesn't work fine (function calls return unexpected results) in DLL-release/EXE-release mode (and this is a huge problem, because it prevents me from debugging the EXE, which is my main goal) and crashes on a heap corruption in DLL-debug/EXE-debug mode.

I know that there is a CRT-related problem that requires CRT-isolation between DLL and EXE. Normally this problem is solved by making operators new/new[]/delete/delete[] private in the DLL and wrapping them by create()/release() functions that allows to the EXE dynamic object creation.

My question is: before I start re-factoring all my code in that direction, is there something else I need to do in order to avoid these kind of problems ? CRT-isolation will probably fix my DLL-debug/EXE-debug crash, but I'm not sure it will fix the DLL-release/EXE-debug problem.

Any hint ? Anyone having already been confronted to this problem ?

Thanks, Al.

Answer 1

Don't use configuration-specific code in public Dll h-files. For example:

class ExportedClass
{
...

#ifdef _DEBIG
    int debug_info;
#endif

...
}

When Dll is compiled in Debug configuration, sizeof(ExportedClass) contains additional 4 bytes. When this file is compiled by client code is Release configuration, sizeof(ExportedClass) is 4 bytes less. Result is undefined.

Also, don't use any types which have configuration-specific size, as part of Dll public interface: return values and parameters.

Answer 2

I would first and foremost solve the debug/debug scenario. The heap corruption is an indicator of a serious existing problem, and until not solved, you have no guarantee that any other scenario will work properly. in fact, I would argue that any other scenarios will not work properly either.

Also, I am not sure why would you think that the heap corruption needs to be solved by CRT isolation and is not a problem in the dll or exe code. Are the dll and the exe linked against different versions of the CRT?