WSL2: SIGTRAP (int3) crash when debugging/attaching to .NET 8 Avalonia app using CEF (Xilium.CefGlue)

[RusieckiRoland]

Windows Version

Microsoft Windows [Version 10.0.26200.7840]

WSL Version

2.6.3.0

Are you using WSL 1 or WSL 2?

• WSL 2
• WSL 1

Kernel Version

6.6.87.2-1

Distro Version

Ubuntu-22.04

Other Software

• .NET SDK: 8.0.124 (Host runtime 8.0.24) on Ubuntu 22.04 (WSL2)
• Avalonia UI app (.NET 8) + Xilium.CefGlue (CEF/Chromium) hosting Monaco Editor
• Visual Studio 2022 (Windows) using "Attach to Process" with connection type "Windows Subsystem for Linux (WSL)"
• WSL version: 2.6.3.0
• WSL kernel: 6.6.87.2-1 (6.6.87.2-microsoft-standard-WSL2)
• WSLg version: 1.0.71
• Windows version: 10.0.26200.7840

Repro Steps

Scenario: Attach to running process (Visual Studio -> WSL) or simply f5 (run with debugging)

1. Start the app inside WSL2 without a debugger:

   • cd /mnt/d/Repo/dotNet/PhialeGis.Library/Avalonia/PhialeGis.ComponentSandbox.Avalonia/bin/Debug/net8.0/linux-x64
   • /usr/bin/dotnet PhialeGis.ComponentSandbox.Avalonia.dll

   (The app uses Xilium.CefGlue / CEF to host Monaco Editor.)

2. In Visual Studio on Windows:

   • Debug -> Attach to Process...
   • Connection type: Windows Subsystem for Linux (WSL)
   • Connection target: Ubuntu-22.04
   • Select the main "dotnet" process that runs PhialeGis.ComponentSandbox.Avalonia.dll
     (do NOT select Xilium.CefGlue.BrowserProcess, do NOT select vsdbg)
   • Code type: Managed (.NET Core for Unix)

3. After attaching, the app runs briefly and then crashes / terminates.

Control:
4) If I start the same app with the browser control disabled (no CEF created), attach does not crash:

• PHIALEGIS_CEF_DISABLE=1 /usr/bin/dotnet PhialeGis.ComponentSandbox.Avalonia.dll

Expected Behavior

Running with debugging without terminating process.
Attaching a debugger to a running .NET process in WSL2 should not cause the process to terminate.
At minimum, attaching should not trigger a fatal SIGTRAP/breakpoint trap in the runtime.

Actual Behavior

After attaching, the app terminates with:
Trace/breakpoint trap (core dumped)

WSL kernel log (dmesg) shows SIGTRAP (signal 5) and CaptureCrash. Example:

traps: .NET Timer[...] trap int3 ... in System.Private.CoreLib.dll[...]
dotnet: .NET Timer: potentially unexpected fatal signal 5.
WSL (... - CaptureCrash): Capturing crash for pid: , executable: !usr!lib!dotnet!dotnet, signal: 5, port: 50005

traps: .NET TP Worker[...] trap int3 ... in System.Private.CoreLib.dll[...]
dotnet: .NET TP Worker: potentially unexpected fatal signal 5.

In other runs (debugging from launch) I also observed crashes involving Chromium/CEF threads (CrBrowserMain) and memfd:doublemapper.
This only reproduces when the app creates/uses CEF (Monaco). With CEF disabled (PHIALEGIS_CEF_DISABLE=1) the attach scenario does not crash.

Diagnostic Logs

WSL diagnostics:

• dmesg excerpt (SIGTRAP / int3 / CaptureCrash):
  Run in WSL:
  dmesg | rg -n "trap int3|fatal signal 5|CaptureCrash|CrBrowserMain|System.Private.CoreLib" | tail -n 200

Application logs:

• Startup log (includes debugger attach detection):
  /mnt/d/Repo/dotNet/PhialeGis.Library/Avalonia/PhialeGis.ComponentSandbox.Avalonia/bin/Debug/net8.0/linux-x64/phialegis-avalonia-startup.log
  Relevant lines can be extracted with:
  tail -n 300 phialegis-avalonia-startup.log | rg -n "DbgMon|ProcExit:|UnhandledException|CEF:"

Versions:

• dotnet info:
  dotnet --info
• kernel:
  uname -a

Optional (if needed):

• core dump is produced sometimes ("core dumped"). I can provide the core file if you indicate how to collect it in WSL (coredumpctl is not available by default).

[github-actions]

Logs are required for review from WSL team

If this a feature request, please reply with '/feature'. If this is a question, reply with '/question'.
Otherwise, please attach logs by following the instructions below, your issue will not be reviewed unless they are added. These logs will help us understand what is going on in your machine.

How to collect WSL logs

Download and execute collect-wsl-logs.ps1 in an administrative powershell prompt:

Invoke-WebRequest -UseBasicParsing "https://raw.githubusercontent.com/microsoft/WSL/master/diagnostics/collect-wsl-logs.ps1" -OutFile collect-wsl-logs.ps1
Set-ExecutionPolicy Bypass -Scope Process -Force
.\collect-wsl-logs.ps1

The script will output the path of the log file once done.

If this is a networking issue, please use .\collect-wsl-logs.ps1 -LogProfile networking instead, following the instructions in Collect WSL logs for networking issues

Once completed please upload the output files to this GitHub issue.

See Collect WSL logs (recommended method).

If you choose to email these logs instead of attaching them to the bug, please send them to wsl-gh-logs@microsoft.com with the GitHub issue number in the subject, and include a link to your GitHub issue comment in the message body, and reply with '/emailed-logs'.

[RusieckiRoland]

WslLogs-2026-03-08_18-06-26.zip

[github-actions]

Diagnostic information

Detected appx version: 2.6.3.0
Found evidence of linux crash: !usr!lib!dotnet!dotnet (dump: C:\Users\rolan\AppData\Local\temp\wsl-crashes\wsl-crash-1772989618-80701-_usr_lib_dotnet_dotnet-5.dmp)
Found evidence of linux crash: !usr!lib!dotnet!dotnet (dump: C:\Users\rolan\AppData\Local\temp\wsl-crashes\wsl-crash-1772989788-82609-_usr_lib_dotnet_dotnet-5.dmp)