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

Repro:

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?

About this issue

  • Original URL
  • State: closed
  • Created 7 years ago
  • Reactions: 1
  • Comments: 32 (31 by maintainers)

Most upvoted comments

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.

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

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

@lt72, any luck?

Actually closing : )

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

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

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)