Isolate SOS hosting from other debugger extensions that use managed code

Abierto
  • ¿Algo no está bien?
#6,207 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

@hoyosjs ya está trabajando en esto.

Desde el 10/11/2026.

  • #6209 de @hoyosjs — abierto

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
25/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
cpp, csharp
Área
devtools

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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

Lenguaje dominante
C++
Estrellas
1.3k
Forks
407
Merge medio
21 h 5 min
PR fusionados (30 d)
78

Preparar el entorno

Abrir en Codespaces

Inicia el contenedor de desarrollo del proyecto en tu navegador, con tu propia cuenta de GitHub.

  • Sin Dockerfile ni archivo de Docker Compose
  • Sin plantilla de pull request
  • Sin guía de contribución

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de dotnet/diagnostics

Todos los issues de dotnet/diagnostics

Issues similares

Más issues de C++

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.