镜像站点 · 本页由第三方 GitHub 只读镜像提供,非 GitHub 官方站点,不接受任何登录或凭据输入。前往 github.com
Skip to content

Node.js v24.15.0: native crash (exit code 57005/0xDEAD) during npm ci on Windows #62991

Description

@wtgodbe

Summary

node.exe v24.15.0 intermittently crashes with a native fault during npm ci tarball extraction on Windows. The crash produces exit code 57005 (0xDEAD). v24.14.1 is not affected.

Environment

  • OS: Windows Server 2025 (10.0.26100) — Azure DevOps CI agents (windows.vs2026preview.scout.amd64.open)
  • Node: v24.15.0 (crashes), v24.14.1 (no crashes)
  • npm: 11.12.1 (bundled with 24.15.0)
  • CPU: AMD64, Standard_D4a_v4 (4 vCPU, 16GB RAM)
  • Disk: ~147GB free (not a space issue)

Reproduction

The crash occurs during npm ci in the dotnet/aspnetcore repository, which has ~1400 npm dependencies. The crash happens during the tarball extraction phase (after all packages are downloaded from the registry).

  • Frequency: ~43% of Windows CI builds over a 10-day period
  • Linux/macOS: Never observed — Windows only
  • First occurrence: Build 1381847, queued 2026-04-16T11:37:14Z — approximately 4 hours after v24.15.0 was published
  • Zero crashes on v24.14.1 across hundreds of builds

Crash Evidence

Windows Event Log (Application Error, ID 1000)

Faulting application name: node.exe, version: 24.15.0.0
Faulting module name: (empty)
Exception code: 0x...
Faulting process id: 2e0c
Faulting application path: C:\ToolCache\node\24.15.0\x64\node.exe
Report Id: d4db47fc-5298-47bc-a98f-13aebaa4d464

This confirms a native-level crash in node.exe, not a JavaScript exception.

npm debug log analysis

Across multiple independent crashes, the npm debug log is truncated at exactly the same file size (518,908 bytes with maxsockets=15, 868,502 bytes with maxsockets=10). The log ends mid-extraction at the silly tarball phase — different packages each time, but identical byte count. This suggests the process hits a deterministic resource threshold before being killed.

What we ruled out

  • Disk space: 147GB free on all crashed agents
  • Windows Defender: RealTimeProtectionEnabled is disabled on CI agents
  • JavaScript-level crash: NODE_OPTIONS=--report-uncaught-exception produced no report — the crash bypasses JS error handling
  • npm-level error: No npm error output, no .npmrc issues
  • Network: All packages downloaded successfully (cache hits), crash happens during extraction

Suspected changes in v24.15.0

The crash is in the native layer during buffer-heavy tarball extraction. Potentially relevant changes between v24.14.1 and v24.15.0:

  1. buffer: disallow ArrayBuffer transfer on pooled buffer — buffer: disallow ArrayBuffer transfer on pooled buffer #61372 — Changes buffer transfer lifecycle; npm extraction is extremely buffer-intensive
  2. V8 cherry-pick related to the buffer change — [v24.x] deps: V8: cherry-pick 33e7739c134d #62567
  3. npm 11.11.0 → 11.12.1 upgrade — deps: upgrade npm to 11.12.1 #62448 — Though the crash is in node.exe, not npm JS code

Workaround

We pinned to Node.js v24.14.1 in our CI pipeline (dotnet/aspnetcore#66465). Zero crashes since the pin.

Example CI builds

Activity

  1. Renegade334 commented on Apr 30, 2026

    @Renegade334
    Member

    Tried to reproduce by running many iterations of npm ci --workspaces --include-workspace-root in the aspnetcore repo on a Windows desktop, but no dice. Unless anyone can identify a standalone reproduction to test with, we might need help debugging.

  2. added
    windowsIssues and PRs related to the Windows platform.
    on Apr 30, 2026
  3. added a commit that references this issue on May 6, 2026
  4. MurrayMicrosoft commented on May 15, 2026

    @MurrayMicrosoft

    Seeing this at about 5% repro rate on my pipelines running an azure hosted ADO agent pool with agent version v4.273.0

  5. v-dko commented on May 27, 2026

    @v-dko

    HI team, We're seeing this crash (0xDEAD / 0xC0000409) on Azure DevOps hosted Windows agents across all regions — ~15K crashes/day in EU,~130/day in US. Reproduces on Node v24.15.0+ and v25.8.0+, impacting tasks like AzureCLI, AzureKeyVault, PowerShell.
    Related bugs filed against us:

    Is there an ETA for a permanent fix?

  6. Renegade334 commented on May 27, 2026

    @Renegade334
    Member

    Is there an ETA for a permanent fix?

    The root cause has not yet been identified. No-one has reported seeing this outside of Azure DO, which makes debugging rather challenging.

  7. added
    help wantedIssues that need assistance from volunteers or PRs that need help to proceed.
    on May 27, 2026
  8. Maxkrvo commented on May 27, 2026

    @Maxkrvo

    Also interested to see when this will be solved as large enterprise implementations are being affected by this. Do you, @MattIPv4 , perhaps have an idea whether this is something that could be prioritized?

  9. MattIPv4 commented on May 27, 2026

    @MattIPv4
    Member

    👀 This is outside my wheelhouse, sorry, I only help look after the web side of things for Node.js.

  10. Maxkrvo commented on May 27, 2026

    @Maxkrvo

    👀 This is outside my wheelhouse, sorry, I only help look after the web side of things for Node.js.

    Aha my bad mate! Do you perhaps have an idea who could be pinged?

  11. Renegade334 commented on May 28, 2026

    @Renegade334
    Member

    Realistically, we are going to need more error information and/or a standalone reproduction. I could not reproduce with a simple Azure pipeline on windows-2025-vs2026 npm ciing 1500+ packages.

  12. wtgodbe commented on Jun 1, 2026

    @wtgodbe
    Author

    @Renegade334 I can get a repro from the aspnetcore repo - what error information would be helpful? I can get event logs, etc

  13. Renegade334 commented on Jun 2, 2026

    @Renegade334
    Member

    @wtgodbe Would be useful if there were some kind of stack trace available, What's the source of the offending pipeline?

  14. Renegade334 commented on Jun 2, 2026

    @Renegade334
    Member

    Come to think of it, it would be worth re-checking your pipelines with v24.16.0. There was a non-deterministic Windows-only stack buffer overrun in the TCP machinery that was fixed in this release, which does kinda fit with the issue description.

  15. wtgodbe commented on Jun 3, 2026

    @wtgodbe
    Author

    I've re-run 5 times without hitting the issue on 24.16, so I suspect the underlying is fixed! It was a lot more persistent than that previously

  16. linked a pull request that will close this issuedeps: libuv: cherry-pick aabb7651de #62561on Jun 3, 2026
  17. added
    libuvIssues and PRs related to the libuv dependency or the uv binding.
    and removed
    help wantedIssues that need assistance from volunteers or PRs that need help to proceed.
    on Jun 3, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    libuvIssues and PRs related to the libuv dependency or the uv binding.windowsIssues and PRs related to the Windows platform.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions