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)
Any update on this? If this worked, a lot of one-off debugging problems would be a bit simpler for me.
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.
@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: