Debug DLL with release EXE

Question

Is it possible to execute debug mode DLL with release mode EXE?

I am trying this scenario but EXE does not load the debug DLL and throws error "This application has failed to start...".

I know this is not good scenario to do but Due to certain requirements I have to make this work.

Yes, it is possible. The failure to load should its own specific reason such as missing dependency. — Roman R., Mar 01 '13 at 08:41
Check your debug build settings. Generally this error shows up when there is missing libraries or you have made the build with "Multi-Threaded Debug Dll" option in the code generation. — Abhineet, Mar 01 '13 at 08:48
@Abhineet: I tried building using "Multi-threaded DLL" option. Still same issue... — Nipun, Mar 01 '13 at 11:11

score 5 · Answer 1 · answered Mar 01 '13 at 09:07

5

It can work if your dll interface has no dependencies on classes that may look different in debug and release. e.g. std::string and std::vector in MSVC are not compatible in debug and release. (Fences ...)

So for example

std::string GetName();

will not work.

In additional new and delete should not be shifted because debug/release use different runtimes. But anyway you should always delete in the same context(dll/exe) as new.

answered Mar 01 '13 at 09:07

Totonga

4,236
2
25
31

I have created a very basic DLL which is simply returning an integer vale. – Nipun Mar 01 '13 at 11:13

score 3 · Accepted Answer · edited May 23 '17 at 11:46

Yes, this can work.

Your "application has failed to start" issue is most likely you copied a debug build of the DLL (built on your machine with Visual Studio), to a machine that did not have the DEBUG CRT installed. Usually copying over MSVCRTD(version).dll to the same directory as your program files solves this problem. I have a previous answer that covers some of this here.

Best bet is to always have all your binaries linked to the same dynamic MSVCRT DLL so they all share the same runtime.

Another easy workaround is to compile your DEBUG DLL to use the same flavor of the MSVCRT DLL (or statically link to the CRT). Somewhere in the VS project propery pages (code generation I think) is the dropdown for choosing the CRT. There's nothing wrong with linking the retail MSVCRT into a debug DLL - or statically linking.

The things to watch out for are when you have a different flavor of the debug C runtime linked to the different binaries. If you have the release MSVCRT dll linked for the EXE, but the debug MSCVRTD DLL for the DLL, that can cause problems in a few circumstances. This is because handles and memory blocks are tracked by two different instances of the CRT.

Examples:

If you allocate memory in the EXE, but free in in the DLL. And vice versa.
File handles opened with fopen() in the EXE, but used or closed in the EXE (and vice versa).
For any of the header files for the DLL's interface, having any sort of inline functions or methods implemented in the header file is an easy way to cause #1 or #2 to happen.
Sharing STL objects (std::string, std::list, std::vector) is a definite no-no for mixed CRT usage.

Debug DLL with release EXE

2 Answers2