I'm trying to debug a C# dll from a native C++ executable. I have a C# COM object that is loaded and run from native code via IDispatch. Everything is built in Debug, both C# and C++ code. Whilst I can see all the c++ code, and all the c++ dlls have their symbols loaded and available for debugging, breakpoints etc the C# code refuses to play.
What I do see is that the C# dlls all refuse to load their symbol pdbs, reporting "skipped loading symbols for ngen binary" in the modules window.
Incidentally, I am debugging the C# solution here, I have set the native executable as the 'start external program' in the COM project's debug settings.
Now I can start the C++ executable and then attach to it, and then all works as I expect - the symbols load and I can set breakpoints in the C#.
This is using Visual Studio 2013u4. Is there a setting to enable mixed-mode debugging? One niggle is that the native code was built with VS2010.
Here's the Module window - note all pdbs and dlls are in a single directory, you can see the c++ dlls loaded, but not the C# ones.
Here's the modules window - note the 3rd entry for the EvCom dll (the COM object) which I assume is the entry enabling debugging.
There is nothing of any interest in the Output window, when it comes to load the COM dll, I see the following (in the case of attach to running process, the other only has 2 Loaded lines instead of 3).
'Explorer.exe' (Win32): Loaded 'C:\Dev\...\lib\debug\EvCom.dll'.
'Explorer.exe' (Win32): Loaded 'C:\Dev\...\lib\debug\EvCom.dll'.
'Explorer.exe' (Win32): Unloaded 'C:\...\lib\debug\EvCom.dll'
'Explorer.exe' (Win32): Loaded 'C:\Dev\...\lib\debug\EvCom.dll'.
One thing of interest - I checked the "Use Managed Compatibility Mode" in the debug settings and, thought it still doesn't load my symbols when starting debugging, it only shows 1 entry in the modules list. This time saying "No native symbols in symbol file" for the C# dlls.
It looks like the problem is not being able to select the debugger type in VS2013 (or 2012). This connect article suggests its "by design" with some workarounds.
Turns out it is all down to the changes in debug engine for .NET 4.0
.NET 4 and greater uses a different debug engine than .net 3.5 and below, when you start debugging a native application the debugger will choose a .net debugger for you (defaults to .net 4.0) and if your .net dll is built using this platform, all will be well - breakpoints will be hit.
If your loaded dll is .net 3.5, then the debug engine will not understand the dlls that are loaded and will refuse to load symbols or debug.
The solutions are either to rebuild as .net 4, or start the native executable and attach to it (where you can select the debugger type, either 'old' .net or 'new' .net) or you can create a project from the executable and set its debug settings to specify the right debugger.
What I find annoying is that Microsoft could easily have started the debugger using the .NET framework type specified in the project you're debugging (after all, when debugging a dll and specifying an external program, you still want to debug the dll you're pressing F5 for, so you know what debugger to use!)(What is even more annoying is that once managed debugging is started in a loaded dll, you can then step into projects built using older .net frameworks without problem).
More details on this Microsoft connect article
(If your executable isn't already in your solution, File > Add > Existing project, then right-click and set it as start-up project.)
Right-click your start-up project, Properties, Debugging, Debugger Type = Mixed.
In my case I have own symbol server and TFS, so I
enabled option TOOLS > Options > Debugging > General > "Enable source server support" and three child options.
For me is was debugging a UWP app in Xamarin Forms:
Cause:
The debugger is skipping files not in the .NET environment.
Solution:
Uncheck Debugging => General => Enable Just My Code
Related
From my C# application I'm integrating with a 3rd-party DLL using interop (DllImport). I suspect that DLL is written in C++ or maybe C++/CLI.
That 3rd-party DLL refuses to run in a debugger (when running my application from within Visual Studio, the DLL produces a message box saying it won't run in a debugger).
Is there a Visual Studio setting oder some interop hack which allows me to run my application in debug mode, but without having the debugger attached to the external 3rd-party DLL?
Because the information you provided is limited, I have given several solutions, please try them one by one.
Dll project, properties - configuration properties - debugging - set the command to bin\Debug*.exe of the exe project that calls the dll
Dll project, properties - configuration properties - debugging - set the debugger type to local only
Dll project, properties - configuration properties - general - set the output directory to the bin\Debug directory of the exe project that calls the dll
Set a breakpoint in the dll project, and then regenerate the dll project, in order to output the dll to the set directory
Exe project, properties - debugging - enable unmanaged code debugging
Exe project, set as startup project
Tools - Options - Debugging - Remove the check mark in front of (Enable "Only My Code") and use Managed Compatibility Mode at the same time. In the c++ project settings, the debugger type should be set to automatic (not set to native only).
i have a simple c# app that is using DLL from another project which is compiled with debug: full mode
i can step into the code of the DLL but when I'm in the source code i can't click + jump to other source code that is related to the DLL.
how do i configure Visual Studio 2019 to be able to fully navigate the DLL I'm referencing
this is by the way is enable somehow by default in VC++
This is more of a comment/suggestion, but I needed multiple lines, check out the following
The other DLL needs to be built using the same framework version as the code you are searching from
as Paval said in Tools -> Options... -> Debugging -> General make sure the "Enable Just My Code" is not selected
When you are in 'source code' make sure the PDB for the dll you are referencing is in the build directory for the selected configuration
I want to know where is location that debug info was stored when I debugging c++ native dll project.
I have 2 project in my solution, C# managed project and C++ dll project. When I insert break point native dll, vs stops well in C#'s native calling with dllimport. And, I copied native dll to managed project directly (so managed project has native dll file only for native project, without pdbfile), vs stops breakpoint in native calling too! What makes this possible? managed project has no info for pdb file of native dll, but it seems that vs still can access native pdb file. Anyone can explain that?
Debugging an unmanaged dll is the same regardless of how the application was started (via .net or not). Wherever the dll is loaded from, Visual Studio will look for a .pdb file in the same directory and load that if it exists.
You can see when this happens in your output window (Debug->Window->Output). You will see a line like:
'<your-exe>.exe': Loaded '<path-to-dll>\<your-dll>.dll', Symbols loaded.
If you are writing a .net app though, none of this will happen if 'unmanaged code debugging' is turned off in your .net application project settings (Properties->Debug->Enable Debuggers)
PDB loading follows a number of rules. The first attempt of visual studio, is to assume the DLL was built on the debugging machine. There is a fully qualified reference to the pdb in the dll. That rule is firing. Later on, it uses the _NT_SYMBOL_PATH variable, and can find multiple versions of a pdb from the same dll, if a symbol server is referenced.
I have created a visual c++ 6.0 dll project and using it from my c# code. Now i want to debug the dll but i am not able to do it.
I choose the following option to do it:
put the breaking point in my visual c++ project code.
build the dll and copy it into the directory of my c# project.
Now i build my c# project and dll works fine (method are calling perfectly).
Now i want to debug the dll.
I follow a blog and open the c++ project and choose the Attach to process from vc++.
but i am not able to find the running process of visual c# project, whereas it available at task manager process.
In my c# project solution i have two project i.e.
web service (i called the dll method at the time of accessing a url)
Another one is webform application which starts the web services.
Now please help me how should i debug my dll. I have followed so many blogs but all of them are focusing on Attaching process method which is not working in my condition. What should i do?
You'll need to enable unmanaged debugging, it is not turned on by default in either scenario because your main program is managed.
You do it in your C# project with Project > Properties > Debug tab > tick the "Enable unmanaged code debugging" checkbox.
You do it with Tools > Attach to Process by clicking the Select button. Choose the "Debug these code types" radio button and tick both Managed and Native. You may have to resort to only native if your process is 64-bit.
Set a breakpoint in the DLL's source code and be sure to write C# code that exercises the DLL function. If you still have trouble getting a breakpoint then use Debug > Windows > Modules and verify that you see the DLL in the module list. Get additional troubleshooting info by right-clicking it, select Symbol Load Information. Which shows a trace of where the debugger looked for the PDB file.
You can add C++ project to the your C# solution and add reference directly to the project (not dll), then you will not be needing to copy DLL. After that just start normal debugging (F5) of your C# project, and breakpoints will be working for C++ project too. This way will be very comfortable for debugging. I have tried such debugging and did not change any other settings.
I have a C++ solution. The startup project is an exe. In the solution there are a number C# dlls (targeting .NET Framework 2.0) that are registered for COM interop. When I put a breakpoint in the C# code I get the hollow red breakpoint with "No native symbols in symbol file"
I have tried setting Project Property Pages -> Debugging -> Debugger Type to Mixed on the start-up project that calls the COM methods.
I have checked Debug -> Windows -> Modules. It has loaded my dlls, and the symbol status is "No native symbols in symbol file".
This is not the end of the world because if I do Debug -> Start Without Debugging and then Debug -> Attach to Process, changing the Attach To: to Managed (v2.0, v1.1, v1.0) code, Native code. Then I hit breakpoints in both the C++ code and C# code.
So I have my workaround but I reckon if I can do it by attaching to process - I should be able to do it by just debugging.
How can I hit my C# breakpoints by just doing Debug -> Start Debugging?
I was able to debug my C# dll from a C++ project in VS2008 by doing the following:
In the C++ project's properties, goto Configuration Properties -> Debugging. Set "Debugger Type" to Mixed. "Attach" should be set to No.
In your C# project properties, in the Debug tab, set the "Start External Program" to your C++ project's executable.
I know it's a little bit old but I found a practical solution for the problem.
I had the same problem while using a C++ application which uses a C# COM-Object. I tried several settings within Visual Studio on the C++ and C# side. Nothing helps until I tried manually launching the Debugger.
You can use
Debugger.Launch();
to manually start the Debugger on your C# DLL. I know this is not the best but a practical way. In later productive environments you have to remove the Debugger launch function :).
Regards
I am unsure if this will help but we work a lot with C# and C++. I found this to be possible by placing the C++ project and the C# project in the same solution and enabling "native debugging" in the C# project. Then I was able to jump back and forth between them while debugging.