Debug C++ dll from C# works in VS2013, but not VS2010 - c#

Enabled "Enable native code debugging" setting in 2010/2013 and verified debug symbols are loaded. Cannot step into the C++ source. After running the same project in VS2013 (without changing any settings), code steps into the C++ source. Why?
Note: This is being run from a c# unit test project.

Having the PDB file next to the DLL is not enough to debug the DLL.
You will need to have access to the DLL code so that you can step into it from your debugger.
Have a look at that thread:
http://social.msdn.microsoft.com/Forums/en-US/69e84750-6636-4656-bbd4-8d3586290af3/how-to-debug-native-c-dll-from-c-application?forum=netfxcompact

Related

How to debug and step into a native code project from inside a .NET core C# project?

I am developing a .NET core (.NET Standard 1.6) application in VS2015. The application calls C++ code via P/Invoke. Now I need to step into the C/C++ code of my native dll project.
In regular .NET application, by enabling unmanaged code debugging in the property window of the application, we can step into the C/C++ code directly:
But I can't find such option on a .NET core project. And I know that I can attach the debugger to the application to debug native code only, but that's not suitable for my case.
Again, I want to debug from managed C# code into native C/C++ code.
Any ideas?
Maybe I should switch back to .NET Framework so I can debug the native code. It's really hard to debug by printf. :(
UPDATE
The mixed mode debugging, i.e. debugging from managed C# code into native C/C++ code, has been implemented. See Tutorial: Debug managed and native code in Visual Studio.
UPDATE
The feature may have already been implemented, see this.
Just as #cynic said, this is not yet supported now (2016-11-1).
That can be verified by following steps provided by cynic.
Put a pause in your program (e.g. a Console.ReadKey call).
Attaching to the dotnet.exe process selecting "Managed (CoreCLR)" and "Native" code types
You'll get a message box stating explicitly that "Interop debugging is not supported".
Here is a proper way to debug the native dll.
Right click on the solution, Add Existing Project
Open 'dotnet.exe'. This is normally installed to 'C:\Program Files\dotnet\dotnet.exe'.
You should now see another node in solution explorer for dotnet.exe. Right click it to bring up project properties:
Change the working directory to be what you want
Change the arguments to be the path to your built dll
Change the exe project to your startup project
RECOMENDED: Go to Tools->Options->Projects and Solutions->Build and Run, uncheck 'Only build startup projects and dependcies on Run'

Breakpoint not getting hit in managed code

I am using Visual Studio 2010 & .NET Framework 3.5.
In my solution, I have a C++ project and a C# project. The C++ code in the former project invokes the managed code in the latter via (reverse) COM Interop. Both the dlls would get loaded into an external application. Both the projects are configured to start the same application when debugging is started.
Problem:
While debugging native code, the breakpoints are hit; however, while i want to debug the managed code, the breakpoints never get hit. This is the behavior regardless of the whether i start the application from native project or managed project.
Options Tried:
Setting the Debugger Type option in Native project properties to Mixed / Managed Only. Either case doesn't help.
Enabling / Disabling 'Enable Unmanaged code debugging' in Managed project properties also does not help.

Debugging unmanaged application and managed C# dll at the same time

My setup:
Application.exe (Visual Studio 6.0 C++)
Component.dll (Visual Studio 2010 C#)
Application.exe uses Component.dll
I want to be able to debug my Visual Studio 6.0 C++ application and the Visual Studio 2010 C# component that it uses at the same time but I'm not sure if this is possible or not.
I tried to launch the application from Visual Studio 6.0 and attach to that process (Application.exe) in my Visual Studio 2010 component solution but when I go to attach to the process (Application.exe) it is greyed out. I tried switching the Attach To: to Native but this does not allow me to attach to this process. My Application.exe is still greyed out in the window.
Is it possible to do this and if so how?
There can be only one debugger attached to a process, that's why the selection is grayed out. You have little use for the VS6 debugger, it doesn't know anything about managed code. You'll have to debug this from VS2010. Right-click your C# project, Properties, Debug. Select "Start external program" and select your C++ .exe. Tick the "Enable unmanaged code debugging option".
Set a breakpoint in your C# code and press F5 to start the .exe. The breakpoint indicator will turn solid as soon as the C++ code loads you DLL. Debugging the C++ code might be possible too although you're working with a .pdb from the previous century. You cannot single-step from the managed code into the C++ code, you have to set a breakpoint.
You cannot attach two different debuggers to the same process.
Instead, you can attach it only to VS2010, but attach it as both managed and native.

Debugging A VC++ 6 DLL Called From C#

I have an old DLL written in Visual Studio 6 which I am calling from C# written in Visual Studio 2010. The DLL is not working properly and I want to debug into it. How can I do this? I have the source code project but cannot see how I can step into it.
Note: When I say "doesn't work", the call to the DLL succeeds and it gets a little way through the code in the DLL before failing, but I want to track down exactly where.
The technique of debugging a DLL is described here on MSDN. You'll need to do this from Visual Studio 6 (i.e. the tool that developed the DLL) and so the terminology will have changed. But the principles remain the same.
Attaching VS6 debugger on the .NET process shall work, as long you have the PDB file with the corresponding binary and the sources. You can break only on DLL code, however.
Attaching another VS+ shall work if the flag "Allow unmanaged debugging" is checked, but there is a possibility that symbols are not loaded by the debugger. A recompilation of the DLL shall solve the last problem.
Open Visual C++ Dll project, set breakpoint where you need. In the Project properties, Debug, Executable for debug session, type .NET executable file which uses this Dll. Start debugging (Go). When VC++ function is called, debugger breaks. Using this way, you can debug only unmanaged VC++ code.
Another way is to start debugging from .NET client in mixed debugging mode. Add VC++ project to the solution and rebuild it to debug both managed and unmanaged code.

How to debug without Visual Studio?

Python -> c++ dll -> c# dll
I have a com interop c# dll that is loaded in a wrapper c++ dll throught the .tlb file generated in c# to be used in a python project. When I run in my computer it works fine but when I run in a computer that just got formated it gives:
WindowsError: exception code 0xe0434f4d
I have the redistribute c++ installed and the .net compact framework 3.5 on the formatted computer.
How can I see what is the correct exception on a computer that does not have visual studio installed? How can I debug all of this? I can't debug the dll's itself can I?
Note: in my computer all works well so maybe is some dll or file missing. I allready used Dependency Walker to see if there's some dll missing, and nop!
Download the Microsoft Debugging Tools for Windows.
It contains the WinDbg debugger, which can also be used for debugging.
Advantage of WinDbg over Visual Studio is that you have much more low-level commands to find problems.
Disadvantage of WinDbg is that it's not that user friendly (compared to Visual Studio).
You can use WinDbg or other good applications to attach to the process or even run the application in the debugger application.
Another really good software is OllyDbg.
Both of these will both allow you to set breakpoints on different locations in your application.

Categories