Native C/Managed C++ Debugging

Question

I have a native C Dll that calls 'LoadLibrary' to load another Dll that has the /clr flag turned on. I then use 'GetProcAddress' to get a function and call it on dynamically loaded dll. I would like to step into the dynamic library in the debugger, but the symbols never load. Any idea?

And I should have said I'm using Visual Studio 2008.

Update: Thanks to some tips below, I changed the project debugging to Mixed. It didn't work, but I think I know why. I am developing an addin to an existing application. The app I'm connecting to starts one exe then it starts another. So I have to use "Attach to process" to fire up the debugger. My guess is launching the debugger that way will default to "Auto". Is there a way to change the default behavior of VS to use "Mixed" debugging?

Answer 1

I've had mixed experiences with doing similar things like this in VisualStudio. You might consider using ProcMon to see where VisualStudio is looking for the PDB file. Alternatively, you might try using WinDbg. It seems to do better at loading symbols and if it doesn't, you can explicitly load them yourself. Using WinDbg involves riding a steep learning curve, but if you're burning time right now, isn't it worth it?

You can also run the exe on its own and from the source of the managed dll, attach to the process to debug it.

Answer 2

Modify the mixed-mode dll to throw a CLR exception where it enters the first code you're interested in debugging. This should give you an opportunity to launch the managed debugger.

Answer 3

In VS2005, there are per-project options to enable native and CLR debuggers separately. You might need to enable the CLR debugger for the native dll project from which you start the debugger.

Answer 4

This is from VS2008, but if I remember correctly VS2005 was similar. In the native project's properties, under "Configuration Properties->Debugging" there is a "Debugger Type" which is set to "Auto" by default. You'll need to change it to "Mixed", because VS isn't smart enough to realize you need managed debugging