cardano-node crashes with STATUS_FATAL_USER_CALLBACK_EXCEPTION (0xc000041d) on Windows, leaving ChainDB dirty

[disassembler]

Description

cardano-node hard-crashes on Windows with exception code 0xc000041d (STATUS_FATAL_USER_CALLBACK_EXCEPTION). The process terminates without any shutdown logging, leaving the ChainDB in a dirty state. On the next startup, the node triggers a full ImmDB validation of all ~8,981 chunks (~2–3 hours), during which the wallet API is unavailable and Daedalus appears permanently disconnected.

Environment

• OS: Windows 10.0.19045
• cardano-node version: 11.0.1-97036a66b
• cardano-wallet version: 2026.5.11-c642e0779
• Daedalus version: 11.0.0 (build 50706edb8)
• Network: Mainnet
• CPU: 12th Gen Intel Core i9-12900KF
• RAM: 63.8 GB

Steps to Reproduce

1. Run Daedalus/cardano-node on Windows for an extended period while fully synced
2. Node crashes (no user action required — appears to occur spontaneously)

Observed Behaviour

• cardano-node process (PID 2520) terminates abruptly with no shutdown log entries
• Windows Application Error Event Log records:
  • Event ID: 1000
  • Time: 2026-08-01T21:09:57Z
  • Faulting process ID: 0x9d8 (2520)
  • Exception code: 0xc000041d (STATUS_FATAL_USER_CALLBACK_EXCEPTION)
  • Faulting module: bad_module_info / unknown (Windows cannot identify the GHC RTS module)
• On restart, node logs: ChainDB is not clean. Validating all immutable chunks
• Full validation of 8,981 chunks proceeds at ~1 chunk/sec (~2.5 hours total)
• Daedalus shows disconnected / not syncing for the entire validation period

Expected Behaviour

• cardano-node should handle the exception and shut down cleanly, or
• At minimum, write a shutdown reason to the log before terminating

Additional Context

The crash occurred after the node had been running for several hours in a quiet/stable state (fully synced, stable peers). The last log entry before the crash was at 17:05:43Z, with the crash confirmed at 21:09:57Z — a ~4 hour gap with no log output, suggesting the node was running but idle.

The bad_module_info / unknown faulting module is typical for GHC-compiled executables on Windows, as the GHC RTS uses custom memory management that Windows error reporting cannot introspect. A minidump or WER report would be needed for a full stack trace.

The STATUS_FATAL_USER_CALLBACK_EXCEPTION code typically indicates an unhandled exception inside a Windows kernel callback or APC — potentially caused by heap or stack corruption in the GHC RTS.

Relevant node.log excerpt (startup after crash)

[2026-08-01 21:10:40.2513Z][ChainDB.LastShutdownUnclean] ChainDB is not clean. Validating all immutable chunks
[2026-08-01 21:10:40.2513Z][ChainDB.OpenEvent.StartedOpeningDB] Started opening Chain DB
[2026-08-01 21:10:40.2513Z][ChainDB.OpenEvent.StartedOpeningImmutableDB] Started opening Immutable DB
[2026-08-01 21:10:40.4013Z][ChainDB.ImmDbEvent.ChunkValidation.StartedValidatingChunk] Validating chunk no. 0 out of 8981. Progress: 0.00%

Validation was still in progress at 28.23% (chunk 2535/8981) when Daedalus was closed ~15 minutes later.

Windows Event Log entry

<Event>
  <System>
    <Provider Name="Application Error" />
    <EventID>1000</EventID>
    <TimeCreated SystemTime="2026-08-01T21:09:57.7505014Z" />
    <Computer>MASKED</Computer>
  </System>
  <EventData>
    <Data>bad_module_info</Data>   <!-- App name -->
    <Data>0.0.0.0</Data>           <!-- App version -->
    <Data>unknown</Data>           <!-- Fault module -->
    <Data>c000041d</Data>          <!-- Exception code -->
    <Data>00007ffbc143c380</Data>  <!-- Fault offset -->
    <Data>9d8</Data>               <!-- PID (= 2520) -->
  </EventData>
</Event>