[CI][Windows] Enable long paths fails with registry SecurityException before tests

[dalexsoto]

Failure

The Windows Integration Tests stage fails in Enable long paths, before workload installation or product tests:

LongPathsEnabled : 0
Set-ItemProperty : Requested registry access is not allowed.
System.Security.SecurityException

Classification: CI infrastructure failure. The Windows worker cannot update HKLM\SYSTEM\CurrentControlSet\Control\FileSystem\LongPathsEnabled. This is a setup/permissions failure, not a product-test assertion or a user-project MAX_PATH error.

Confirmed occurrences

2 confirmed occurrences across 2 distinct monitored PRs. Repeated observations and downstream reporting errors are not counted separately.

PR / full head SHA	Run / attempt	Outcome
#26642 / 336dcbb3b669c56dcedb60376d70125ef2943c6f	15346858 / 1	Setup failed; full Windows stage attempt 2 subsequently succeeded.
#26593 / fcf09933855a77843499d8b95eeabd63717a5bfa	15396763 / 1	Same setup failure; no monitor retry submitted.

Pipeline: xamarin-macios-sim-pr-tests (definition 21922). Both failures are stage windows_integration, job Dotnet tests / eac261bd-81a1-5958-df8d-94842fc987be, task Enable long paths / c296d67b-77b3-5268-5af9-207fe49f60b0, stage/job/task attempt 1. Original task logs are 1858 and 1417, respectively.

First confirmed failure: 2026-09-16 14:56:49 UTC. Latest: 2026-09-21 12:21:39 UTC.

Investigation and impact

Both original task logs were inspected and have the same disabled registry value, denied write and PowerShell exit 1. The same-pipeline passing control #26513 / run 15345672 has LongPathsEnabled : 1 before and after this task (log 1417).

In #26593, Install custom .NET, Install workloads and Run tests are skipped. The later Prepare tests results and Html Report error is a consequence: its configured custom dotnet.exe was never installed. No Windows TestSummary was produced. The published HtmlReport is a nested ZIP with no test-result XML/TRX or binlog files; no product test or relevant MSBuild execution occurred. Helix results and test IDs therefore do not exist for this occurrence.

Searches covered all open and closed issues, separately using the exact task, registry value, permission error and component. #18445, #20305 and #18259 concern application/package path-length errors; #22806 and its explicit duplicate target #22591 concern bitcode_strip. None records this CI setup root.

Recovery and current decision

#26642's entire Windows Integration Tests stage, attempt 2, succeeded at 2026-09-16 19:05:03 UTC. This is an observed recovery, not a guarantee that another worker will have the correct permissions.

For #26593, a further retry is blocked by incomplete lifetime retry accounting: historical run 15321041 still has metadata but no retained timeline response, and historical external accepted-request grouping cannot be established safely. The new head does not reset the PR-lifetime counter. No new retry, source change or suppression change was made.

The infrastructure remedy is to ensure the Windows image and agent identity have the required long-path configuration and permissions before test setup. A permitted recovery retry must rerun the whole Windows stage, after merge/head, active-run and both budget gates pass.

No existing issue-specific diagnostic checklist applied when this issue was created. Exact PR/head/run/attempt/job/task, registry state, errors and retry outcome are retained; absent test results are explicitly explained above. Worker identifiers and IP addresses are not disclosed. Azure logs and artifacts are retention-limited.

Stable signature: CI-infrastructure|WindowsIntegration|Enable-long-paths|LongPathsEnabled-0|HKLM-SetItemProperty-SecurityException-permission-denied

[dalexsoto]

Verified full-stage recovery and merge: PR #26593

PR #26593, unchanged head fcf09933855a77843499d8b95eeabd63717a5bfa, recovered in run 15396763, Windows Integration Tests attempt 2. Pipeline definition: 21922; stage/job attempt 2, setup-task record attempt 1.

Enable long paths succeeded at 2026-09-21 18:43:12 UTC (task d33a9217-e040-57a3-23ad-ec3a4bd998d1, log 3085). Its original task output reports LongPathsEnabled : 1 both before and after the update, with no registry-access denial.

The whole Windows stage reran: reservation, test job, and re-enable jobs all completed successfully. Actual product-test execution was verified from current-attempt original TRX files, not inferred from the brief Run tests placeholder:

Original result file	Passed	Not executed
windows-local-dotnet-tests.trx	69	0
windows-remote-dotnet-tests.trx	34	0
windows/bgen-tests/results.trx	408	1

That is 511 passed, zero failed, one not executed. TRX timestamps match the Run .NET tests locally, Run .NET tests remotely, and Run generator tests tasks (logs 3094, 3095, 3097).

The test job succeeded at 19:23:04 UTC, the full stage at 19:25:50 UTC, and the pipeline at 19:29:55 UTC. GitHub confirms the PR merged at 19:30:12 UTC as e4aba139d0cb700f6899d8105a9a22effc78105a, with 56 successful checks / 1 skipped.

Counts remain 2 confirmed failures across 2 distinct monitored PRs. This was an external retry; this monitor performed neither retry nor merge. Success does not reset either retry budget or resolve the previously recorded lifetime-accounting gap.

Diagnostics/checklist: the refreshed issue body has no Additional info to collect section. Exact head/run/attempt/job/task identities, registry values, full-stage outcomes, original TRX counts/times, and merge metadata were collected. Original attempt-1 test results remain unavailable because setup failed before tests ran; retry results do not retroactively supply them. Worker identifiers and IP addresses are withheld.

Evidence: TestSummary-windows_integrationwindows-2 and HtmlReport-windows_integrationwindows-2 in run artifacts, subject to retention. No source, warning suppression, or test-ignore changes were made.

[dalexsoto]

Confirmed Windows setup recurrence: PR #26669

• PR/head: [main] Update dependencies from dotnet/macios #26669 / 5f6fafc37b48f2ccf45cc3a0f234500ba668bebc.
• Pipeline/run: xamarin-macios-sim-pr-tests (21922), 15410988.
• Job/task: Windows Integration Tests / Dotnet tests / Enable long paths, stage/job/task attempt 1, task log 1450.
• Failure time: 2026-09-22 06:56:19 UTC; job completed failed at 06:57:06 UTC.

The original setup log independently confirms the exact signature:

LongPathsEnabled : 0
Set-ItemProperty : Requested registry access is not allowed.
System.Security.SecurityException
PowerShell exited with code '1'.

Custom .NET installation, workload installation, local/remote .NET tests and generator tests were skipped. The later Prepare tests results and Html Report failure (task 1e0c8bcc-c745-5642-21ec-e07c8a709e51, log 1466) is a cascade: its configured custom dotnet.exe was never installed. It is not counted as another root occurrence.

Classification/counts: CI infrastructure setup/registry-permission failure. The total is now 3 confirmed occurrences across 3 distinct monitored PRs, adding #26669 once to #26642 and #26593.

Retry decision: no retry submitted while this pipeline remains active. Any later permitted retry must rerun the entire Windows Integration Tests stage, after fresh head/merge, complete all-actor budget accounting, atomic reservation and equivalent-run checks. The prior successful recoveries on other PRs remain historical evidence, not a recovery claim for this occurrence.

Diagnostics/checklist: the refreshed issue body has no Additional info to collect section. Exact head/run/attempt/job/task, initial registry value, permission error, skipped task sequence and downstream cascade were collected. No Windows TestSummary was published; the inspected HtmlReport-windows_integrationwindows-1 contains no test-result XML/TRX, binlog or dump. Product test IDs/results and Helix work-item data are therefore unavailable/not applicable. A successful post-write registry value is unavailable because the write failed. Worker identifiers and IP addresses remain withheld.

The infrastructure remedy remains correct long-path configuration and registry permissions before test setup. No source, suppression or branch changes were made. Azure logs/artifacts are retention-limited.

[dalexsoto]

Confirmed fourth Windows long-paths setup recurrence

PR #26643, head 36127eabacd47e080ac49d32ab09f7767b3a8248: Azure run 15431841 attempt 1 / Windows Integration Tests / Dotnet tests / Enable long paths, pipeline 21922; stage/job/task attempt 1, task log 1417. At 2026-09-23 15:35:42 UTC, the task read LongPathsEnabled : 0, then Set-ItemProperty on the long-path registry key failed with PermissionDenied / System.Security.SecurityException (“Requested registry access is not allowed”), exit 1.

Root/classification: the exact existing Windows CI infrastructure/permission failure, not a product-test or MAX_PATH assertion. Custom .NET installation, workload installation and Run tests were skipped; a later HtmlReport preparation task also failed after setup, without evidence of a second root. Totals: 4 confirmed failure occurrences across 4 distinct monitored PRs.

Retry observation: an externally initiated whole Windows Integration Tests stage attempt 2 is running on the unchanged head. Its reservation job has succeeded, but the test and full-stage outcomes are not yet established. This monitor requested no retry and made no change to the Rolf PR. The actor, accepted-request grouping with a concurrent simulator attempt, and exact all-actor lifetime/current-head counts remain uncertified; no additional retry is authorized.

Issue-specific checklist: the refreshed issue body has no Additional info to collect section. The post-write registry value is unavailable because the write failed. Original Windows product-test IDs/results, TestSummary and Helix work items do not exist because setup stopped before tests. Worker identifiers/IPs are withheld. Remedy remains an appropriately configured Windows image/permissions; artifact retention applies.

[dalexsoto]

Windows Integration retry passed on #26643

#26643, unchanged head 36127eabacd47e080ac49d32ab09f7767b3a8248: Azure run 15431841 / Dotnet tests job. The externally initiated Windows Integration Tests stage attempt 2 succeeded at 2026-09-24 08:34:47 UTC. Its Dotnet tests job attempt 2 succeeded at 08:32:20 UTC; Enable long paths succeeded with LongPathsEnabled=1 (task log 3148), local and remote .NET test tasks succeeded, and TestSummary-windows_integrationwindows-2 reports all 3 tests passed.

The original attempt-1 LongPathsEnabled=0 / Set-ItemProperty SecurityException before tests remains a confirmed CI infrastructure failure. Its stable signature is CI-infrastructure|WindowsIntegration|Enable-long-paths|LongPathsEnabled-0|HKLM-SetItemProperty-SecurityException-permission-denied. Stage-attempt-2 success shows that setup failure did not recur on this retry, not that the infrastructure problem is permanently fixed. Failure totals remain 4 confirmed occurrences across 4 distinct PRs; this passing attempt is not a fifth failure.

The parent pipeline and #26643's separately rerunning iOS simulator job are still in progress; no full-PR recovery is claimed. The retry was external, not requested by this monitor; its initiating actor, accepted-request grouping with the simulator retry, and exact all-head retry counters remain unverified. The issue body has no Additional info to collect checklist. No Helix work item applies to the original Windows setup task. Azure artifacts are retention-limited.

AI-assisted CI monitoring update.

[dalexsoto]

Fifth distinct PR: Windows long-path registry setup failure

#26687, head 6df0ea155215603133a01b583c94440eeb32ca07, Azure run 15431340 / Windows Integration attempt 1 / Dotnet tests job eac261bd-81a1-5958-df8d-94842fc987be: Enable long paths task c296d67b-77b3-5268-5af9-207fe49f60b0, log 1462, read LongPathsEnabled=0 and failed at 2026-09-23 14:40 UTC with Set-ItemProperty PermissionDenied / System.Security.SecurityException writing the HKLM filesystem key. Product tests did not run on that attempt. This matches the CI infrastructure failure signature CI-infrastructure|WindowsIntegration|Enable-long-paths|LongPathsEnabled-0|HKLM-SetItemProperty-SecurityException-permission-denied, not a source change in the PR.

An externally initiated entire Windows Integration stage attempt 2 succeeded at 18:49:53 UTC. Its long-path setup and local/remote .NET tests succeeded, and TestSummary-windows_integrationwindows-2 reports all 3 tests passed. This is an observed retry recovery for the setup stage, not proof that agent permissions are permanently fixed. The parent pipeline ultimately succeeded after separate iOS simulator retries for unrelated failures, which are tracked under their own signatures.

Totals: 5 confirmed registry-setup failures across 5 distinct monitored PRs. This adds one PR and one failed attempt; the successful stage attempt is not a sixth failure. The accepted retry actor, request scope/grouping with other stages, and exact all-head lifetime/head counters remain uncertified; this monitor requested no retry or source edit. The issue body has no Additional info to collect section. No Helix work item applies to a registry setup failure before tests; Azure artifacts are retention-limited.

AI-assisted CI monitoring update.

[dalexsoto]

Sixth distinct PR: Windows long-path registry setup failed on #26683

#26683, new head e61ea7a19b187b24b2cf443c3a644207df8b8239, Azure simulator run 15445529 / Windows Integration Tests / Dotnet tests job eac261bd-81a1-5958-df8d-94842fc987be: the first failed task, Enable long paths (c296d67b-77b3-5268-5af9-207fe49f60b0, log 1428), read LongPathsEnabled=0 and failed at 2026-09-24 11:29:03 UTC with Set-ItemProperty PermissionDenied / System.Security.SecurityException on the HKLM filesystem key. No workload or product test ran in this job; the later HtmlReport preparation failure was a cascade. The Windows stage ended failed at 11:32:26 UTC while other simulator jobs continued.

This is the same CI infrastructure failure signature CI-infrastructure|WindowsIntegration|Enable-long-paths|LongPathsEnabled-0|HKLM-SetItemProperty-SecurityException-permission-denied, on a sixth distinct monitored PR. It differs from #26683's old-head Windows workload-feed failure and does not implicate its new-head source changes or recently merged ImageIO/SdkVersions fixes.

Totals: 6 confirmed occurrences across 6 distinct monitored PRs. This is the initial automatic build on the new head, not a monitor-requested retry. GitHub currently reports #26683 CONFLICTING / DIRTY, so the monitor will not retry or resolve its conflicts. Exact all-actor lifetime/current-head retry totals are not certified. The issue body has no Additional info to collect section. No NUnit result or Helix work item exists for a setup failure before tests; Azure logs are retention-limited.

AI-assisted CI monitoring update.