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.
Related
I'm quite new to VS Code. I have been debugging DLLs for 3rd party applications earlier in Visual Studio but it seems all the tools available there are not available in VS Code.
What I have been doing in VS earlier is:
create, develop and build my DLL to the plugins folder of that 3rd application (with references to the 3rd party application's libraries)
add the 3rd party exe as another project and set it as startup project.
when starting debugging session, VS automatically launches/attaches to my dll, i.e. I can step through my code when I start the plugin inside the app.
I am able to successfully build the DLL in VS Code to the correct folder and it works (will show me the simple msgbox i am waiting for). However, when I try to debug it by attaching the debugger to the 3rd party app process, the debugger does not stop at the breakpoints. When I hover over the breakpoint during debugging (which is not red anymore during debug), I get the message "No symbols loaded for this document". I guess I'm doing something wrong. The .pdb for the DLL is in that plugins directory. Is this because the debugger does not find it? Honestly, I'm not very well in with the launch.json contents yet (no need to work with those in full VS). What is the best way (if any) to do this kind of debugging in VS Code? In case this is something that definitely can't be done in VS Code, please let me know, so I know I need to return back to full IDE.
It turned out I just had some issues in my launch.json. I am now able to step through my code and the UX is practically the same than that with full VS. Problem solved.
#vernou Thanks for the link anyway!
So i have one C# desktop application that references a C++ dll. This dll project was developped by other persons, it can't be compiled on visual studio, I use NMake with the parameter -DCMAKE_BUILB=Debug to generate the .dll & .PDB files. I copied the files on the C# project reference folder and enabled Debugging of Unmanaged Code in the project properties. So im actualy able to debug unmanaged code from the dll. My issue is that i can't inspect any of the object nor the variables im lokking in the unmanaged code side. The visual studio contextual inspector doen't show when I passe my mouse on the objects/variables & when trying to add a spy it's not better. I need to see the values of the objects/variables from the unmanaged code to make sure it doen't do anything wrong.
Note : a coworker of mine had already opened a thread here How add spy on Visual studio using unmanaged code
But sadly the thread was closed for lack of details, so I tried to add more details to describe the issue.
Pls don't close this one
Inspect unmanaged C++ objects/variables on Visual studio 2017
Suggestion
Update 1
Please make sure that you have installed the C++ development and C# development workload in VS Installer. That's all the premises.
1) when you reference the path of the dll, make sure that the pdb file already exists under the reference folder(the folder where you referenced the dll) and then use DLLImport node to import the c++ functions.
2) Tools-->Options-->Debugging-->General-->check the option Used Managed Compatibility Mode
3) Right-click on your C# project-->Properties---> Debugging-->check the option Enable native code debugging
Also, check Allow unsafe code option under Build.
4) also, if your c++ dll is built with x64 platform, you should also use x64 platform to debug your c# main project.
In addition, you can refer to this similar issue for more detailed info.
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'
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
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.