Attaching DLL to managed process doesn't work

0
votes

I have a C++ DLL project (x86) that I need to debug. This DLL is consumed by an exe.

I can easily attach the DLL project in VS2017 to a native exe (x86). When I set breakpoints in the C++ DLL project in VS2017, these break points are hit. This is the normal, desired behaviour.

Now I have attached the C++ DLL project to a .NET exe (compiled as x86). Break points are not hit, and I don't have any idea why that doesn't work like with a native exe.

I have unchecked the option "Use Application Framework", but that didn't change anything.

I have also tried the option "Enable native code debugging" without any success. Also, I have tried to attach it to a Debug version of the NET exe and to a Release version of the NET exe.

I can see that VS2017 attaches to the correct process as when I close the NET exe, VS2017 goes out of debugging mode.

However, breakpoints are not hit.

Is there anything special that I have to take care of?

1
c++debuggingdllprocessvisual-studio-2017
I guess you need to enable debugging of native code. – PaulMcKenzie
@PaulMcKenzie Thank you, but that doesn't change anything. – tmighty
Then debug from the DLL side. Load the DLL project and have the .Net app as the executable to run. – PaulMcKenzie
@PaulMcKenzie Yes, that is what I'm doing anyways: I start the NET.exe project, then I open the C++ DLL project in VS2017 and click "Debug" -> "Attach to process". – tmighty
No, don't attach. Load the DLL project, change the executable to run to the Net executable in the debug configuration of the DLL. Also, look at the console output carefully and check if the DLL is being loaded and that symbols have been loaded. – PaulMcKenzie

1 Answers

0
votes

Most likely, the managed .exe has not loaded the native DLL. Or it has loaded an incorrect build of the DLL, not the one that you’re debugging.

To troubleshoot, add __debugbreak(); call in your native code. That kind of breakpoint is very unlikely to be ignored, unless you mess with structural exception handling. Windows will show you a message offering to attach a debugger, you can choose existing instance of visual studio. Once attached, “Modules” window will show you exactly which build of the native DLL it loaded.

The best way to solve that permanently is add two projects in a single visual studio solution, setup dependency, and ensure the DLL output location is where the EXE looks for the library. I do it all the time in VS2017, with native code debugging enabled I can set my breakpoints in either managed or native code, which helps a lot debugging the interop.