"skipped loading symbols for ngen binary" for C# dll

Question

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.

Coeternity

Right-click your C++ project, Properties, Debugging, Debugger Type = Mixed. – Osmunda

There is no C++ project, I'm debugging my C# project in VS2013, and there is no such setting there, the native project is built externally and not referenced inside VS as a project. – Coeternity

"I can see all the c++ code" is ... weird then. You must already have mixed-mode debugging enabled, only way to see C++ code. Focus on the weirdo warning about ngen binaries, that's not normal. You should never ngen debug code. Run ngen /uninstall to get rid of it. – Osmunda

I know, and the c# code is not ngened. Note vs2013 will debug the C# code as long as I attach to the exe rather than start it automatically. I assume its starting in native debug mode becuase the start program is native even though I'm debugging only C# projects, but I can't see why or how to change that. – Coeternity

@HansPassant thanks, it does look like you can no longer select the debugger type when starting debugging. A change introduced with .NET 4.0. – Coeternity

Answer 1

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

Coeternity

Connect link no longer works – Membranophone

Answer 2

(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.

Nevadanevai

did you read more than Hans Passant's comment? Check out the accepted answer for reasons why your answer isn't correct. – Coeternity

@Coeternity - I had a problem. I googled it. I found this page. The solution that worked for me was in a comment. Comments are transitory, therefore I copied it into an answer to make sure it is available for people in the future. Your answer goes a lot into the why, but the actual crux of the fix isn't clear. Reading it again now, I find that the answer is "set its debug settings to specify the right debugger", but without Hans Passant's comment I wouldn't know where to set the debug settings or what the "right debugger" is. – Nevadanevai

Perhaps as my situation is slightly different to yours (seeing as I'd already created a project from the executable) I should have asked a new question and posted this answer on that. But I thought that would be a waste of everyone's time. – Nevadanevai

Answer 3

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.

Sharpie

Answer 4

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

Cabinetwork