Windows: editor access violation and renderer in-page error during long MP4 exports #175

Repro evidence (Windows, 2026-11-07)

FrameTrellis v1.4.0, bundled MLT 7.42.0, on Windows: the editor and renderer unexpectedly stopped while exporting video. This is a real user-observed bug, not a synthesized benchmark.

• 09:38:46 — editor log recorded render-helper start; last autosave 09:50:25. No normal editor shutdown markers. Next application launch 09:58:16.
• Windows Reliability Monitor at 09:51 recorded two separate failures:
  • frametrellis.exe: 0xC0000005 (access violation), faulting module ntdll.dll.
  • frametrellis-render.exe: 0xC0000006 (in-page error), faulting module ntdll.dll.
• Another export began 09:59:08, editor stopped after last autosave 10:02:24, restarted 10:03:25. The faulting module for this second event hasn't been provided.
• Earlier export log includes successful, cancelled, and forcibly cancelled helper runs. Do not mislabel a cancellation as a crash.
• The supplied log did not contain a Windows call stack, WER dump, failing media sample, or a verified root cause. The two different exception codes should be investigated independently, including storage/page-file or memory-mapped file access for 0xC0000006; ntdll.dll appearing as the faulting module is not sufficient to blame Windows.

Mitigations already merged

• fix(export): release renderer handles safely and report Windows crash diagnostics #173 — encoder lifetime ordering, bounded helper diagnostics, milestones, and repeated FPS / GUI export regression.
• fix(recovery): preserve recovered autosave across repeated crashes #174 — recovered projects retain their autosave across a second abrupt stop.
• fix(export): pause preview playback while render helper is active #176 — pauses active timeline preview during export to reduce competing decoder/IO load; this is a mitigation, not a verified root-cause fix.
• fix(export): persist latest unsaved edits before launching renderer #177 — persists a fresh project recovery copy before launching export, including recent unsaved edits.
• tooling(windows): opt-in WER minidumps for native export crash diagnosis #178 — merged: opt-in Windows crash minidump tooling to obtain native call stacks for future reproductions.
• fix(render): validate helper progress frame counts before integer conversion #180 — merged: checks helper-protocol frame counts before converting JSON numeric values to FrameCount to avoid undefined integer conversion on malformed values.
• test(render): prove editor survives abnormal helper exit and preserves output #179 — merged: controlled failed-helper isolation, bounded stderr, preserved output and retry tests.
• fix(export): remove only job-owned partial MP4 after renderer failure #181 — merged: clean up only the failing renderer's job-owned temporary MP4 after it exits; whole-editor crashes still require manual investigation.
• fix(render): bound child stdout reads and recover protocol after oversized lines #182 — merged: read and parse child stdout in bounded chunks to avoid transient large allocations from unframed diagnostics.
• fix(render): bound stderr reads from crashing export helper #183 — merged; CI and Windows packages verified: bound FFmpeg stderr reads to avoid large GUI allocations; stress test with 2 MiB stderr per failure.
• fix(export): deliver cancellation requested before renderer startup #184 — merged; CI and Windows packages verified: retain cancellation requested during helper startup and deliver it exactly once after QProcess starts; regression for Starting and Running cancellation.

These changes passed CI but are not proof the reported native crashes are eliminated. They are after v1.4.0 and need a separately verified Windows build.

Additional independent Windows CI evidence

The combined main build on 2026-11-07 had a Windows 11 ARM x64-emulation
package-verification failure on its second independent portable GUI launch:
0xC0000005 shortly after QML main window created, before the screenshot.
The first portable and later installed GUI launches passed. Windows Server 2022/2025
and application CI passed. This is tracked as #185
with an opt-in default/software Qt Quick comparison in draft #186.
Shared exception code does not establish a shared cause with the user's export crash.

Investigation / acceptance criteria

• Capture opt-in, local WER minidump + call stack for both executables (avoid publishing private media/paths); identify exact faulting thread/module, native symbols/build version.
• Check whether failures correlate with source/output location, disk or page-file errors, Windows Event Viewer disk/NTFS/storport events, memory pressure, and codec/MLT plugin use. Do not automatically assume storage failure.
• Reproduce with redacted/synthetic footage and actual selected export FPS, long-duration render, GPU/software rendering, audio, and simultaneous editor preview.
• Guarantee renderer failure never terminates the editor, recovery survives two consecutive process terminations, and no partial output overwrites a finished file.
• Add a regression based on the identified cause and verify long Windows export with packaged release binaries.

Privacy

Paths, usernames, project media titles, fault process IDs, and report IDs were deliberately omitted. Ask the reporter before requesting dumps or private footage.