Well, that is normal, and there is no ProcessMessage there, the stack when the
exception raised is the most critical to find/capture, hence my question about why it is cut in the screenshot, or just the debugger is failing to walk the stack which indicate bigger/deeper issue in
RTL/
VCL flow like stack overflow (overwrite, wrong declaration..) or just a reproducible debugger failure.
If I let the
IDE break on the
exception the call stack does look like in original post:
Vcl.Forms.TCustomForm.VisualManager_AcceptMessage( (45089, 0, 0, 0, 0, 0, (), 0, 0, (), 0, 0, ()))
Vcl.Forms.TCustomForm.WndProc((9960336, 9960352, 9960168, 9960168, 64416, 151, (), 64232, 151, (), 64232, 151, ()))
Vcl.Controls.TWinControl.MainWndProc(???)
System.Classes.StdWndProc(721212,45089,0,0)
:75d40eab USER32.AddClipboardFormatListener + 0x4b
:75d37e5a ; C:\WINDOWS\SysWOW64\USER32.dll
:75d35bca ; C:\WINDOWS\SysWOW64\USER32.dll
:75d35990 USER32.DispatchMessageW + 0x10
Vcl.Forms.TApplication.ProcessMessage(???)
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.