`pear.exe` crashes with STATUS_STACK_BUFFER_OVERRUN (0xC0000409) on every invocation, including `pear --version`

[nomadicco0-star]

Description

pear.exe v3.0.0 crashes immediately and deterministically on every invocation on Windows 11, including the simplest possible command (pear --version). No output is produced before the crash. This happens whether invoked directly (AppData\Local\Programs\pear\pear.exe) or via the npm-installed pear wrapper (AppData\Roaming\npm\pear.cmd, which just spawns the same binary) — both paths hit the identical crash.

Environment

• OS: Windows 11 Home, build 10.0.26200
• CPU: 11th Gen Intel Core i5-1135G7 (Tiger Lake) — AVX2/AVX-512 capable, ruling out an instruction-set mismatch
• pear version: 3.0.0 (latest dist-tag — confirmed current at time of report)
• Node.js: v24.18.0
• npm: 11.16.0
• pear.exe SHA256: A07EC55E03DFAA6EEDFA96633AB4072A823AE9B59AA90CE60C68213817C83200

Steps to reproduce

pear --version

(also reproduces identically with pear touch, npx pear --version, and invoking pear.exe directly with a full path)

Actual result

Process exits immediately with exit code -1073740791 (0xC0000409 / STATUS_STACK_BUFFER_OVERRUN) and no stdout/stderr output at all. This exit code is also used by __fastfail()/abort() on Windows, and critically, that path bypasses Windows Error Reporting entirely — so no crash dump or WER event is ever created.

Expected result

Normal CLI output, e.g. the version string for pear --version.

What I've ruled out

• Stale/corrupted install — reinstalled via two separate methods (npm global install and the pear.sh bootstrap installer); same crash both times.
• Corrupted local state — renamed %APPDATA%\pear aside entirely; crash persists with a fully fresh state directory.
• Missing VC++ Redistributable — confirmed present.
• Windows Defender / real-time protection — confirmed via Get-MpComputerStatus that RealTimeProtectionEnabled was genuinely False at test time (not just toggled in the UI, which Tamper Protection can silently revert); crash was byte-for-byte identical with protection off.
• CPU instruction-set incompatibility — CPU supports AVX2/AVX-512.
• Outdated pear version — 3.0.0 is the current latest on npm at time of testing.
• npm-wrapper vs standalone binary discrepancy — traced pear.cmd's source; it just spawns the exact same pear.exe, so both entry points are hitting the identical crash in the identical binary.

Given the crash is 100% reproducible on the very first command with no state involved yet, this looks like a genuine platform-specific bug in the 3.0.0 Windows build rather than an environment/AV issue on this particular machine. Happy to provide further diagnostics (WinDbg trace, etc.) if that would help narrow it down.

[rafapaezbas]

Hello @nomadicco0-star, thank you very much for the report.

To isolate the issue, it would be ideal if you could try running a simple standalone "hello world" with Bare. Could you build a hello.js file with a simple console.log and run it?

npx bare-build --standalone --out ./hello --name hello --host win32-x64 hello.js