🐛 Access violation (0xC0000005) on win32-arm64 — regression in 2.5.2, still present in 2.5.7

[fmadore]

Environment information

Details

CLI:
  Version:                      2.5.7
  Color support:                true

Platform:
  CPU Architecture:             aarch64
  OS:                           windows

Environment:
  BIOME_DISTRIBUTION:                unset
  BIOME_LOG_PATH:                    unset
  BIOME_LOG_PREFIX_NAME:             unset
  BIOME_LOG_LEVEL:                   unset
  BIOME_LOG_KIND:                    unset
  BIOME_CONFIG_PATH:                 unset
  BIOME_THREADS:                     unset
  BIOME_WATCHER_KIND:                unset
  BIOME_WATCHER_POLLING_INTERVAL:    unset
  NO_COLOR:                     unset
  TERM:                         xterm-256color
  JS_RUNTIME_VERSION:           unset
  JS_RUNTIME_NAME:              unset
  NODE_PACKAGE_MANAGER:         unset

Biome Configuration:
  Status:                       Not set
  Path:                         unset

Workspace:
  Open Documents:               0

Host: Windows 11 (10.0.26200), Snapdragon / Windows-on-ARM, Node v24.18.1 win32-arm64.

What happened?

biome lint crashes with an access violation on win32-arm64 as soon as it does
any analysis work. It reproduces on a two-line JavaScript file with no
configuration file anywhere on the path, so it is not rule-, config- or
project-specific.

1. Create an empty directory outside any repository:

   mkdir biome-arm-repro
   cd biome-arm-repro
   "const a = 1;`nconsole.log(a);" | Set-Content t.js

2. Install the platform binary directly (bypassing the @biomejs/biome wrapper,
   to rule the wrapper out):

   npm i --no-save @biomejs/cli-win32-arm64@2.5.7

3. Run it:

   & .\node_modules\@biomejs\cli-win32-arm64\biome.exe lint t.js

Result: no output at all, and

LASTEXITCODE = -1073741819   # 0xC0000005, STATUS_ACCESS_VIOLATION

Under Git Bash the same command reports Segmentation fault, exit 139.

biome --version and biome rage both succeed at the same version (the rage
output above was produced by the very binary that crashes), so the executable
loads and runs — it dies only once it starts analysing.

Bisect

Same machine, same t.js, same command, only the version of
@biomejs/cli-win32-arm64 changed:

Version	Result
2.4.16	✅ lints
2.5.0	✅ lints
2.5.1	✅ lints
2.5.2	❌ 0xC0000005
2.5.3	❌ 0xC0000005
2.5.4	❌ 0xC0000005
2.5.5	❌ 0xC0000005
2.5.6	❌ 0xC0000005
2.5.7	❌ 0xC0000005

2.5.2 is the first affected release. To confirm the passing runs are not a
silent no-op, I ran 2.5.0 against a file with an actual violation
(if (a == b) { var x = 1 }) and it correctly reported
lint/correctness/noUnusedVariables.

Nothing in the 2.5.2 release notes looks platform- or build-related — they are
all rule and formatter changes — so I suspect the toolchain or build
configuration rather than a specific code change.

Possibly related

This looks like the same bug class as #10270 ("Biome 2.4.14 broken on Windows on
ARM"), which was closed as fixed on 2026-05-07 with the conclusion, from the
biome-win-arm-debug CI runs, that 2.4.14 was the only affected version. That
no longer holds: 2.5.2 through 2.5.7 are all affected on this machine.

Workaround, for anyone who lands here

The x64 binary runs fine under Windows-on-ARM emulation:

npm i --no-save --force --cpu=x64 --os=win32 --prefix /tmp/biome-x64 @biomejs/cli-win32-x64@2.5.7
/tmp/biome-x64/node_modules/@biomejs/cli-win32-x64/biome.exe lint .

I am happy to run further diagnostics on this machine — a debug build, a
pkg.pr.new build, or a bisect over commits between 2.5.1 and 2.5.2 — if that
would help narrow it down.

Expected result

biome lint t.js should lint the file and exit 0, as it does on 2.5.1 and as it
does with the x64 binary under emulation.

Code of Conduct

• I agree to follow Biome's Code of Conduct

[github-actions]

✅ Organic activity

No automation signals detected in the analyzed events.

View full analysis →

_{This is an automated analysis by AgentScan}

[ematipico]

Some of us don't possess a Windows machine, so if you can find a fix for us, that would be great

[fmadore]

I think I found the cause, and it looks like it's the bundled allocator rather than Biome's own code.

Setting MIMALLOC_VERBOSE=1 makes the binary print which mimalloc it uses:

• Biome 2.5.1 → mimalloc v2.2.4 → works
• Biome 2.5.7 → mimalloc v3.3.1 → crashes

mimalloc v3.3.1 is already known to be broken on Windows ARM64: microsoft/mimalloc#1277, fixed by microsoft/mimalloc#1283 (merged 2026-04-23).

I also tested this outside Biome with a small Rust program that just allocates memory: with libmimalloc-sys 0.1.47 (v3.3.1) it crashes the same way, and with 0.1.49 (v3.3.2) it doesn't.

Biome's Cargo.lock currently has libmimalloc-sys 0.1.47 (on main, 2.5.2 and 2.5.7) — the broken one. libmimalloc-sys 0.1.47 was published on 2026-04-22, one day before the upstream fix landed. Running cargo update -p libmimalloc-sys moves it to 0.1.49, which passed in my test.

This may be the same underlying issue as #10270.

I haven't rebuilt Biome itself to confirm — only tested the allocator in isolation.

[ematipico]

I wonder how it got in, because we reverted that change...

Thank you for the analysis

[dyc3]

I've reverted mimalloc and started a preview build with the fix: https://github.com/biomejs/biome/actions/runs/31099289766

@fmadore when its done building, would you mind testing it?

[fmadore]

Tested the preview build (run 31099289766, cli-aarch64-pc-windows-msvc) on win32-arm64 and it fixes the crash. Thanks!

MIMALLOC_VERBOSE=1 confirms the binary now uses mimalloc v2.2.4 (was v3.3.1).

• biome lint . and biome check . → 62 files checked, exit 0, no access violation
• biome lint ./does-not-exist (which used to die too) → normal "paths ignored" diagnostic
• 10 consecutive check . runs → 0 crashes