x86 validation: bad allocation before extracting ~614 MiB portable ZIPs (1.29.280) #6632

Relevant area(s)

WinGet CLI

Relevant command(s)

winget install

Brief description of your issue

WinGet 1.29.280 exits with Caught std::exception: bad allocation / 0x8a150003 while validating two approximately 614 MiB portable ZIP installers on the x86 validation worker. Both failures occur after download, SHA256 verification, and successful IAttachmentExecute::Save(), before any archive-extraction log entry or application execution.

Affected submissions:

• Update: XGo.LLGo.MSVC to 1.0.9 winget-pkgs#464370 — XGo.LLGo.MSVC 1.0.9
• Update: XGo.LLGo.MinGW to 1.0.9 winget-pkgs#464371 — XGo.LLGo.MinGW 1.0.9

The evidence below comes from the public validation service artifacts, not a separate local Windows reproduction. The logs do not contain a native stack trace, so the exact allocation site is unconfirmed.

Steps to reproduce

Use the x86 installer entry from either linked PR on a Windows x86 worker with WinGet 1.29.280. The validation service enabled LocalManifestFiles and LocalArchiveMalwareScanOverride, then ran:

winget install --manifest C:\Users\Validator\AppData\Local\Temp\Manifest.yaml --installer-type zip --accept-package-agreements --skip-dependencies --ignore-local-archive-malware-scan

Both manifests use InstallerType: zip, NestedInstallerType: portable, and NestedInstallerFiles: [{ RelativeFilePath: bin/llgo.exe, PortableCommandAlias: llgo }].

Both downloaded archives were independently checked: the hashes match the manifests and published GitHub asset digests, bin/llgo.exe exists, and all ZIP entry CRCs pass. The static installer scans also passed in both PRs. MSVC x64 and ARM64 installed and ran llgo.exe with exit code 0. MinGW has successful x64 and ARM64 ARP registration; its separate ARM64 executable-discovery review is not the x86 failure reported here.

Expected behavior

The x86 portable ZIP installs successfully without exhausting the client's address space during archive processing.

Actual behavior

Both x86 runs exit with -1978335229 (0x8a150003). The tail of the MSVC WinGet log is:

2026-10-29 00:46:52.183 <I> [CLI ] Installer hash verified
2026-10-29 00:47:04.586 <I> [CORE] Finished applying motw using IAttachmentExecute. Result: 0 IAttachmentExecute::Save() result: 0
2026-10-29 00:47:09.617 <E> [CLI ] Caught std::exception: bad allocation

The MinGW run has the same sequence and error.

A possible allocation-pressure source is Archive::ScanZipFile in v1.29.280, which materializes the entire ZIP in a vector before calling pure_zip. ScanArchiveFromLocalManifest calls the scanner even with the override argument; it checks the argument only after the scanner returns. This is a hypothesis consistent with the log sequence, not a confirmed stack trace. Please investigate the allocation behavior on x86 and the appropriate validation path for these archives.

Environment

WinGet: 1.29.280
OS: Windows.Desktop v10.0.19045.6456
Package: Microsoft.DesktopAppInstaller v1.29.280.0
Validation architecture: x86

Public diagnostic bundles (download URLs expire 2026-11-28):

• WinGetSvc-Validation-464370-1
• WinGetSvc-Validation-464371-1

Relevant files are ValidationResult/XGo.LLGo.{MSVC,MinGW}/1.0.9/InstallationVerification_Result.json and the x86-...-WinGet-...log files under InstallationVerificationLogs.