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?
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/