Reduce Windows ReadFileIntoBuffer chunk to 16 MB (AppContainer errcode 1450)

[Gianluca Mazza (gianlucamazza)]

Description

WindowsEnv::ReadFileIntoBuffer currently issues up to 1 GB per ReadFile call. On Windows AppContainer / UWP (observed on Xbox Series S Dev Mode) a large single transfer can fail intermittently with:

ReadFile … fail, errcode = 1450 - ERROR_NO_SYSTEM_RESOURCES

This surfaces when loading ONNX models with large external .onnx.data (e.g. ~0.5–1 GB tensors such as an un-quantized embedding table inside a multi-GB external file). AppContainer cannot use ORT's preferred mmap path (non-FromApp mapping APIs are blocked), so every large external read goes through this loop.

Reducing the per-call cap to 16 MB keeps the same total I/O with far fewer pages locked in the MDL for each transfer. Desktop behavior is unchanged aside from more loop iterations.

Related: AppContainer path canonicalization was addressed in #28509; this is an independent I/O sizing issue. Tracker: #29730.

Motivation and Context

• Unblocks reliable load of external-data ONNX models under AppContainer memory pressure.
• Validated on Xbox Series S UWP with ORT DirectML 1.24.4 + a 1.86 GB-extdata int4 model: 6/6 clean restarts, 0× errcode 1450 after the change; previously intermittent.

Alternatives considered

• Keep 1 GB and document “don’t use large external data in AppContainer” — fragile for real multi-GB models.
• 64 MB / 128 MB — also likely fine; 16 MB is conservative and matched the field fix.

How was this tested?

• Real hardware: Xbox Series S Dev Mode, UWP AppContainer, model with 1.86 GB external data.
• Before: intermittent 1450 on ReadFile model.onnx.data.
• After (16 MB): load + generate, 6/6 restarts.

Happy to adjust the constant if maintainers prefer a different cap (e.g. 64 MB).

Checklist

• I have addressed comments/review feedback
• I have linked the related issue (Windows AppContainer: large ReadFileIntoBuffer chunks can fail with ERROR_NO_SYSTEM_RESOURCES (1450) #29730)

[azure-pipelines]

Azure Pipelines:
There may be pipelines that require an authorized user to comment /azp run to run.

[Gianluca Mazza (gianlucamazza)]

Cross-ref: console validation and field numbers are also tracked in the xllama project (gianlucamazza/xllama#86).

[Copilot]

Pull request overview

This PR adjusts the Windows filesystem implementation (WindowsEnv::ReadFileIntoBuffer) to reduce the maximum per-ReadFile transfer size from 1 GB to 16 MB. This targets intermittent ReadFile failures under Windows AppContainer/UWP environments (e.g., Xbox Dev Mode) when loading large ONNX external data blobs, improving reliability without changing total I/O semantics.

Changes:

• Reduced the maximum per-call ReadFile chunk size to 16 MB to avoid ERROR_NO_SYSTEM_RESOURCES (1450) under AppContainer memory pressure.
• Added explanatory comments and linked the related tracker issue for context.

[Gianluca Mazza (gianlucamazza)]

Could a maintainer authorize CI on this (/azp run)? Field data point: on the affected device (Xbox Series S Dev Mode, AppContainer) the 16 MB chunking eliminated errcode 1450 across 6/6 clean app restarts loading a >2 GB external-data blob (un-quantized fp16 embed weights).

[Xavier Dupré (xadupre)]

Copilot merge with main branch

[Gianluca Mazza (gianlucamazza)]

The failing checks all look infrastructure-related: the Windows pipelines timed out at exactly 24h waiting for runners, and web_Release died mid "E2E package consuming test" with no step conclusion (runner termination). Could a maintainer trigger a re-run? Happy to rebase if that helps.

[Gianluca Mazza (gianlucamazza)]

Merged with main as requested (Xavier Dupré (@xadupre)). The previous red check (web_Release / build_onnxruntime_web) and the cancelled jobs looked infra-related (24h runner timeout), so a fresh pipeline run on the updated branch should tell. /azp run when convenient — thanks!