[CI][Windows] Publisher bootstrap Add-Type fails when environment block exceeds 65535 bytes
Los mantenedores suelen responder en 1 día
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 1-2 días
- Aptitud para principiantes
- 45/100
Línea de trabajo
Start with tools/devops/automation/scripts/test-powershell-core-native.ps1 and inspect the Add-Type invocation at line 24, then review the two linked publisher task logs. Determine how to let the fixture initialize when the inherited environment block exceeds 65,535 bytes; the issue does not identify which variables cause the oversized block. Done means the fixture runs past initialization and reaches its native exit-code assertions in the affected Windows CI publisher.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Apple platform
All Apple targets are affected indirectly: this fails in the Windows CI test-results publisher, before its native-bootstrap fixture can execute. It is not an Apple application runtime failure.
Framework version
net11.0-* (main PR #26930) and net10.0-* (release/10.0.1xx backport #26942). The failing operation is CI PowerShell/C# fixture initialization, not a managed framework test.
Affected platform version
Windows PowerShell Desktop 5.1, established by the exact checked-out script's mandatory edition/version guard before the failing line. Exact Windows OS and PowerShell patch versions are unavailable from these publisher error logs.
The reported maximum process environment block is 65,535 bytes; the two failures report 243,887 and 244,990 bytes. These are the task's reported sizes, not an environment dump or independent variable-size measurement.
Description
Recurring CI infrastructure failure: 2 publisher tasks across 2 distinct monitored PRs.
Test native PowerShell bootstrap failures stops at Add-Type, line 24 of tools/devops/automation/scripts/test-powershell-core-native.ps1. The compiler process cannot start because its environment block exceeds the Windows limit. This occurs before Get-PowerShellVersion and the expected native exit-code 1/0 assertions at line 39, so it is not evidence that native exit propagation failed.
| PR / queued source | Build / exact publisher job | Stage/job/task attempt | Reported bytes | Observed failure boundary |
|---|---|---|---|---|
#26930 / 099816777ca38eac865f67de947e7cfd00192cda |
15747841 / publisher 1, task b5cf0d2e-5215-58e4-92cf-6e3360fda5dd, log 3027 |
1/1/1 | 243,887 | Task Failed 2026-10-20 19:15:09.8433333 UTC; publisher job Failed at 19:15:49.9933333 |
#26942 / 568453c0b63c6f046d15d9cb43f812ff1ebaf191 |
15749908 / publisher 2, task 82f32dde-3ff8-527c-0403-7998fb8eca3b, log 3166 |
2/2/1 | 244,990 | Task Failed 2026-10-20 21:53:07.03 UTC; publisher job/shared parent were still nonterminal in the captured snapshot |
First and latest recorded CI failure instants are the task boundaries above. The publisher-2 stage/job belongs to an already observed external Windows retry wave; its dependent publisher is not another retry request. No monitor rerun or source change was submitted.
Own-job source provenance: both publisher PR-reset steps were skipped. Their own successful checkout logs instead verify provider merge commits 16d1a46584d5d811bcec79f79fcb3f008ad5a0d4 (log 3025, first run) and 2c67ce5916d8aaebcc9ff6374860c920bd169f36 (log 3164, second run). Both contain the exact same fixture blob fa44f4ac936d963c40cfc1481454194072718ae9. The queued PR sources are not substituted for these actual checkouts, and source-reset proof from test/reservation jobs is not borrowed.
The task uses powershell.exe; the exact fixture's Desktop-5.1 guard passes before Add-Type. A separate successful Install PowerShell Core step does not prove these assertions ran under Core, that installation was cold, or that a permanent MSI/PATH/worker fix was validated.
Steps to Reproduce
- Inspect either linked CI publisher job and its own failed native-bootstrap task log.
- Confirm the source checkout and fixture blob above, and the failure at
Add-Typeline 24. - Observe the environment-block limit error before any expected/actual native exit-code assertion result is emitted.
The environmental trigger is an oversized inherited process environment. Which variable or combination produced that size is not established. No environment contents were dumped, no worker was probed, and no shared CI configuration/environment was changed. This is a CI-observation reproduction, not a request to rerun an unresolved pipeline or alter a shared worker.
Did you find any workaround?
No verified workaround or permanent fix. The monitor's all-actor retry-history/grouping counters remain incomplete, so it did not submit an exploratory retry. A successful fixture in another job does not repair or invalidate this publisher-specific failure.
Before filing, complete separate searches across open and closed issues for the stable signature, exact task name, environment-block/65,535 error, and Add-Type/PowerShell component returned no candidates. No existing canonical issue was found.
Relevant log output
Add-Type : The environment block used to start a process cannot be longer than 65535 bytes.
Your environment block is 243887 bytes.
System.InvalidOperationException,Microsoft.PowerShell.Commands.AddTypeCommand
PowerShell exited with code '1'.
The second task reports the same error with 244990 bytes. No native exit-code fixture result was reached in either failure. This is not the separate pwsh.exe-not-found or SSH-network-timeout failure.
Worker identifiers, IP addresses, credentials, environment contents and raw command lines are intentionally omitted. Artifact retention is limited; the linked task logs and exact source commits are the primary evidence. Helix and application NUnit/TRX results are not applicable to this fixture-initialization failure.
[!NOTE]
Generated by GitHub Copilot.
- Lenguaje dominante
- C#
- Estrellas
- 2.9k
- Forks
- 578
- Merge medio
- 2 d 9 h
- PR fusionados (30 d)
- 187
Preparar el entorno
Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de dotnet/macios
-
NSString(string) keeps an extra native reference, so every NSString created from a managed string leaksPosiblemente ocupada @rolfbjarne la tomó hace 4 días. Abiertobackport-to-net10.0 backport-to-net11.0 bug regression
Dificultad 2/5 1-3 horas Aptitud para principiantes 64/100
dotnet/macios#27042 · 1 comentario · 1 reacción ·
Los mantenedores suelen responder en 1 día
-
[Network] Align NWIPVersion enum values with native nw_ip_version_tPosiblemente ocupada @rolfbjarne la tomó hace 4 días. Abiertoapi-bindings copilot
Dificultad 2/5 1-3 horas Aptitud para principiantes 88/100
dotnet/macios#26802 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
[Network] Bind the waiting state for NWBrowserStatePosiblemente ocupada @rolfbjarne la tomó hace 17 días. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 85/100
Los mantenedores suelen responder en 1 día
-
ci-failure ci-postmortem tests
Dificultad 2/5 1-3 horas Aptitud para principiantes 86/100
Los mantenedores suelen responder en 1 día
-
Specifying both RuntimeIdentifier + RuntimeIdentifiers can confuse the build.Posiblemente ocupada @rolfbjarne la tomó hace 9 días. Abiertobug msbuild regression
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
dotnet/macios#25463 · 1 reacción ·
Los mantenedores suelen responder en 1 día
Todos los issues de dotnet/macios
Issues similares
-
bug elsa 3 prio low
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
elsa-workflows/elsa-core#9154 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
NethermindEth/nethermind#15452 ·
Los mantenedores suelen responder en 1 día
-
kind:ux size:S
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
elsa-workflows/elsa-foundation#3563 ·
Los mantenedores suelen responder en 1 día
-
请让 FPS 叠加层的字号大小可单独设置Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
Los mantenedores suelen responder en 1 día
-
امکان انتخاب متن پیام هرزنامهAbierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 66/100
MahdiyarGHD/GheychiApp#39 ·
Los mantenedores suelen responder en 1 día