In-process (.NET, Windows): access violation in copilot_runtime_connection_write when responding to runtime requests

Offen
#2,821 1 Kommentar 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
4/5
Geschätzter Aufwand
3-5 Tage
Anfängerfreundlichkeit
43/100
Issue-Typ
Bug
Klarheit
Größtenteils klar
Aktivitätsstatus
Aktiv
Tech-Stack
csharp, typescript
Bereich
backend, devtools

Rechercherichtung

Start by tracing the .NET in-process response path from FfiRuntimeHost.SendFrame through JsonRpc.SendResultResponseAsync, then inspect the native copilot_runtime_connection_write implementation and its connection lifecycle. Try to reproduce on Windows x64 with parallel MCP tool calls using the reported SDK/runtime versions; done means writes either succeed or report a managed error without crashing the host.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

Summary

With in-process hosting (RuntimeConnection.ForInProcess()) on Windows x64, the host process dies with an access violation (0xC0000005) inside the native copilot_runtime_connection_write while the .NET SDK writes a response frame. It happens mid-turn in long agent sessions and takes down the whole host application.

Versions

  • GitHub.Copilot.SDK 1.0.16 (runtime 1.0.89) and 1.0.17 (runtime 1.0.93); reproduced on both
  • .NET 10, win-x64, self-contained WPF app, in-process hosting
  • Session config: OnPreToolUse hook (synchronous, returns allow), OnPermissionRequest handler (synchronous allow), OnUserInputRequest, OnElicitationRequest, an HTTP MCP server with many tools, AskUserVariant.Elicitation, a custom provider pointed at a loopback HTTP endpoint

Stack (1.0.17)

Fatal error.
0xC0000005
   at GitHub.Copilot.FfiRuntimeHost.<ConnectionWrite>g____PInvoke|55_0(UInt32, Byte*, UIntPtr)
   at GitHub.Copilot.FfiRuntimeHost.SendFrame(System.ReadOnlySpan`1<Byte>)
   at GitHub.Copilot.JsonRpc+<SendMessageAsync>d__35`1[[System.__Canon, ...]].MoveNext()
   at GitHub.Copilot.JsonRpc+<SendResultResponseAsync>d__46.MoveNext()
   at GitHub.Copilot.JsonRpc.SendResultResponseAsync(System.Text.Json.JsonElement, System.Object, System.Type, System.Threading.CancellationToken)
   at GitHub.Copilot.JsonRpc+<HandleIncomingMethodAsync>d__41.MoveNext()
   at GitHub.Copilot.JsonRpc+<ReadLoopAsync>d__37.MoveNext()
   ...
   at GitHub.Copilot.JsonRpc+<ReadMessageAsync>d__39.MoveNext()
   ...
   at GitHub.Copilot.FfiRuntimeHost+CallbackReceiveStream+<ReadAsync>d__4.MoveNext()
   ...
   at GitHub.Copilot.FfiRuntimeHost+CallbackReceiveStream+<ReadCoreAsync>d__5.MoveNext()
   at System.Threading.ThreadPoolWorkQueue.Dispatch()
   at System.Threading.PortableThreadPool+WorkerThread.WorkerThreadStart()

On 1.0.16 the same fault came through JsonRpc.SendMessageAsync from CopilotSession.HandlePendingPermissionRequestAsync.

Pattern

Both crashes happened right after the model issued two MCP tool calls in parallel. The host log shows two preToolUse approvals, then two permission-request approvals, then an MCP HTTP call returning 200, and then the fault while writing a response frame back to the runtime. FfiRuntimeHost.SendFrame already holds _lifecycleLock and checks _disposed and _connectionId, so the managed side does not seem to be writing concurrently or after close. The fault appears to be in the native write path.

Frequency: about 1 crash in 15–20 multi-tool conversations when replaying real user sessions (each 1–4 turns, 10–60 tool calls). Single-turn tests and a 40-turn sequential stress run did not reproduce it, so concurrency between parallel tool calls looks like a factor.

Possibly related: on 1.0.16 we also saw one turn hang forever. The session's events.jsonl had hook.start for preToolUse with no matching hook.end, even though our hook returns synchronously.

Expected

A response write to an open connection either succeeds or fails with a managed error. It should never crash the host process.

Happy to run a build with extra native logging if that helps.

Vorherrschende Sprache
Java
Sterne
10.7k
Forks
1.5k
PR-Merge-Kennzahlen
Keine gemergten PRs in 30 T.

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus github/copilot-sdk

Alle Issues in github/copilot-sdk

Ähnliche Issues

Weitere Issues zu Java

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.