Isolate SOS hosting from other debugger extensions that use managed code

Aperta
  • Qualcosa non va?
#6,207 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@hoyosjs ci sta già lavorando.

Dal 10/11/2026.

  • #6209 di @hoyosjs — aperta

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
25/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
cpp, csharp
Ambito
devtools

Direzione di ricerca

Start by tracing native SOS initialization and managed hosting in the SOS code, then inspect how debugger interfaces and callbacks are registered. The issue identifies dependency isolation, existing CoreCLR handling, Windows AppDomain boundaries, and initialization rollback as connected design constraints. Done means SOS can initialize alongside another managed debugger extension without dependency conflicts or unusable partial state.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

bug
Description

SOS should work when another WinDbg or LLDB extension that uses managed code has already started a runtime or loaded different dependency versions. This concerns independently loaded debugger extensions, not optional SOS extensions.

Current issues on main:

  • CoreCLR dependency conflicts: SOS infrastructure loads into Default, sharing assembly bindings with other managed debugger extensions. Incompatible dependencies loaded first can prevent initialization or break commands. ExtensionLoadContext isolates optional SOS extensions, not SOS infrastructure.
  • Existing-runtime handling: SOS selects a runtime and calls coreclr_initialize without explicitly handling an already-active CoreCLR. Its TPA/probing setup cannot be assumed to replace the existing host's configuration or make SOS assemblies discoverable there.
  • Framework/AppDomain isolation: SOS runs in the default AppDomain. Its failed-bind resolver cannot override incompatible bindings that already succeeded. A dedicated AppDomain could isolate dependencies, but managed objects cannot simply be shared across domains without marshaling/remoting. A native COM-compatible boundary can avoid remoting, provided the domain remains alive while the debugger retains interface pointers or callbacks. Unloading it would invalidate those pointers. AppDomain isolation also cannot replace the underlying CLR version.
  • Incomplete initialization recovery: Initialization publishes native pointers, the initialized flag, and managed singleton state before registration succeeds, without complete rollback. Failures can leave partial state and block reconfiguration. Windows may also fall back to Framework after CoreCLR initialization fails.
Configuration

Native SOS hosting in WinDbg or LLDB. The Framework/AppDomain path applies to supported Windows configurations.

Regression?

Not established.

Other information

N/A

Lingua principale
C++
Stelle
1.3k
Fork
407
Merge medio
21h 5m
PR unite (30g)
78

Preparare l'ambiente

Apri in Codespaces

Avvia il container di sviluppo del progetto nel browser, con il tuo account GitHub.

  • Nessun Dockerfile né file Docker Compose
  • Nessun modello di pull request
  • Nessuna guida per i contributori

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di dotnet/diagnostics

Tutte le issue di dotnet/diagnostics

Issue simili

Altre issue su C++

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.