Isolate SOS hosting from other debugger extensions that use managed code

Đang mở
  • Có gì không ổn?
#6,207 0 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

@hoyosjs đang làm issue này rồi.

Từ ngày 10/11/2026.

  • #6209 của @hoyosjs — đang mở

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
25/100
Loại issue
Tính năng
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
cpp, csharp
Lĩnh vực
devtools

Hướng nghiên cứu

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.

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

Mô tả

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

Ngôn ngữ chính
C++
Star
1.3k
Fork
407
Merge trung bình
21 giờ 5 phút
Pull request đã merge (30 ngày)
78

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.

  • Không có Dockerfile hay tệp Docker Compose
  • Không có mẫu pull request
  • Không có hướng dẫn đóng góp

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/diagnostics

Tất cả issue của dotnet/diagnostics

Issue tương tự

Thêm issue về C++

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.