Skip to content

Add Windows ARM64 diagnostics test runs - #6075

Merged
max-charlamb merged 7 commits into
mainfrom
dev/max-charlamb/windows-arm64-tests
Oct 1, 2026
Merged

max-charlamb merged 7 commits into
mainfrom
dev/max-charlamb/windows-arm64-tests

Conversation

@max-charlamb

Copy link
Copy Markdown
Member

Summary

  • enable the Windows ARM64 build in public and internal pipelines
  • run diagnostics Helix coverage on Windows 11 ARM64 queues
  • include the managed-only test payloads and SOS ARM64 coverage

Validation

  • evaluated Helix project discovery for win-arm64
  • built representative ARM64 test projects and verified ARM64 apphosts
  • staged representative managed and DebugServices ARM64 Helix payloads

Enable public and internal win-arm64 builds and Helix execution, including the managed-only test projects and SOS coverage on Windows 11 ARM64 queues.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
@max-charlamb
max-charlamb requested a review from a team as a code owner September 29, 2026 15:30
Max Charlamb and others added 4 commits September 29, 2026 12:56
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Report the underlying DAC activation failure so remaining ARM64 CDB failures identify whether loading or CLRDataCreateInstance failed.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Max Charlamb and others added 2 commits September 30, 2026 14:11
Initialize SOS managed services in the existing CoreCLR after loading the native extension. Cover live and dump hosting and preserve error/warning output for diagnostics.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Restore native DAC logging and DbgEng output capture to their original behavior. Keep the shared-CoreCLR fix and verify the host cannot be changed after initialization using normal output.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
@max-charlamb

Copy link
Copy Markdown
Member Author

/ba-g unrelated test failures

@max-charlamb
max-charlamb merged commit b5158da into main Oct 1, 2026
22 of 24 checks passed
@max-charlamb
max-charlamb deleted the dev/max-charlamb/windows-arm64-tests branch October 1, 2026 16:10
max-charlamb added a commit that referenced this pull request Oct 1, 2026
## Problem

`HostServices.Uninitialize` releases the native debugger-services COM
reference twice:

1. `DebuggerServices` is registered in the global service container as
`SOSHost.INativeDebugger`. Although that interface does not inherit
`IDisposable`, the concrete object inherits `CallableCOMWrapper`, which
does.
2. `ServiceContainer.DisposeServices()` checks the concrete instances
for `IDisposable` and calls `DebuggerServices.Dispose()`, releasing the
wrapper's owned COM reference.
3. `Uninitialize` then calls `DebuggerServices.ReleaseWithCheck()`,
which invokes a raw COM `Release()` again rather than respecting the
wrapper's disposed state.

This is a double COM release, not necessarily an immediate double free
in every run. With other references outstanding, it incorrectly consumes
another owner's reference; if the first release destroys the native
object, the second release can call through freed memory.

## Provenance

The explicit release predates service-container ownership and was
originally appropriate. #3448 introduced global service disposal while
leaving `DebuggerServices` outside the container. #4285 subsequently
registered the same wrapper as `SOSHost.INativeClient` so `SOSHost`
could use the existing native debugger client, but retained the manual
release. #4437 later renamed that interface to `INativeDebugger`.

`CallableCOMWrapper` already implemented `IDisposable` when the
registration was added, so this is an ownership mismatch rather than a
recent ClrMD disposal-contract change.

## Fix

- Remove the redundant explicit release; the service container disposes
`DebuggerServices` exactly once.
- Detach `DiagnosticLoggingService` from its debugger-backed console
before disposing global services. Its singleton retains a
`ConsoleServiceFromDebuggerServices` that forwards trace output to the
native debugger interface; leaving that connection active during
disposal could issue output through a released pointer.
- Preserve target destruction and the shutdown event before global
service disposal.

This was found while investigating Windows ARM64 SOS tests in #6075, but
the ownership bug is architecture-independent. This PR does not
establish that it caused the separate `Output` versus `Output2` callback
behavior.

## Validation

Targeted restore and build of
`src\SOS\SOS.Extensions\SOS.Extensions.csproj` succeeded for `net8.0`
and `net462` with zero warnings and errors. No native teardown
reproduction or ARM64 runtime validation has been performed for this
fix.

Co-authored-by: Max Charlamb <maxcharlamb@microsoft.com>
Copilot-Session: 13f45840-6112-4dc4-ab2f-c020bd189022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants