crossgen2 AccessViolation in ProfileDataManager.GetAllowSynthesis during win-x86 SDK crossgen layout

[steveisok]

Summary

crossgen2 crashes with an AccessViolationException while processing PGO instrumentation data during the SDK crossgen (ReadyToRun) layout step on win-x86. The crash occurs in ILCompiler.ProfileDataManager.GetAllowSynthesis and appears to be a threading/memory corruption issue in the PGO data path.

Crash Stack

Process terminated. Access Violation: Attempted to read or write protected memory.
   at ILCompiler.ProfileDataManager.GetAllowSynthesis(Compilation, MethodDesc, Boolean&) + 0x31
   at Internal.JitInterface.CorInfoImpl.getPgoInstrumentationResults(...) + 0xab
   at Internal.JitInterface.CorInfoImpl._getPgoInstrumentationResults(...) + 0x60
   at Internal.JitInterface.CorInfoImpl.JitCompileMethod(...) + 0xc5
   at Internal.JitInterface.CorInfoImpl.CompileMethodInternal(IMethodNode, MethodIL) + 0xc4
   at Internal.JitInterface.CorInfoImpl.CompileMethod(MethodWithGCInfo, Logger) + 0x3f2
   at ILCompiler.ReadyToRunCodegenCompilation.<>c__DisplayClass50_0.<ComputeDependencyNodeDependencies>g__CompileOneMethod|5(...) + 0x37e
   at ILCompiler.ReadyToRunCodegenCompilation.<>c__DisplayClass50_0.<ComputeDependencyNodeDependencies>g__CompileOnThread|4(Int32) + 0x37
   at ILCompiler.ReadyToRunCodegenCompilation.<>c__DisplayClass50_0.<ComputeDependencyNodeDependencies>g__CompilationThread|3(Object) + 0x43
   at System.Threading.Thread.StartThread(IntPtr)
   at System.Threading.Thread.ThreadEntryPoint(IntPtr)

Build

• Pipeline: dotnet-unified-build (public, def 278)
• Leg: Windows_x86 (TargetRid=win-x86)
• Phase: SDK crossgen layout (Crossgen.targets:171)
• PR: dotnet/dotnet#5533 — unrelated change (source asset signing backport)

Analysis

• The crash is in crossgen2's PGO data processing path during multi-threaded R2R compilation.
• CompileOnThread → CompileOneMethod → getPgoInstrumentationResults → GetAllowSynthesis suggests multiple compilation threads reading ProfileDataManager state.
• The AV at GetAllowSynthesis+0x31 likely dereferences a null or corrupt pointer in PGO schema data.
• x86-only — this targets win-x86 (32-bit). Could be pointer truncation, address space pressure, or an x86-specific codegen bug.
• Non-deterministic — single occurrence in this window but possibly related to a parallel IBCMerge PGO crash on internal builds (dotnet/dotnet#4138), also x86-only.

Possibly Related

dotnet/dotnet#4138 — IBCMerge BadImageFormatException processing PGO profile data on Windows_Pgo_x86. Different tool (IBCMerge vs crossgen2) but same class of problem: PGO data corruption/crash isolated to x86 platforms.

[dotnet-policy-service]

Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch
See info in area-owners.md if you want to be subscribed.

[steveisok]

Related: IBCMerge PGO crash on release/10.0.2xx (dotnet/dotnet#4138)

A related PGO data processing crash is also hitting internal builds on x86 — this time via IBCMerge rather than crossgen2:

• Build: 2928805 (internal, release/10.0.2xx)
• Leg: Windows_Pgo_x86
• Tool: IBCMerge (Arcade SDK OptimizationData.targets)
• Crash: BadImageFormatException: Read out of bounds in MDReader.GetSigType while processing IBC profile data for Microsoft.CodeAnalysis.VisualBasic.Features.vbproj
• Tracked in: dotnet/dotnet#4138

This is the same class of problem — PGO/optimization data corruption isolated to x86 platforms — but exercised through a different tool (IBCMerge reads .ibc files during official builds; crossgen2 reads PGO instrumentation data during R2R compilation). Both crash on malformed profile data on win-x86.

Notably, #4138 was previously confined to main builds but has now spread to release/10.0.2xx, breaking that branch's prior 100% clean rate.

[JulieLeeMSFT]

CC @AndyAyersMS .

[AndyAyersMS]

Unlikely this is a codegen issue per se, but I'll investigate.

[AndyAyersMS]

Builds have already been purged, so may need to wait until this repros again.

[AndyAyersMS]

Will re-open if this happens again.

[jtschuster]

Looks like this happened a couple more times recently:

Build	Date	Leg	Branch	Error
2979463	2026-05-20	Windows_x86	internal/release/10.0.109	NullReferenceException
3001312	2026-06-16	Windows_x64	release/10.0.4xx	AccessViolation → FailFast

Both crash at the same site and offset as the original:

at ILCompiler.ProfileDataManager.GetAllowSynthesis(Compilation, MethodDesc, Boolean&) + 0x31
at Internal.JitInterface.CorInfoImpl.getPgoInstrumentationResults(...) + 0xab
at Internal.JitInterface.CorInfoImpl._getPgoInstrumentationResults(...) + 0x60

Nore 3001312 is Windows_x64, so this isn't x86-specific.

Copilot thinks is an issue with an inlined _inputProfileData[method] read due to heap corruption from the parallelism in crossgen2.

Note

Drafted with AI (GitHub Copilot) assistance.

[AndyAyersMS]

Yeah corruption of some sort is the likely suspect.

A crash dump sure would help. We could selectively arm via the registry if the build processes have admin privileges. Seems like they might.