Runtime: Debugger.Launch doesn't work correctly on coreclr on Windows

[stephentoub]

Repro:
```C#
using System;
using System.Diagnostics;

public class Test
{
public static void Main()
{
Console.WriteLine("1");
Console.WriteLine("2");
Debugger.Launch();
Console.WriteLine("3");
Console.WriteLine("4");
}
}

With .NET Framework, I can compile this, run it from the console, and the Debugger.Launch pops the attach dialog asking which VS I want to use and which debugging engine to employ.  I'm then in the debugger broken into the app on the Launch line, and I can successfully F10 to step to the WriteLine for "3" and "4".

With .NET Core 2.0 (built with the latest source), the same thing happens, up until the debugger breaking in.  VS opens, but I have to manually hit the pause button to break into the app.  Then I find myself on the Launch line, but neither F5 nor F10 work successfully; instead, they start running the app again, but no forward progress is made, and breaking in again reveals being on the same line, with this stack:

ntdll.dll!NtWaitForMultipleObjects

() Unknown
KernelBase.dll!WaitForMultipleObjectsEx() Unknown
[Managed to Native Transition]

tmpapp.dll!Test.Main() Line 10 C#
[Native to Managed Transition]
CoreRun.exe!00007ff68c9f2fa3() Unknown
CoreRun.exe!00007ff68c9f33dc() Unknown
CoreRun.exe!00007ff68c9fc149() Unknown
kernel32.dll!BaseThreadInitThunk
() Unknown
ntdll.dll!RtlUserThreadStart
() Unknown
```
That's the case with both VS2015 and VS2017, and with selecting the managed CoreCLR debug engine.

Am I missing some component that's supposed to make this work?

[lt72]

@mikem8361 @gregg-miskelly : any ideas?

[gregg-miskelly]

@lt72 there is no real Just-In-Time debugging support for CoreCLR. To make this work we would need to work out a contract between the Just-In-Time debugger and CoreCLR so that we could know how to know that a Just-In-Time launch is for CoreCLR debugging, and how to tell the CoreCLR to resume execution.

[mikem8361]

Yes, this feature has never been implemented (the interaction with the JIT debugger). It looks like coreclr does initialize debugging and should be attachable. It is just that the JIT debugger is NOT launched automatically to do the attach.

[lt72]

@stephentoub: Steve, did you inquired because you found this accidentally or do you need this feature for any reason?

[stephentoub]

Found it while trying to use it for my own debugging purposes.

[danmosemsft]

@lt72 what's the prospects of getting this implemented? It would certainly help folks working on CoreFX, as well as customers.

[lt72]

@noahfalk FYI
We will put this work item on the 2.1 planning and prioritize according to other needs. We should be able to make a call by end of July, when planning is finalized.

[gregg-miskelly]

@danmosemsft You are asking for only Windows AND only full VS, correct? I don't see how we could make the full end-to-end work in VS Code, or in some sort of remote VS case.

[danmosemsft]

@gregg-miskelly yes, most people debug most of the time on Windows with VS. This would make it easier, particularly when a test spawns a child process.

[ghost]

If making it work requires changes to it anyway, shouldn't it be removed it since it doesn't work?

[mellinoe]

Any update on this? If this worked, a lot of one-off debugging problems would be a bit simpler for me.

If making it work requires changes to it anyway, shouldn't it be removed it since it doesn't work?

That's not the worst option, really. This method's current behavior is very misleading -- probably doubly-so for a regular .NET Core user who doesn't understand that it's broken.

[danmosemsft]

This would significantly help devs working on the BCL libraries.

[lt72]

We will not be able to get to this anytime soon. We can try and see that this gets some traction sometimes before the end of October.

[stephentoub]

We can try and see that this gets some traction sometimes before the end of October.

@lt72, any luck?

[lt72]

@mikem8361: can you please take a look to this one?

[mikem8361]

.NET Core really doesn't use the registry so I purpose that coreclr uses an environment variable like COMPlus_AeDebug that works like the AeDebug registry key so you could set it to something like ""C:\WINDOWS\system32\vsjitdebugger.exe" -p %ld -e %ld" and end up with similar behavior to the desktop.

The default if the environment variable doesn't exists is the current behavior.

I worry about the security problems with launching something from an environment variable.

/cc @jkotas

[gregg-miskelly]

I don't think you want to use an environment variable for this -- this is a system setting, so it should really be in the registry on Windows, and as a configuration file on other OSs.

I would like to suggest that we:

• Use a registry key on Windows
• Do NOT use AeDebug\Debugger, so that we can use a different command line format from native exceptions and so we aren't just launching a native debugger
• Come up with a command line contract that makes it easy for the JIT debugger to understand the basic details of the exception (I think the exception type and maybe message?) without needing to load up any other dll (ex: these things can either be passed on the command line, or the address of some descriptor struct is passed on the command line)

[danmosemsft]

If you invent a new mechanism I hope there is a way to make it work with existing VS and native debuggers...that should technically work I assume? It is sometimes useful to launch a native debugger possibly to use SOS.

[danmosemsft]

Perhaps if the new key is not set it can fall back to AeDebug?

[gregg-miskelly]

No. VS will need to do work to support any .NET Core JIT debugging scheme.

Windbg could do something, but I think it would be a poor trade-off to fall back AeDebug when the 99% case is that it will not work. Just write the new key with the Windbg command line if you want Windbg.

[mikem8361]

@jkotas, would you recommend using a registry key in .NET Core?

[jkotas]

I assume that this registry key will be set by the VS debugger machine global installer. Is this correct? If it is the case, I do not see a problem with it.

There are cases where .NET Core depends on machine global state whether it is via registry or by other means. There is not problem with that. The problem is when .NET Core its own SxS state is stored in machine global location.

[gregg-miskelly]

Correct, the registry key would be set by the VS installer.

[mikem8361]

Also see dotnet/runtime#6364

[danmosemsft]

@lt72 @mikem8361 is this scheduled? It is often needed and seems a key part of the .NET Core debugging story.

[mikem8361]

I'm looking into this week.

[mikem8361]

Now that PR https://github.com/dotnet/coreclr/pull/15722 has been merged that changes the JIT Debugging registry key ("SOFTWARE\Microsoft\.NETCore\JITDebugging"), it is in the VS team's court.

[lt72]

@caslan @gregg-miskelly any chance we get this into 15.6 or very early 15.7?

[caslan]

@lt72, added an item in the backlog for this. 15.7 Preview 1 or Preview 2 should be doable.

[lt72]

That will work, thank you.

[lt72]

This should now be working as expected with the latest d15.7stg and dotnet 2.1.2-preview-007474. Closing on behalf of @caslan.
@mikem8361 FYI

[noahfalk]

Actually closing : )