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

オープン
  • 何か問題がありますか？
#9,838 コメント 4 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
55/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
活発
技術スタック
csharp, typescript, vscode
領域
developer-experience, devtools

調査の方向性

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.

索引モデルが issue の本文から書いたものです。

説明

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).

主要言語
TypeScript
スター
3.1k
フォーク
742
平均マージ
1日 3時間
マージ済み PR（30日）
53

環境構築

Codespaces で開く

このプロジェクトの開発コンテナを、あなたの GitHub アカウントでブラウザ上に起動します。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

dotnet/vscode-csharp のほかの issue

dotnet/vscode-csharp の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。