Debugging BCL test projects won't load test assembly

[sunkin351]

I am a potential contributor to the .NET BCL. I've encountered an issue trying to debug BCL tests from the VS test runner.

Description

I am unable to set breakpoints during debugging, unable to 'break all' (test will presumably continue running), unable to step through code as it will not break.

From the issues I've experienced, this problem shares similarities with issue #26732.

If a breakpoint is set beforehand, VS will inform me, hovering over it, that "No symbols have been loaded for this document", even though this is the test that is being debugged from the VS test runner. I assume this is the cause of my issues. All managed assemblies are of the Debug configuration.

Edit: Attempting to find the tests assembly in the VS Modules window, I find it missing, along with the BCL library it should be testing. The test(s) never complete no matter how much time its given. Note: I'm debugging the tests for System.Text.RegularExpressions

Configuration

System Config: Windows, x64 VS 2019 Version 4.8.04084

Trying to debug tests found in the master branch of this repository, after using the build command line tool to build everything.

Other information

I've talked with people in the discord about this, people there suspect that its not loading the debug symbols because they aren't being put in a spot that VS can find it. May or may not be fixable from the build script.

I admit that this may or may not be a completely isolated issue. I'm still not able to solve it myself.

[ghost]

Tagging subscribers to this area: @tommcdon See info in area-owners.md if you want to be subscribed.

Issue Details

---

I am a potential contributor to the .NET BCL. I've encountered an issue trying to debug BCL tests from the VS test runner. ### Description I am unable to set breakpoints during debugging, unable to 'break all' (test will presumably continue running), unable to step through code as it will not break. From the issues I've experienced, this problem shares similarities with issue #26732. If a breakpoint is set beforehand, VS will inform me, hovering over it, that "No symbols have been loaded for this document", even though this is the test that is being debugged from the VS test runner. I assume this is the cause of my issues. All managed assemblies are of the Debug configuration. ### Configuration System Config: Windows, x64 VS 2019 Version 4.8.04084 Trying to debug tests found in the master branch of this repository, after using the build command line tool to build everything. ### Other information I've talked with people in the discord about this, people there suspect that its not loading the debug symbols because they aren't being put in a spot that VS can find it. May or may not be fixable from the build script. I admit that this may or may not be a completely isolated issue. I'm still not able to solve it myself.

Author:	sunkin351
Assignees:	-
Labels:	`area-Diagnostics-coreclr`, `untriaged`
Milestone:	-

[danmoseley]

@sunkin351 could you please share the "symbol load information" output for a module that isn't loading symbols? https://docs.microsoft.com/en-us/visualstudio/debugger/symbol-load-information-dialog-box?view=vs-2019

That will tell us where it "looked".

[sunkin351]

'dotnet.exe' (CoreCLR: clrhost): Loaded 'D:\Programming\Repos\Dotnet_Runtime\artifacts\bin\System.Text.RegularExpressions.Tests\net6.0-Debug\xunit.runner.visualstudio.dotnetcore.testadapter.dll'. 
'dotnet.exe' (CoreCLR: clrhost): Loaded 'D:\Programming\Repos\Dotnet_Runtime\artifacts\bin\System.Text.RegularExpressions.Tests\net6.0-Debug\xunit.abstractions.dll'. 
'dotnet.exe' (CoreCLR: clrhost): Loaded 'D:\Programming\Repos\Dotnet_Runtime\artifacts\bin\System.Text.RegularExpressions.Tests\net6.0-Debug\xunit.runner.utility.netcoreapp10.dll'.

I believe the main issue is it didn't load any for these. Anything else related to tests also didn't have symbols loaded... The BCL libraries appear to have had their symbols loaded. Looking further...

[sunkin351]

Modules window reports that these assemblies did not have any symbols loaded.

testhost.dll
Microsoft.TestPlatform.CoreUtilities.dll
Microsoft.TestPlatform.PlatformAbstractions.dll
Microsoft.TestPlatform.CrossPlatEngine.dll
Microsoft.TestPlatform.CommunicationUtilities.dll
Microsoft.VisualStudio.TestPlatform.ObjectModel.dll
Microsoft.VisualStudio.TestPlatform.Common.dll
xunit.abstractions.dll

Which file am I looking at? testhost?

[danmoseley]

@sunkin351 we rarely need to debug xunit itself. Normally what we care about are the symbols for System.*.dll (both product and tests). Did symbols load for System.Text.RegularExpressions.Tests.dll and System.Text.RegularExpressions.dll?

[sunkin351]

Now that I'm looking for them in the modules window......... they don't appear to even be there... they're not in the list. Would I per chance be debugging a host application? Also, I'd like to point out that I've let this run with the debugger attached for 50 minutes and nothing has happened yet.

[sunkin351]

Due to that particular detail coming to light... This may be worse than I originally suspected...

[danmoseley]

@sunkin351 did you build the libraries in debug or release configuration? (when you ran build.cmd at the root what parameters did you pass it?)

If release, then you probably need to switch off "just my code" in the visual studio options.

[sunkin351]

I compiled every managed assembly in debug config. Only the native runtime is in release.

[sunkin351]

So, slight progress on experimentation... After installing a VS extension that allows the debugging of child processes, I've gotten as far as hitting breakpoints and reading variable values... Major progress to be sure... But then everything else is still janky as hell. Attempting to step through code doesn't quite work and instead acts like Continue would for starters... However these tests are setup, VS appears incapable of handling it right.

[danmoseley]

What solution did you open? If you open the S.T.RE.sln there should be no child processes when debugging..

[danmoseley]

@pgovind perhaps you can help - you've done this recently?

[tommcdon]

Attempting to step through code doesn't quite work and instead acts like Continue would for starters... However these tests are setup, VS appears incapable of handling it right.

Retail debugging can have this behavior due to both Roslyn C# and JIT optimizations leading to relatively few sequence points where the debugger can safely stop in the method. If the code is built in debug mode, the debugger should be loading the modules as non-optimized. This can be confirmed by looking in the modules window. If the modules are being loaded as optimized, you can you try enabling "Suppress JIT optimization on module load (Managed Only)" under Debug->Options. To further improve the experience you might want to consider setting the COMPLUS_ReadyToRun environment variable to 0 (zero). This will cause all ready-to-run library code to be JIT'd.

[SingleAccretion]

I believe @sunkin351 used the ./build -vs System.Text.RegularExpressions command to open the solution.

@tommcdon FWIW, I've "debugged" the issue and concluded the following (this is all if you do "Debug Test" from VS, without the enablement of native code debugging and the use extension for child processes): 1) The debugger is being attached to the "right" process, namely dotnet.exe from the testhost directory. 2) The parent process of the testhost is stuck waiting on test results. 3) The testhost itself is stuck as well, and it turns out it is not that easy to understand why. It hasn't yet loaded the assemblies under test (neither the test assembly itself, nor the source assembly). I've captured the dump, but VS refuses to analyze it (for managed code) because mscordi.dll is not properly signed.

Viewing the stack of the main thread in WinDbg reveals that it is waiting on a lock (from the call to Task.Wait()). It also reveals that the thread that looks related to the debugger has failed with a stack overflow and is waiting on a lock to log the failure in EEPolicy::HandleFatalStackOverflow, this lock being used by some other 6 threads as well:

WinDbg output

Stack trace of thread `5b34`: ``` # Child-SP RetAddr Call Site 00 00000035`de144468 00007ffe`c295a34e ntdll!NtWaitForSingleObject+0x14 01 00000035`de144470 00007ffe`63fee4ae KERNELBASE!WaitForSingleObjectEx+0x8e 02 00000035`de144510 00007ffe`63fee778 coreclr!EEPolicy::HandleFatalStackOverflow+0x172 [C:\Users\Accretion\source\dotnet\runtime\src\coreclr\vm\eepolicy.cpp @ 647] 03 00000035`de144b90 00007ffe`63fac9e8 coreclr!EEPolicy::HandleStackOverflow+0xb4 [C:\Users\Accretion\source\dotnet\runtime\src\coreclr\vm\eepolicy.cpp @ 149] 04 00000035`de144bd0 00007ffe`645c20ea coreclr!CLRException::HandlerState::SetupCatch+0x98 [C:\Users\Accretion\source\dotnet\runtime\src\coreclr\vm\clrex.cpp @ 880] 05 00000035`de144c90 00007ffe`6453d6b0 coreclr!`EEDbgInterfaceImpl::TraceManager'::`1'::catch$16+0x92 [C:\Users\Accretion\source\dotnet\runtime\src\coreclr\vm\eedbginterfaceimpl.cpp @ 1267] 06 00000035`de144ce0 00007ffe`6453b62e coreclr!_CallSettingFrame_LookupContinuationIndex+0x20 [d:\agent\_work\31\s\src\vctools\crt\vcruntime\src\eh\amd64\handlers.asm @ 98] 07 00000035`de144d10 00007ffe`c51d0696 coreclr!__FrameHandler4::CxxCallCatchBlock+0x1de [d:\agent\_work\31\s\src\vctools\crt\vcruntime\src\eh\frame.cpp @ 1393] 08 00000035`de144de0 00007ffe`63dd1c49 ntdll!RcConsolidateFrames+0x6 09 00000035`de2bbfb0 00007ffe`643cf869 coreclr!EEDbgInterfaceImpl::TraceManager+0x2d9 [C:\Users\Accretion\source\dotnet\runtime\src\coreclr\vm\eedbginterfaceimpl.cpp @ 1261] 0a 00000035`de2bc180 00007ffe`643c8525 coreclr!DebuggerThreadStarter::TriggerPatch+0xe9 [C:\Users\Accretion\source\dotnet\runtime\src\coreclr\debug\ee\controller.cpp @ 8247] 0b 00000035`de2be000 00007ffe`643c25eb coreclr!DebuggerController::ScanForTriggers+0xa71 [C:\Users\Accretion\source\dotnet\runtime\src\coreclr\debug\ee\controller.cpp @ 2642] 0c 00000035`de2be2a0 00007ffe`643c1a36 coreclr!DebuggerController::DispatchPatchOrSingleStep+0xa27 [C:\Users\Accretion\source\dotnet\runtime\src\coreclr\debug\ee\controller.cpp @ 2937] 0d 00000035`de2be6d0 00007ffe`643dbe46 coreclr!DebuggerController::DispatchNativeException+0x9ba [C:\Users\Accretion\source\dotnet\runtime\src\coreclr\debug\ee\controller.cpp @ 4242] 0e 00000035`de2be960 00007ffe`63dde01d coreclr!Debugger::FirstChanceNativeException+0x576 [C:\Users\Accretion\source\dotnet\runtime\src\coreclr\debug\ee\debugger.cpp @ 5627] 0f (Inline Function) --------`-------- coreclr!IsDebuggerFault+0x46 [C:\Users\Accretion\source\dotnet\runtime\src\coreclr\vm\excep.cpp @ 6575] 10 00000035`de2beb60 00007ffe`63ddde6d coreclr!CLRVectoredExceptionHandlerPhase2+0x18d [C:\Users\Accretion\source\dotnet\runtime\src\coreclr\vm\excep.cpp @ 7282] 11 00000035`de2bec40 00007ffe`63dde6e0 coreclr!CLRVectoredExceptionHandler+0x215 [C:\Users\Accretion\source\dotnet\runtime\src\coreclr\vm\excep.cpp @ 7197] 12 00000035`de2bed90 00007ffe`c51a83dc coreclr!CLRVectoredExceptionHandlerShim+0x1a0 [C:\Users\Accretion\source\dotnet\runtime\src\coreclr\vm\excep.cpp @ 7933] 13 00000035`de2bee10 00007ffe`c517b406 ntdll!RtlpCallVectoredHandlers+0x108 14 00000035`de2beeb0 00007ffe`c51cfe3e ntdll!RtlDispatchException+0x66 15 00000035`de2bf0c0 00007ffe`049631da ntdll!KiUserExceptionDispatch+0x2e 16 00000035`de2bf7e0 00007ffe`c513ad4f 0x00007ffe`049631da 17 00000035`de2bf870 00007ffe`c513a96d ntdll!EtwpEventApiCallback+0xdb 18 00000035`de2bf920 00007ffe`c5138883 ntdll!EtwpUpdateEnableInfoAndCallback+0xd9 19 00000035`de2bf970 00007ffe`c51383a2 ntdll!EtwpProcessNotification+0x53 1a 00000035`de2bf9a0 00007ffe`c513821d ntdll!EtwDeliverDataBlock+0xb2 1b 00000035`de2bfa30 00007ffe`c516ecac ntdll!EtwpNotificationThread+0x6d 1c 00000035`de2bfbb0 00007ffe`c5142536 ntdll!TppExecuteWaitCallback+0xa4 1d 00000035`de2bfc00 00007ffe`c31a7034 ntdll!TppWorkerThread+0x456 1e 00000035`de2bff00 00007ffe`c517d0d1 kernel32!BaseThreadInitThunk+0x14 1f 00000035`de2bff30 00000000`00000000 ntdll!RtlUserThreadStart+0x21 ``` Same thread, now `!clrstack`: ``` OS Thread Id: 0xaa4 (16) Child SP IP Call Site 00000035DE144680 00007ffe049631da [FaultingExceptionFrame: 00000035de144680] 00000035DE2BF7E0 00007ffe049631da ILStubClass.IL_STUB_ReversePInvoke(IntPtr, Int32, Byte, Int64, Int64, Int64, Int64) ``` Output of `!locks`: ``` CritSec +d0748f70 at 00000151d0748f70 WaiterWoken No LockCount 0 RecursionCount 1 OwningThread 5b34 EntryCount 0 ContentionCount 1 *** Locked CritSec coreclr!DebuggerController::g_criticalSection+0 at 00007ffe648e03c0 WaiterWoken No LockCount 7 RecursionCount 1 OwningThread aa4 EntryCount 0 ContentionCount 7 *** Locked Scanned 23 critical sections ``` Curiously, the finalizer thread appears to be waiting on the same section (`00007ffe`648e03c0`) as the thread spawned to log the failure: ``` Args to Child : Call Site 00000000`00003f25 00000151`d07d5990 00000151`0000012e 00000000`00000004 : ntdll!NtWaitForAlertByThreadId+0x14 00000000`00000000 00000000`00000000 00000035`dd2fde48 00007ffe`648e03c8 : ntdll!RtlpWaitOnAddressWithTimeout+0x81 00007ffe`648e03c0 00000000`00001722 00000000`00000000 00000000`00000070 : ntdll!RtlpWaitOnAddress+0xae 00000035`dd2fe0e0 00007ffe`64699bc8 00000000`ffffffe2 0000040a`000002b7 : ntdll!RtlpWaitOnCriticalSection+0xfd 00000000`000000a1 00000000`00000000 00007ffe`648e03c0 00000000`00000070 : ntdll!RtlpEnterCriticalSectionContended+0x1c4 00007ffe`648e03c0 00000151`d0810360 00000151`d080eab0 00000000`00000070 : ntdll!RtlEnterCriticalSection+0x42 00000000`00000000 00000035`dd2fe0e0 00007ffe`648e03c0 00000000`00000000 : coreclr!CrstBase::Enter+0x26b [C:\Users\Accretion\source\dotnet\runtime\src\coreclr\vm\crst.cpp @ 327] --------`-------- --------`-------- --------`-------- --------`-------- : coreclr!CrstBase::CrstHolder::{ctor}+0x16 [C:\Users\Accretion\source\dotnet\runtime\src\coreclr\vm\crst.h @ 382] --------`-------- --------`-------- --------`-------- --------`-------- : coreclr!DebuggerController::ControllerLockHolder::{ctor}+0x16 [C:\Users\Accretion\source\dotnet\runtime\src\coreclr\debug\ee\controller.h @ 1020] 00000151`d080eab0 00000035`dd2feb80 00000035`dd2ff070 00007ffe`648e03c0 : coreclr!DebuggerController::DispatchExceptionHook+0x4b4 [C:\Users\Accretion\source\dotnet\runtime\src\coreclr\debug\ee\controller.cpp @ 3332] 00000151`d0810360 00000035`dd2feb80 00000000`000000a1 00000151`d080eab0 : coreclr!DebuggerController::DispatchNativeException+0x847 [C:\Users\Accretion\source\dotnet\runtime\src\coreclr\debug\ee\controller.cpp @ 4189] 00000151`d0759230 00000035`dd2ff070 00000035`dd2feb80 00000035`80000003 : coreclr!Debugger::FirstChanceNativeException+0x576 [C:\Users\Accretion\source\dotnet\runtime\src\coreclr\debug\ee\debugger.cpp @ 5627] --------`-------- --------`-------- --------`-------- --------`-------- : coreclr!IsDebuggerFault+0x46 [C:\Users\Accretion\source\dotnet\runtime\src\coreclr\vm\excep.cpp @ 6575] 00000000`00000074 00000000`00000074 00000151`d080eab0 00000151`d0810360 : coreclr!CLRVectoredExceptionHandlerPhase2+0x18d [C:\Users\Accretion\source\dotnet\runtime\src\coreclr\vm\excep.cpp @ 7282] 00000151`d0810360 00000000`00000000 00000151`d080eab0 ffffffff`ffffffff : coreclr!CLRVectoredExceptionHandler+0x215 [C:\Users\Accretion\source\dotnet\runtime\src\coreclr\vm\excep.cpp @ 7197] 00007ffe`63dde540 00000000`00000000 00000000`00000000 00000000`00000000 : coreclr!CLRVectoredExceptionHandlerShim+0x1a0 [C:\Users\Accretion\source\dotnet\runtime\src\coreclr\vm\excep.cpp @ 7933] 00000035`dd2ff070 00000035`dd2feb80 00000000`00000000 00000000`00000000 : ntdll!RtlpCallVectoredHandlers+0x108 00000000`00000000 00000000`00000000 00000000`00000040 00000000`00000000 : ntdll!RtlDispatchException+0x66 00007ffe`641a8360 00000000`00000040 00000000`00000001 00000151`00000000 : ntdll!KiUserExceptionDispatch+0x2e 00000000`00000040 00000000`00000001 00000151`00000000 00007ffe`64728710 : KERNELBASE!wil::details::DebugBreak+0x2 00000000`00000000 00000000`00000000 00000000`00000010 00000000`00000001 : coreclr!ThreadSuspend::SuspendRuntime+0xa80 [C:\Users\Accretion\source\dotnet\runtime\src\coreclr\vm\threadsuspend.cpp @ 3574] 00000000`00000001 00000000`00000001 00000000`00000001 00000000`00000000 : coreclr!ThreadSuspend::SuspendEE+0x28b [C:\Users\Accretion\source\dotnet\runtime\src\coreclr\vm\threadsuspend.cpp @ 5718] 00000000`00000000 00000001`ffffffff 00000000`00000000 00000151`d08112d0 : coreclr!GCToEEInterface::SuspendEE+0x48 [C:\Users\Accretion\source\dotnet\runtime\src\coreclr\vm\gcenv.ee.cpp @ 28] 00000000`00000002 00000151`d07eed10 00000151`00000009 00007ffe`63c9c377 : coreclr!WKS::GCHeap::GarbageCollectGeneration+0x249 [C:\Users\Accretion\source\dotnet\runtime\src\coreclr\gc\gc.cpp @ 41625] 00000000`00000000 00000151`d0810360 00000000`00000002 00000000`00000002 : coreclr!WKS::GCHeap::GarbageCollect+0x11e [C:\Users\Accretion\source\dotnet\runtime\src\coreclr\gc\gc.cpp @ 40849] 00000151`d080eab0 00000000`00000001 00000000`00000001 00000000`00000029 : coreclr!FinalizerThread::WaitForFinalizerEvent+0x10f [C:\Users\Accretion\source\dotnet\runtime\src\coreclr\vm\finalizerthread.cpp @ 192] 00000035`dd2ffb70 00000035`dd2ff809 00000000`00000001 00000035`dd2ffb70 : coreclr!FinalizerThread::FinalizerThreadWorker+0x15c [C:\Users\Accretion\source\dotnet\runtime\src\coreclr\vm\finalizerthread.cpp @ 273] 00000035`dd2ffb70 00000151`d0810360 00000035`dd2ffae0 00000035`dd2ff9b0 : coreclr!ManagedThreadBase_DispatchInner+0xb9 [C:\Users\Accretion\source\dotnet\runtime\src\coreclr\vm\threads.cpp @ 7299] ffffffff`ffffffff 00000035`dd2ffaf8 00000151`d080eab0 00007ffe`6467d4f0 : coreclr!ManagedThreadBase_DispatchMiddle+0x76 [C:\Users\Accretion\source\dotnet\runtime\src\coreclr\vm\threads.cpp @ 7343] 00000151`d07ef230 00000151`d07ef230 00000035`dd2ffb08 00000000`00000000 : coreclr!``ManagedThreadBase_DispatchOuter'::`11'::__Body::Run'::`5'::__Body::Run+0x77 [C:\Users\Accretion\source\dotnet\runtime\src\coreclr\vm\threads.cpp @ 7502] 00000035`dd2ffb08 00000035`dd2ffb70 00000151`d07ef230 ffffffff`ffffffff : coreclr!`ManagedThreadBase_DispatchOuter'::`11'::__Body::Run+0x83 [C:\Users\Accretion\source\dotnet\runtime\src\coreclr\vm\threads.cpp @ 7504] 00000151`00000001 00000151`d080eab0 00007ffe`64015830 00000000`00000008 : coreclr!ManagedThreadBase_DispatchOuter+0xc7 [C:\Users\Accretion\source\dotnet\runtime\src\coreclr\vm\threads.cpp @ 7524] 00000151`d080eab0 00000000`00000000 00000151`d0810360 00000000`00000029 : coreclr!ManagedThreadBase_NoADTransition+0xca [C:\Users\Accretion\source\dotnet\runtime\src\coreclr\vm\threads.cpp @ 7572] 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : coreclr!FinalizerThread::FinalizerThreadStart+0x1bc [C:\Users\Accretion\source\dotnet\runtime\src\coreclr\vm\finalizerthread.cpp @ 382] 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : kernel32!BaseThreadInitThunk+0x14 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : ntdll!RtlUserThreadStart+0x21 ``` As do some other threads with very similar stacks at the top.

What's interesting is that just trying to "Debug Test" again from VS worked, but then when opening the solution again, it didn't, hanging with the same symptoms as above (the dump is night identical).

The issue should be reproducible if one follows these steps: 1) ./build clr -c Checked 2) ./build libs -c Debug -rc Checked 3) ./build libs.tests -c Debug -rc Checked 4) ./build -vs System.Text.RegularExpressions 5) Wait for the tests to be recognized and then click "Debug Test" on one of them for net6.0

If that would be of any interest, I can provide the dump.

[danmoseley]

VS refuses to analyze it (for managed code) because mscordi.dll is not properly signed.

@tommcdon can say, but I assume there are regkeys like these for that --

https://github.com/dotnet/diagnostics/blob/master/documentation/privatebuildtesting.md

[pgovind]

Hmmm the runtime repo infra is complicated enough that it could be any number of things. A couple questions followed by 2 suggestions:

1. Did you do a git clean -xdf and a build -clean before starting your build? I don't know why, but often this cleans up most of these VS issues.
2. You mention that you built everything in debug mode. The last time I tried this, the tests took forever (still less than 50mins though) to start/run because coreclr itself was in debug mode.

Suggestion 1 if you want to stick to VS: If you are up for it, can you do the following in a command line from `..path/to/repo/runtime/?

1. git clean -xdf
2. build -clean
3. build clr+libs -rc Release
4. build -vs System.Text.RegularExpressions
5. cd src\libraries\System.Text.RegularExpressions\tests
6. dotnet build /t:Test (This will build the test projects so VS doesn't have to)
7. Now go the VS window that was opened and go to the Test Explorer and debug your test

Suggestion 2 if you're ok with VSCode: Since your libraries built fine, you should be able to follow https://github.com/dotnet/runtime/blob/master/docs/workflow/debugging/libraries/debugging-vscode.md (I would still recommend cleaning and building coreclr in release with step 3 from Suggestion 1). The pdbs for each assembly live in runtime\artifacts\bin\testhost\net6.0-windows-Debug-x64\shared\Microsoft.NETCore.App\6.0.0. My guess here is that VSCode will find the dlls/pdbs here and you will be able to debug.

1 other option to try is to put Debugger.Launch() statements in the unit test and run it from the command line. Try to attach a new VS instance to see if that works?

[Kuinox]

I got the same issue on 2 different PCs:
Yesterday I cloned & built runtime completely without issue but had the same issue.
I followed every step but on 7. VS decided that it had to rebuild the solution, and failed because it was missing System.Compilers.(forgot).Unsafe. A rebuild from VS cleared that error, but I hit the same issue. Note that on one of my PC, VS does not enter in debug mode, on the other one it enter in debug mode but does nothing more.
Edit: VS Freeze if I try to detach the current process being debugged.

[danmoseley]

This is starting to suggest an issue with the debugger itself, or at least that's among the issues..

[danmoseley]

Can you use "dotnet build /t:test" on command line in the test folder for now... and Debugger.Launch() to debug? Does that work?

[Kuinox]

dotnet test => attaching to a new instance did work. (thanks :D) dotnet test => attaching to the instance that has System.Memory opened shows the issue.

Basically if you attach the debugger from the instance of VS with System.Memory it fail, but I can debug it with a new instance without any issue.

[sunkin351]

So then it wasn't just me... That's comforting. Thank you guys for your support in this matter.

[danmoseley]

@tommcdon thoughts about this one?

[danmoseley]

What versions of VS are you both using.. can you try the newest?

[Kuinox]

16.8.4, latest release AFAIK.

[SingleAccretion]

Reproduces for me both on 16.8.4 and 16.9 P3.

[tommcdon]

VS refuses to analyze it (for managed code) because mscordi.dll is not properly signed.

@tommcdon can say, but I assume there are regkeys like these for that --

On Visual Studio 2019:

1. Open developer command prompt
2. "%DevEnvDir%vsregedit.exe" set "%VSINSTALLDIR:~0,-1%" HKLM Ad7Metrics\Engine{2E36F1D4-B23C-435d-AB41-18E608940038} ValidateFilesForMinidumps DWORD 0

to reset it back to the original behavior:

"%DevEnvDir%vsregedit.exe" set "%VSINSTALLDIR:~0,-1%" HKLM Ad7Metrics\Engine{2E36F1D4-B23C-435d-AB41-18E608940038} ValidateFilesForMinidumps DWORD 1

[tommcdon]

00000035DE2BF7E0 00007ffe049631da ILStubClass.IL_STUB_ReversePInvoke(IntPtr, Int32, Byte, Int64, Int64, Int64, Int64) @tommcdon thoughts about this one?

@hoyosjs @jkoritzinsky This looks like it may be another manifestation of #47421

[Kuinox]

If I run dotnet test with a test containing Debugger.Launcher(), and attach with a new instance of VS, it works fine. But I cannot attach to a process that already tried to debug this code.