dotnet process silently crashes when debugger is attached #444
Description
We have a certain part of our code where the dotnet console process always crashes when the debugger is attached in a docker-compose project. The code executes correctly when started without a debugger, on native linux, and native windows.
System Info
Dotnet info
C:\repos> dotnet --info
.NET SDK:
Version: 8.0.401
Commit: 811edcc344
Workload version: 8.0.400-manifests.e85ccad0
MSBuild version: 17.11.4+37eb419ad
Runtime Environment:
OS Name: Windows
OS Version: 10.0.22631
OS Platform: Windows
RID: win-x64
Base Path: C:\Program Files\dotnet\sdk\8.0.401\
.NET workloads installed:
Configured to use loose manifests when installing new manifests.
[aspire]
Installation Source: VS 17.10.35201.131, VS 17.11.35125.118
Manifest Version: 8.1.0/8.0.100
Manifest Path: C:\Program Files\dotnet\sdk-manifests\8.0.100\microsoft.net.sdk.aspire\8.1.0\WorkloadManifest.json
Install Type: FileBased
Host:
Version: 8.0.8
Architecture: x64
Commit: 08338fcaa5
.NET SDKs installed:
6.0.425 [C:\Program Files\dotnet\sdk]
8.0.304 [C:\Program Files\dotnet\sdk]
8.0.400-preview.0.24324.5 [C:\Program Files\dotnet\sdk]
8.0.401 [C:\Program Files\dotnet\sdk]
.NET runtimes installed:
Microsoft.AspNetCore.App 3.1.32 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 6.0.33 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 7.0.20 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 8.0.5 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 8.0.8 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.NETCore.App 3.1.32 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 6.0.33 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 7.0.20 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 8.0.5 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 8.0.8 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.WindowsDesktop.App 3.1.32 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 6.0.33 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 7.0.20 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 8.0.5 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 8.0.8 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Other architectures found:
x86 [C:\Program Files (x86)\dotnet]
registered at [HKLM\SOFTWARE\dotnet\Setup\InstalledVersions\x86\InstallLocation]
Environment variables:
Not set
global.json file:
Not found
Using Rancher Desktop, but also saw the same issue on other machines running Docker Desktop:
Docker version 24.0.7, build afdd53b
Image: mcr.microsoft.com/dotnet/aspnet:8.0
Output from when service starts until dotnet exits:
Microsoft.Hosting.Lifetime: Information: Content root path: /app
Service started
Loaded '/usr/share/dotnet/shared/Microsoft.NETCore.App/8.0.8/Microsoft.CSharp.dll'. Symbols loaded.
Loaded '/usr/share/dotnet/shared/Microsoft.NETCore.App/8.0.8/System.Xml.XmlSerializer.dll'. Symbols loaded.
Loaded '/src/x64/Debug/net8.0/Microsoft.IO.RecyclableMemoryStream.dll'.
Loaded 'Microsoft.GeneratedCode'.
Loaded 'Microsoft.GeneratedCode'.
The thread '[Thread Destroyed]' (40064) has exited with code 0 (0x0).
The thread '[Thread Destroyed]' (40728) has exited with code 0 (0x0).
Loaded '/usr/share/dotnet/shared/Microsoft.NETCore.App/8.0.8/System.Xml.XmlSerializer.dll'. Symbols loaded.
The program 'dotnet' has exited with code 0 (0x0).
The thread '.NET TP Worker' (325) has exited with code 0 (0x0).
The thread '.NET TP Worker' (339) has exited with code 0 (0x0).
The thread '.NET TP Worker' (345) has exited with code 0 (0x0).
The thread '.NET TP Wait' (338) has exited with code 0 (0x0).
The thread '.NET TP Wait' (350) has exited with code 0 (0x0).
There is nothing in my application's logs indicating any exception. The code always crashes in the same place unless I start removing objects. There is plenty of other code that runs before it crashes and it's always in one spot. Unfortunately it's proprietary code so I can't paste it here. I'm looking for other ways to dig into what might be going wrong.
I have the app set to generate crash dumps on sig term and this is what I get:
clrstack
OS Thread Id: 0x1 (0)
Child SP IP Call Site
00007FFEA2616A30 00007f17f3e36b57 [HelperMethodFrame_1OBJ: 00007ffea2616a30] System.Threading.Monitor.ObjWait(Int32, System.Object)
00007FFEA2616B60 00007F177485728E System.Threading.Monitor.Wait(System.Object, Int32) [/_/src/coreclr/System.Private.CoreLib/src/System/Threading/Monitor.CoreCLR.cs @ 156]
00007FFEA2616B70 00007F1774861F62 System.Threading.ManualResetEventSlim.Wait(Int32, System.Threading.CancellationToken) [/_/src/libraries/System.Private.CoreLib/src/System/Threading/ManualResetEventSlim.cs @ 561]
00007FFEA2616C00 00007F1774877CA1 System.Threading.Tasks.Task.SpinThenBlockingWait(Int32, System.Threading.CancellationToken) [/_/src/libraries/System.Private.CoreLib/src/System/Threading/Tasks/Task.cs @ 3072]
00007FFEA2616C70 00007F1774877A68 System.Threading.Tasks.Task.InternalWaitCore(Int32, System.Threading.CancellationToken) [/_/src/libraries/System.Private.CoreLib/src/System/Threading/Tasks/Task.cs @ 3007]
00007FFEA2616CC0 00007F17748C5A78 System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(System.Threading.Tasks.Task, System.Threading.Tasks.ConfigureAwaitOptions) [/_/src/libraries/System.Private.CoreLib/src/System/Runtime/CompilerServices/TaskAwaiter.cs @ 104]
00007FFEA2616CE0 00007F17749CD018 System.Runtime.CompilerServices.TaskAwaiter`1[[System.Int32, System.Private.CoreLib]].GetResult() [/_/src/libraries/System.Private.CoreLib/src/System/Runtime/CompilerServices/TaskAwaiter.cs @ 335]
00007FFEA2616CF0 00007F1775411957 DistrolessHelper.Program.<Main>(System.String[])
I turned on MS_VS_DOCKER_TOOLS_LOGGING_ENABLED=1 but the logs only contain messages about hot reload writing and reading to the pipe.