What exactly is the "Multi-threaded Debug DLL" Runtime Library option doing in VS 2008?

I have a solution in VS 2008 that creates a DLL. I then use that DLL in another application. If I go in to the DLL projects property pages and change the following configuration for a DEBUG build then the built dll no long provides开发者_JAVA技巧 the desired functionality. If I change it back and rebuild the DLL, then the DLL does provide the correct functionality:

Property Pages => Configuration Properties => C/C++ => Code Generation => Runtime Library

If set to "Multi-threaded Debug DLL (/MDd)" then everything works as it should. I get the correct functionality from the DLL

If set to "Multi-threaded DLL (/MD)" then the DLL does not function properly...no runtime errors or anything, it just doesn't work (The DLL is supposed to plot some lines on a map but does not in this mode).

So the question is, why does using the /MDd flag result in correction functionality of the underlying code, while /MD results in incorrect functionality?

A little background...somebody else developed the DLL in C++ and I am using this DLL in a VB.net application.

All DLL's/debug code generation must match across everything that uses them. There may be another referenced library or object or dll or some code in there that is built using the wrong options; or specific options for an individual element that override the global project options.

The only way of figuring it out is to meticulously check all of the options for each file, checking the included and referenced libraries (.lib and .dll) and object files. Check the linker options too.

The reason why it doesn't work is probably because the debug version adds extra guard blocks around memory to allow detection of errors.

I had similar problems. My application which "used" a 3rd party DLL crashed when its runtime library was set to "Multi-threaded DLL (/MD)", but worked when its runtime library was set to "Multi-threaded Debug DLL (/MDd)".

It has something to do with passing std::strings and std::lists across the DLL interface.

Our guess was the low level definition of these types was somehow different in the two runtime libraries.

We solved our related problems using this rule... The DLL and the DLL user must be build using the exact same runtime library.

The main difference between the two options is in the libraries that your code will be linked at later. for the debug version for example this will include LIBCMTD.LIB and a few others. if your library is going to be built as debug the you should always link with MDd. failing to do so will result in lots of unresolved external linker errors at best. and sometimes the code compiles normally but crashes at runtime. if this happens in vb.net then a catch can easily hide the error. I guess you should make sure you build setting is correct. for more detailed information check this.