-2

I have an unmanaged C++ application which has a dependency on a C# assembly (interacted via COM).

When I run my native C++ application through the VS debugger, breakpoints in C# code are disabled with an error no symbols are loaded. From this question I found to look in the Modules window: How do I remedy the "The breakpoint will not currently be hit. No symbols have been loaded for this document." warning?

However, my C# assembly DLL is not listed in the module list. When the application starts up in the debugger, my C# assembly is not mentioned in the Output window either when it is loaded and used. The C++ is only a simple wrapper around the C# code so not being able to debug C# code is a problem. I can't attach-to-process because the C# code is in an assembly not a separate application.

This question seems to be on a similar topic, but the converse situation, so I don't see any solution there: "The breakpoint will not currently be hit" error while debugging a mixed mode application (c# and unmanaged c++)

Is there a way to debug my managed C# code when used by an unmanaged native C++ application?

大陸北方網友
  • 3,696
  • 3
  • 12
  • 37
Mr. Boy
  • 60,845
  • 93
  • 320
  • 589
  • I don't think there any other steps outside covered in those 2 questions even exist... Can you please list steps you *already done* so someone can try to come up with new once? (like "my code only" and "mixed debugging") – Alexei Levenkov Jun 30 '20 at 16:02
  • 1
    You need to be debugging **managed code** (Attach to -> Select), and you're probably not. Is your assembly already loaded and the CLR running when you attach the debugger, and are you attaching to a managed module, or do you hit F5 on your C++ program? – CodeCaster Jun 30 '20 at 16:06
  • Isn't your assembly running in an out-of-proc COM server (i.e. as a separate process)? -- Maybe try coding a Debugger.Break(); into it in a place that you know will always be hit and see what happens. – 500 - Internal Server Error Jun 30 '20 at 16:12
  • @AlexeiLevenkov those _are_ the steps I've tried... 1)realised no symbols are loaded 2)find SO questions, 3)determine the module isn't listed 4)stuck. – Mr. Boy Jun 30 '20 at 16:18
  • @CodeCaster I'm hitting F5 to run up the C++ application. What would I attach the debugger _to_ for the managed code? The only process I can see is the unmanaged one... should there be some special COM process I can look for? – Mr. Boy Jun 30 '20 at 16:21
  • 1
    To the same process, after it initialized the CLR. – CodeCaster Jun 30 '20 at 16:30
  • 1
    @CodeCaster aha I think you have answered it though I don't really understand quite how - I detached all, attached back to my running EXE and the C# assemblies and symbols are now shown. Are we back to having to run up the exe then attach, and hack some timer or flag to stop it doing anything - if you care to expand in an asnwer I think it will be useful! – Mr. Boy Jun 30 '20 at 16:40
  • I don't know how to properly explain it so I can't answer. There are different ways to debug code. If you want to debug managed code, the process must have loaded the CLR, then you can attach to it. Otherwise, the debugger will treat it as unmanaged code or whatever kind of executable it's running in. – CodeCaster Jun 30 '20 at 16:51
  • OK well this seems to be the issue, when it launches in the debugger COM hasn't yet loaded the C# assembly. If you attach to an initialized process, it has, and everything appears to work. Big headache mostly solved :) – Mr. Boy Jun 30 '20 at 16:59
  • So I've described my problem in quite a detailed fashion. I've demonstrated that I have looked for solutions and explained why they are not helping me... the comments have been useful and quite technical which suggests it is a valid question. And yet still I get down-voted. – Mr. Boy Jun 30 '20 at 18:20

1 Answers1

1

Based on CodeCaster's comment:

You need to be debugging managed code (Attach to -> Select), and you're probably not. Is your assembly already loaded and the CLR running when you attach the debugger

I was able to find a solution. If I start the application through the debugger, symbols for the managed assembly are not loaded at startup; the assembly is only loaded when one of its types is instanced via COM.

If I attach the debugger to an already-running process, the managed assembly is already loaded and now everything works as expected. It is not ideal if you want to set a breakpoint at startup, but it is a workable solution.

Mr. Boy
  • 60,845
  • 93
  • 320
  • 589
  • I do wonder why VS cannot load symbols of modules loaded after start-up though. If anyone knows better please share! – Mr. Boy Jul 01 '20 at 10:16