Attaching to a process that has the .NET debugger disabled fails with "Unknown Error: 0x80131c08" and does not name the cause

Đang mở
  • Có gì không ổn?
#9,838 4 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
55/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
csharp, typescript, vscode
Lĩnh vực
developer-experience, devtools

Hướng nghiên cứu

Start at the coreclr attach path and reproduce the failure with DOTNET_EnableDiagnostics_Debugger=0, using the documented attach configuration and the reported CORDBG_E_TIMEOUT result. Trace how the attach failure is surfaced and, on Linux or macOS, how the debugger transport is detected. Done means the error identifies disabled debugger connections and the likely EnableDiagnostics or temporary-directory causes instead of reporting an unknown error.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

Blocked on .NET Core Debugger
Summary

If the target process was started with DOTNET_EnableDiagnostics_Debugger=0 (or DOTNET_EnableDiagnostics=0), attaching from VS Code fails with:

Unable to start debugging. Failed to attach to process: Unknown Error: 0x80131c08

0x80131c08 is CORDBG_E_TIMEOUT ("A wait timed out, likely an indication of deadlock"). The message does not say that the target has its debugger switched off, and "deadlock" points the reader elsewhere. The switch is a documented hardening setting. A developer who meets this error on a process configured by someone else has no route from the message to the cause.

Environment
  • VS Code 1.140.0, C# extension 2.160.4 (vsdbg as bundled with that extension), Linux x64 (Ubuntu 26.04.1)
  • Target runtimes: official .NET 10.0.12 and 8.0.31, linux-x64
Steps to reproduce

  1. Create an app that stays alive long enough to attach to:

    Console.WriteLine($"pid {Environment.ProcessId}");
Thread.Sleep(TimeSpan.FromMinutes(2));

  2. Start it with the runtime's debugger disabled:

    DOTNET_EnableDiagnostics_Debugger=0 dotnet run

  3. In VS Code, start a coreclr attach configuration ("request": "attach", "processId": "${command:pickProcess}") and pick the process.

Expected behavior

A message that names the likely cause. For example: "The target process is not accepting debugger connections. It may have been started with DOTNET_EnableDiagnostics=0 or DOTNET_EnableDiagnostics_Debugger=0, or it may use a different temporary directory from the debugger (TMPDIR, systemd PrivateTmp)." Failing that, at least the symbolic name CORDBG_E_TIMEOUT.

Actual behavior

Unable to start debugging. Failed to attach to process: Unknown Error: 0x80131c08. The target keeps running, unaffected.

What I measured

  • vsdbg (this extension): the message above, about 10 s after F5, attaching to a plain console app with no other tooling loaded, started with DOTNET_EnableDiagnostics_Debugger=0 on .NET 10.0.12. The same app started without the switch attached normally. The same message also appeared on .NET 8.0.31, in a setup where a profiling tool was also loaded in the target.

  • The runtime side. A checked runtime build logs Debugging disabled via EnableDiagnostics_Debugger config. once at start-up, and the debugger transport is never created. On Linux the transport's FIFOs are missing from $TMPDIR while the diagnostics IPC socket is still there:

    no switch:  clr-debug-pipe-<pid>-<key>-in, clr-debug-pipe-<pid>-<key>-out, dotnet-diagnostic-<pid>-<key>-socket
switch set: dotnet-diagnostic-<pid>-<key>-socket only

  • Another debugger, for comparison. netcoredbg 3.2.0, attaching to the same kind of app with no other tooling loaded, fails configurationDone with 0x80131c08 after 10.0 s (3/3). The control without the switch attaches in under 0.1 s (3/3). So the HRESULT comes from the runtime's debugging services, not from vsdbg.

Suggestion
  1. Decode the HRESULT to its symbolic name rather than "Unknown Error".
  2. On Linux and macOS, when an attach to a .NET process times out, check whether the target's debugger transport exists (clr-debug-pipe-<pid>-* in the temp directory). If it is missing while the process is clearly a .NET process (its dotnet-diagnostic-<pid>-* socket exists, or libcoreclr is mapped), say that the target is not accepting debugger connections and name the two likely causes: the EnableDiagnostics switches, and a temp-directory mismatch (#3277).
  3. Optionally, make that check before the attach and fail fast rather than after the timeout.

Related: #3277 (same error, temp-directory cause; a better error was suggested there) and #6883 (the same switch on the launch route, which failed silently).

Ngôn ngữ chính
TypeScript
Star
3.1k
Fork
742
Merge trung bình
1 ngày 3 giờ
Pull request đã merge (30 ngày)
53

Chuẩn bị môi trường

Mở trong Codespaces

Khởi chạy dev container của dự án ngay trên trình duyệt, bằng tài khoản GitHub của bạn.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của dotnet/vscode-csharp

Tất cả issue của dotnet/vscode-csharp

Issue tương tự

Thêm issue về TypeScript

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.