The problem itself is a bug, no argument. But the debugger is not faulty, the stack is not corrupted. It correctly reports the location at which the
exception was raised. That is just not the location that is at the root of the problem, but that is fairly often the case.
I am sorry, may be didn't explain this clearly.
The debugger is reporting only 9 calls and stopped at TApplication.ProcessMesage , this call explicitly means there is more to it and it could be helpful or it could be not, but that is not up to the debugger to decide, it should go deeper, you already pasted two stacks report, so why one is over 50 walked and the real needed one with an
exception is stopped/cut at 9 ?
That is my point about failing or buggy debugger.
Also see your first stack there is no ProcessMessages or ProcessMessage, so why that specific call in the stack (on
exception) to begin with ?
If you noticed in the first stack (long) the whole process is logical and right, on other hand with the one with the
exception also looks logical and fine but where and who (or whom ? bad English) did call it ?
All stacks should be resolved/walked to the origin, in the first one +50 was enough but if you want to go deeper, you should pass TApplication.Run and continue into address inside the kernel, same with threads but-there will be any TApplication.xxxx ,because they are what are they, threads.
Now back to the case at hand, Who did call ProcessMessage(MSG), and why the debugger stopped or failed to continue walking the stack from there to something declaring it is in fact the main thread form UI main message handling.
Did Application.ProcessMessages called form he main thread by design from the
VCL ???? that ducked up to say the least, and that from an event triggered by the UI, well i am out of words here.
Yet again will repeat it, even if that is the case then ProcessMessage that reported in the stack should have a caller reported and resolved by the debugger.
Sorry again if that is still not clear, but i hope it might be.