0.5.6: silent crash during recording on Windows 11 (0xc0000005, mostly ntdll.dll) - recording lost, no error shown

[MoritzV42]

Summary

Since updating to 0.5.6 (released Jul 17), Cap crashes silently mid-recording on Windows 11. The recording indicator/tray simply disappears, no error dialog is shown, and the recording is lost (the .cap folder is left without project-config.json, only orphaned DASH segments). Before 0.5.6 the same setup was stable for weeks of daily recordings.

What triggers it

• Most reliably: pressing Pause during a recording (reproduced several times).
• But it also dies spontaneously during recording with no interaction at all — we only noticed because the recording indicator was gone.

Windows Event Log evidence

7 APPCRASH events on Jul 18 alone, all Cap.exe 0.5.6.0 (timestamp 0x6a4edb0e), exception code 0xc0000005 (access violation):

Time (local)	Faulting module	Offset
10:04	ntdll.dll 10.0.26100.8521	0x21dc9
10:33	ntdll.dll	0x21dc9
10:37	ntdll.dll	0x21dc9
10:40	ntdll.dll	0x164747
11:22	Cap.exe	0x1e9ba80
11:28	ntdll.dll	0x1decd
11:32	ntdll.dll	0x164747

Cap's own logs end abruptly mid-recording (no "pipeline shutdown" / teardown lines), consistent with a hard process crash. The ntdll offsets (heap paths) at multiple distinct addresses suggest heap corruption rather than a single bad call site.

Environment

• Cap 0.5.6.0 (desktop, installed via .exe), path C:\Users\<user>\AppData\Local\Cap\Cap.exe
• Windows 11 Home, build 26200
• Recording: screen + mic, DASH segments visible in %APPDATA%\so.cap.desktop\recordings\

Additional note

Older releases on GitHub currently have no installer assets attached, so downgrading as a workaround isn't possible. If you could attach a 0.5.5 (or last-known-good) Windows installer to a release, that would help affected users a lot while this is investigated.

Happy to provide full logs or the WER report IDs if useful.

[linear]

CAP-760

[tembo]

Thanks for the detailed report and the Windows Event Log evidence. The multiple distinct ntdll.dll offsets in heap-related paths do strongly suggest heap corruption rather than a single deterministic crash site.

Some context that might help investigation:

Related but different issue fixed in 0.5.6: PR #1991 was merged just before the 0.5.6 release to fix a different pause-related problem on Windows. That fix addressed the MediaFoundation H264 encoder health monitor false-tripping a 5-second timeout after a long pause, which would abort recordings cleanly with an "Encoder unhealthy: Timeout" error. Your crash is different - it's a hard process crash with no error, so PR #1991's fix wouldn't address this.

Code area to investigate: The Windows recording pipeline uses the MediaFoundation H264 encoder in crates/enc-mediafoundation/src/video/h264.rs. The Windows fragmented muxer and output pipeline code are in crates/recording/src/output_pipeline/. Since the crash also happens spontaneously during recording (not just on pause), the issue may be in the frame processing or muxing path rather than pause-specific logic.

Possibly related issues:

• #1772 - Windows startup crash with similar ntdll.dll heap corruption signature (exception 0xc0000374), though on an earlier version
• #1954 - Windows crash with 0xc0000005 on AMD iGPU (different root cause, but similar crash pattern)
• #1589 - Excessive RAM usage during pause (macOS, but may share underlying buffer management code)

Diagnostic suggestions: If you're able to capture a minidump from one of the crashes (via WER settings or a tool like ProcDump), that could pinpoint the exact stack trace. The WER report IDs you mentioned could also help if the team has access to Microsoft's crash reporting backend.

Regarding the downgrade request - older release installers appear to be missing from the GitHub releases page, so attaching a 0.5.5 Windows installer would indeed help affected users as a workaround while this is being investigated.