Hot Reload: "BadImageFormatException: Bad IL range" on interpreter-only CoreCLR (iOS/Mac Catalyst) after EnC delta, regression from #130159 #132804

Description

Since the .NET 11 runtime picked up dotnet/runtime#130159 ("Use CodeVersioning for EnC"), Hot Reload crashes on the CoreCLR configurations that have no JIT (iOS and Mac Catalyst, i.e. the interpreter-only Apple mobile builds). Immediately after a delta is applied, the first call into an updated method throws:

dotnet watch ⌚ File updated: /tmp/hrtest/AdditionalFile.cs
Unhandled exception. System.BadImageFormatException: Bad IL range.
   at HotReloadTestApp.Program.DoSomething(Int32 i)
   at HotReloadTestApp.Program.RunTestLogic()
   at HotReloadTestApp.Program.Main(String[] args)
dotnet watch ❌ [HotReloadTestApp (net11.0-maccatalyst)] Exited with error code 134

ApplyUpdate itself succeeds — dotnet watch --verbose reports Applying updates to module ..., Invoking metadata update handlers, Updates applied. with no error. The crash happens later, when the updated method is next invoked and its code is prepared.

This is 100% deterministic, both in CI and locally. It has been failing every dependency-flow PR in dotnet/macios for several days; we are tracking the CI side in dotnet/macios#26470 and have had to disable the affected test cases.

Analysis

Bad IL range (BFA_BAD_IL_RANGE) is only thrown from PEAssembly::GetIL (src/coreclr/vm/peassembly.cpp), reached via Module::GetIL(GetRVA()). So the runtime looked up the updated method's IL in the baseline PE image, using the RVA from the metadata delta. After a delta is applied, that MethodDef RVA is delta-relative (a small offset into the delta IL stream), so interpreting it against the baseline image is out of range — hence the error. In other words, the delta IL was never picked up when preparing the updated method.

That lines up exactly with what #130159 changed. EditAndContinueModule::ApplyEditAndContinue now stores the delta IL as an ILCodeVersion (src/coreclr/vm/encee.cpp):

ILCodeVersion ilCodeVersion;
CodeVersionManager *pCodeVersionManager = GetCodeVersionManager();
{
    CodeVersionManager::LockHolder codeVersioningLockHolder;
    if (FAILED(hr = pCodeVersionManager->AddILCodeVersion(this, token, &ilCodeVersion, FALSE, CodeVersionSource::kEnC, m_applyChangesCount)))
        ...
    ilCodeVersion.SetIL((COR_ILMETHOD*)&pLocalILMemory[dwMethodRVA]);
    ilCodeVersion.SetRejitState(RejitFlags::kStateActive);
}

and that IL is reachable only through the versioned config (src/coreclr/vm/prestub.cpp):

COR_ILMETHOD* VersionedPrepareCodeConfig::GetILHeader()
{
    STANDARD_VM_CONTRACT;
    return m_ilCodeVersion.GetIL();
}

whereas the default config falls back to the baseline RVA lookup that throws:

COR_ILMETHOD* PrepareCodeConfig::GetILHeader()
{
    STANDARD_VM_CONTRACT;
    return m_pMethodDesc->GetILHeader();
}

Both go through the same GetAndVerifyMetadataILHeader → pConfig->GetILHeader() call, so the symptom means the updated method is being prepared with a non-versioned PrepareCodeConfig.

Why only the no-JIT configurations?

I want to explicitly rule out the obvious guess, because it's wrong: it is not that code versioning is unavailable on these targets.

• MethodDesc::IsVersionable() is IsEligibleForTieredCompilation() || IsEligibleForReJIT() || IsEligibleForEnC(), and IsEligibleForEnC() only requires InEnCEnabledModule() && IsIL() && !IsWrapperStub() — no dependency on tiering (src/coreclr/vm/method.hpp).
• FEATURE_CODE_VERSIONING is enabled by FEATURE_TIERED_COMPILATION OR FEATURE_REJIT OR FEATURE_METADATA_UPDATER, and FEATURE_METADATA_UPDATER is on for arm64 — so code versioning is compiled in on these targets (src/coreclr/clrdefinitions.cmake).

The actual difference is that FEATURE_DYNAMIC_CODE_COMPILED is off for Apple mobile (src/coreclr/clrfeatures.cmake), which is also what turns FEATURE_TIERED_COMPILATION, FEATURE_REJIT and FEATURE_PGO off there:

if (FEATURE_DYNAMIC_CODE_COMPILED)
  set(FEATURE_TIERED_COMPILATION 1)
  set(FEATURE_REJIT 1)
  set(FEATURE_PGO 1)
endif()

So there is no JIT and these apps run the CoreCLR interpreter. My conclusion is that some interpreter-side code-preparation path doesn't consult the active ILCodeVersion and ends up with a default PrepareCodeConfig. I haven't tracked it down to the exact call site — that's where I'd appreciate help from someone who knows the interpreter entry points (MethodDesc::GetInterpreterCode / InterpreterPrecode / the InvokeManagedMethod path in prestub.cpp).

Corroborating evidence that the JIT path is fine: I built an equivalent plain console app with the same SDK and the same partial-method edit pattern and ran it on desktop osx-arm64 — Hot Reload works correctly there. Only the interpreter-only Apple targets fail.

Repro

Reproduces reliably in the dotnet/macios test suite:

git clone https://github.com/dotnet/macios
cd macios && ./configure --enable-maccatalyst && make world
cd tests/dotnet/UnitTests
dotnet test --filter "FullyQualifiedName~DotNetWatch"

Minimal manual repro (what produced the log above), from tests/dotnet/HotReloadTestApp/MacCatalyst:

AdditionalFile=/tmp/hrtest/AdditionalFile.cs \
UseMonoRuntime=false RunWithOpen=false EnableSandbox=false \
HOTRELOAD_TEST_APP_LOGFILE=/tmp/hrtest/output.log \
dotnet watch --non-interactive --disable-build-servers

then edit /tmp/hrtest/AdditionalFile.cs so the partial method assigns a different value. The app prints the variable once a second, receives the edit, and crashes instead of printing the new value.

The app is built with UseInterpreter=true, MtouchLink=None, Registrar=partial-static (Hot Reload requires no trimming). Note MtouchLink=None means the assembly is not rewritten in any way — I verified the HotReloadTestApp.dll in the app bundle is byte-identical to the compiler output, so this is not a tooling/rewriting artifact.

Ruled out

• ReadyToRun — user assemblies are already excluded from the composite image, and building with PublishReadyToRun=false still crashes.
• Assembly rewriting — obj/, linked/, bin/ and the app bundle copies of HotReloadTestApp.dll all have the same SHA1.
• DebuggableAttribute — identical blob (01 00 07 01 00 00 00 00) in the failing app and the working desktop console app.
• Tiered compilation being merely disabled — DOTNET_TieredCompilation=0 on the desktop console app does not reproduce. The feature being compiled out is not the same as it being switched off.

Regression information

• Suspect: Use CodeVersioning for EnC #130159 ("Use CodeVersioning for EnC"), commit e614b71, merged 2026-07-28. I have not bisected, but the failure signature points directly at the mechanism that PR introduced, and the timing matches when it reached us via dependency flow.
• I could not find an existing issue for this — nothing references Use CodeVersioning for EnC #130159, and no commit to codeversion.cpp or prestub.cpp since it merged looks related. EnC: metadata rows added by a delta are invisible to lookups once the table's lookup hash is built (ApplyUpdate fails: 'The assembly update failed') #131752 is a different EnC bug (FieldRVA lookup hash) and is already fixed.

Configuration

• Runtime: dotnet/runtime 067d74c23c41161cedb93f672be3de0f2452a3d0 (via VMR dotnet/dotnet@7cdb217445905f3342bbb0266a4497b9a014389a), packages 11.0.0-rc.1.26411.119
• SDK: 11.0.100-rc.1.26411.119
• Targets: net11.0-maccatalyst and net11.0-ios, arm64, CoreCLR + interpreter
• Host: macOS, Apple Silicon
• Not affected: desktop macOS CoreCLR (JIT), and Mono on all platforms — the corresponding useMonoRuntime: true test cases still pass.