http://bugs.winehq.org/show_bug.cgi?id=60243 --- Comment #1 from Madison Steiner <awsmadi@amazon.com> --- Regression status: this is not a regression, so I have left Regression SHA1 empty. The reporting path this bug is about has never worked on x86-64. The TEB-frame walk in RtlUnwindEx was bounded by end_frame from the moment it was introduced: /* 98b8160b732, 2009-06-17, "ntdll: Add support for calling the TEB exception chain handlers on x86_64", first released in wine-1.1.24 */ while ((ULONG64)teb_frame < new_context.Rsp && (ULONG64)teb_frame < end_frame) On an exit unwind end_frame is null, so the loop body never executes and the loader's handler is never reached. That bound survived unchanged until 1ad0e3fed68 (2026-06-30) removed it for bug 59850, so it was present in every release from 1.1.24 through 11.12. Measured with the case D reproducer from the description, on four builds, all identical -- exit 5, no err:module:loader_init, two "invalid frame" errors: 9.0, 10.0, 11.0, 11.15 Case A (the same code without the cleanup frame) reports correctly on all four, exit 67. So the two halves are: before 11.13 the walk is skipped entirely, and from 11.13 the walk does run -- instrumenting it shows "calling TEB handler" going from 1 occurrence to 2 -- while every observable outcome stays the same. That residual failure is what this bug reports. One correction in case anyone repeats the archaeology: `git log -S 'teb_frame < end_frame'` credits 2e81ba5f4ff (2011-01-26, "include: Add a prototype for RtlUnwindEx on x86_64"), but that commit only retyped end_frame from ULONG64 to PVOID and added casts, which changes the literal string and so registers as an occurrence-count change. It did not introduce the bound. 98b8160b732 did. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.