2
votes

I have a .NET Core 2.0 C# program that starts another .NET Core 2.0 C# program. I want to automatically attach the VS 2017 debugger to the sub-process, either as soon as it starts or at a certain point in its execution.

I tried adding a System.Diagnostics.Debugger.Launch call to the sub-process code and this does pop up the VS JIT debugger dialog, but:

  • If I don't check "Manually choose debugging engines" it debugs only native code. The process is stopped at a breakpoint, as expected, but I cannot debug my C# code.
  • If I do check it and check "Managed" I still cannot uncheck "Native" - it says "For the debugger to handle the current exception, 'Native' code must be selected." It then starts mixed-mode debugging, but does not enter break mode. If I break manually I can see that the thread that called Debugger.Launch has the following stack trace:
 ntdll.dll!ZwWaitForMultipleObjects()
 KernelBase.dll!WaitForMultipleObjectsEx()
 kernel32.dll!WaitForMultipleObjectsExImplementation()
 [Managed to Native Transition]
 (my method that called System.Diagnostics.Debugger.Launch)

It's just "stuck" in this method and I cannot step out of this to continue running my managed thread, so this is completely useless.

How do I attach the debugger in such a way that I can stop at a breakpoint, inspect managed variables and then continue?

1
Do you select the relevant program types: Managed, Native, or Script under Tools->Options->Debugging-JIT? Or custom the JSON file like this thread: github.com/dotnet/project-system/issues/1125Jack Zhai-MSFT
Yes, I checked "Managed". I don't actually want to debug native code, but "Native" is checked and cannot be unchecked, as I said.EM0
What about this issue? Would you please share the latest information in your side?Jack Zhai-MSFT
@JackZhai-MSFT I don't think I understand the relevance of the GitHub issue you linked. It talks about enabling native debugging, but I don't want that. I want to debug managed code (only).EM0
Just ignore the above comment, I added an answer before,Jack Zhai-MSFT

1 Answers

0
votes

Debug.Assert is probably the easiest if they own the second process. Assuming that’s available in .NET Core.

You could look here for more information on why their Debugger.Launch is behaving like it does:

https://blogs.msdn.microsoft.com/jmstall/2006/02/16/ifeo-and-managed-debugging/