Hermes (RNW): Access violations when evaluating large (>~64KB) JS source via JSI (0.81.1)

[hifiguitarguy]

Problem Description

Issue

On React Native Windows with Hermes enabled, evaluating a single JavaScript source buffer larger than ~64KB via JSI causes intermittent access violations inside hermes.dll.

This occurs with both:

• runtime.evaluateJavaScript(...)
• runtime.prepareJavaScript(...) + evaluatePreparedJavaScript(...)

The same source executes reliably when split into smaller chunks and evaluated incrementally.

Observations

• Source bytes are verified intact (size and hash checked immediately before evaluation).
• Failure manifests as random AVs or “invalid UTF-8 continuation byte” errors.
• Disassembly shows Hermes dereferencing an invalid pointer, consistent with prior memory corruption.
• Chunking the source into <64KB pieces (native eval), concatenating inside JS, then performing a final eval works 100% reliably.
• Indicates a native ingestion/parsing bug triggered by large input size, not invalid JS or encoding.

Environment

• Platform: Windows
• Runtime: Hermes
• Framework: React Native Windows
• Issue does not reproduce when source is evaluated in smaller native chunks.

Workaround

Avoid passing large source blobs directly to Hermes. Instead:

1. Evaluate small (<64KB) snippets natively to append to a JS-side accumulator string.
2. Perform a final (0, eval)(accumulatedSource) inside JS.
3. Clean up the accumulator.

Expected Behavior

Hermes should safely evaluate large JavaScript source buffers passed via JSI without memory corruption or access violations.

Context (why the script is large)

This issue arises in a custom native ScriptManager TurboModule written to support Module Federation on React Native Windows using Callstack/Re.Pack. The TurboModule is responsible for downloading, caching, and evaluating remote MF bundles at runtime. These remote entry bundles are evaluated as a single script via JSI and commonly exceed 64KB due to the Module Federation runtime, module table, and factory definitions. Evaluating a large source blob is therefore an expected and necessary code path for MF on Windows

Steps To Reproduce

I have not yet created a minimal project to create this issue - it would require a purposed TurboModule.

I would imagine you could likely write a TurboModule that injects an script artificially exceeding 64KB. A memory access violation should occur.

My use is fairly complex via MF - with Windows being the final outlier.

Expected Results

No response

CLI version

20.0.0

Environment

System:
  OS: Windows 11 10.0.26100
  CPU: "(16) x64 AMD Ryzen 9 5900HX with Radeon Graphics        "
  Memory: 4.31 GB / 23.37 GB
Binaries:
  Node:
    version: 24.11.1
    path: C:\Program Files\nodejs\node.EXE
  Yarn:
    version: 1.22.19
    path: C:\Users\_____\AppData\Roaming\npm\yarn.CMD
  npm:
    version: 11.7.0
    path: C:\Program Files\nodejs\npm.CMD
  Watchman: Not Found
SDKs:
  Android SDK: Not Found
  Windows SDK:
    AllowDevelopmentWithoutDevLicense: Enabled
    Versions:
      - 10.0.22621.0
      - 10.0.26100.0
IDEs:
  Android Studio: AI-252.27397.103.2522.14514259
  Visual Studio:
    - 18.0.11222.15 (Visual Studio Community 2026)
    - 17.14.36811.4 (Visual Studio Community 2022)
Languages:
  Java:
    version: 17.0.17
    path: C:\Program Files\Microsoft\jdk-17.0.17.10-hotspot\bin\javac.EXE
  Ruby: Not Found
npmPackages:
  "@react-native-community/cli": Not Found
  react: Not Found
  react-native: Not Found
  react-native-windows: Not Found
npmGlobalPackages:
  "*react-native*": Not Found
Android:
  hermesEnabled: Not found
  newArchEnabled: Not found
iOS:
  hermesEnabled: Not found
  newArchEnabled: Not found

Community Modules

"@callstack/repack": "^5.2.2"

Repack does not implement Windows, I am using a custom TurboModule

Target React Native Architecture

New Architecture (WinAppSDK) Only

Target Platform Version

= 10.0.26100

Visual Studio Version

Visual Studio 2022

Build Configuration

Debug

Snack, code example, screenshot, or link to a repository

No response