That is what I would expect in this situation since the code flow after the PostMessage for the cm_release message returns to the main message loop in TApplication.Run, and thus the call stack unwinds to that location. There is no way to determine where in the code the message was posted, so the debugger cannot show that. Of course that is unfortunate in this case since the stack does not reveal the actual cause of the problem, but we have to live with it since that's how Windows apps work. The debugger can do nothing for us here, the info it would need is simply not there.
Well, i disagree on expecting that behavior, my thoughts on this can be reduced to this:
1) The stack is corrupted and that is that, meaning unwind will fail to find the last SEH handler (or SEH chain) and the app will crash, in case
OS catch an unhandled
exception (through its own SEH) that return to specific positions, it will terminate the process, return position they are .. like if a background thread raised an
exception without SEH trap, the
OS will unwind and find it pointing to its origin in the kernel that called from CreateThread then the app is doomed and will be terminated then and there, also if the main thread raised an
exception, and in unwinding the
OS found it pointing to the code responsible for CreateProcess then also the app is done and gone, now if this is the case and it is confirmed by two users you and OP then this is reproducible
RTL/
VCL bug.
2) The stack is fine and the debugger is failing to walk it, then this is a debugger bug, also confirmed by 2 users.
3) Irrelevant to the stack and what the debugger is able show/walk/report, this
exception confirmed by 2 users, and this is reproducible
RTL/
VCL bug.
So in all case this is a bug and need to be reported/fixed.
as for
Vcl.Forms.TApplication.ProcessMessage being the first/oldest reported by the debugger, these is no more clearer report that there is a bug and it concern the stack itself or the debugger, like above either the debugger had failed or the stack already damaged/corrupted byt the
RTL/
VCL itself.
Also
Vcl.Forms.TApplication.ProcessMessage is Delphi code and it is not an
OS callback function, hence should and must have another code calling it from within Delphi code and that code (procedure/function) should be on the stack too, as simple as that.