使用发行版EXE调试DLL

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.

Answer 1

It can work if your dll interface has no dependencies on classes that may look different in debug and release. eg 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 .

Answer 2

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:

1. If you allocate memory in the EXE, but free in in the DLL. And vice versa.

2. File handles opened with fopen() in the EXE, but used or closed in the EXE (and vice versa).

3. 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.

4. Sharing STL objects (std::string, std::list, std::vector) is a definite no-no for mixed CRT usage.