调试由Visual Studio 2015中的本机应用程序加载的托管DLL

Question

I am working with a particular Application that supports "extensions" as Managed C# DLL's. The Application itself is a Native Application, and I do not have the source code for it.

I am able to get the Application to load the DLL, and I can verify that my functions are being called. What I would like is to be able to Debug my extension code in the DLL when it runs. I can attach to the Process of the Native Application using Visual Studio, however, I am not able to set any breakpoints as I get the "No symbols have been loaded..." error. The PDB file is present next to the DLL.

It seems to me that the Visual Studio Debugger is not recognizing my Managed C# code, even though the DLL is clearly being used. For example, if I browse through the "Modules" View, I cannot see my DLL in the list.

Reading through some Visual Studio support pages, it sounds like there is a "Mixed Mode" that I would typically enable on the Project of the running Application. However, since I am not actually building the Application, I cannot change this setting.

Does anybody know if there is another way to achieve this?

Answer 1

Visual studio will have your DLL in the list, if it's loaded, and the program is using a normal .net runtime. If it's using something doctored or mono for instance then it may not be there.

I don't think your not having the source to the unmanaged program is the problem here. "Mixed mode" is not something you set on the project. It's something you set for VS to know what debugging mode to use when starting the project from VS. You can choose even more options when attaching to a process, and that's what's important for you here.

I used this project to test the theory: https://code.msdn.microsoft.com/windowsdesktop/CppHostCLR-e6581ee0

I built release mode and deleted the PDB and was able to hit a breakpoint in the CSClassLibrary (at static int GetStringLength ) using VS2015 by manually selecting the debugger type when attaching to the process.

If you let it automatically choose, and youre having a timing problem (attach vs .net startup vs dll load), then .net may not be started up when you're attaching, and it wouldn't know to attach with the .net debugger enabled. So specifying it manually should help.

Furthermore, a standard trick when solving debugging timing problems is to put System.Diagnostics.Debugger.Break() in your c# code--that will make sure you get a chance to attach a visual studio right at that moment when you're sure your c# code is running in the (hopefully normal) .net runtime.

Answer 2

Visual Studio will show that error when your DLL has not been loaded by the process you attached to. Just ignore the error and set the breakpoints as usual. When the native application loads your DLL into memory, the breakpoint icons should turn red and work as expected.