Also der Titel ist echt etwas verwirrend.
Nein, man nutzt die VCL niemals nie innerhalb eines "anderen" Threads, als dem Hauptthread.

Dann liegt es wohl nicht an den VCL-Dialogen.

MessageDlg nutzt standardmäßig intern die TaskDialog-API von Windows.
Unter gewissen Umständen (uraltes Windows, Idioten, VCL-Styles, sonstwas) werden intern aber VCL-Dialoge (TForm) genutzt.

Laufen bei dir Timer oder Threads, welche irgendwas machen/blockieren können?

Wie sieht die CPU-Last aus?
* hängt es nur (Sleep, WaitFor oder so)
* arbeitet irgendwas und der Thread arbeitet Volllast (Hauptthread mit 100%)

Joar, auf "Pause" im Debugger, während es im Dialog hängt
und falls man im Stack noch nichts sieht, dann versuchen mittels F7/F8 weiter zu schauen, ob man irgendwann in Code landet, welcher am Arbeiten ist/hängt.

Mal mit 32 Bit probieren?




Egal ob VCL-Dialoge oder DialogAPI vom Windows,
es läuft intern eine MessageLoop, welche alle Messages verarbeitet, also z.B. Timer und Paint der anderen Forms uvm.

Außer, dass die VCL-Dialoge TApplication.ProcessMessage nutzen und dort mehr machen,
als die "blanken" / fremden PeekMessage/TranslateMessage/DispatchMessage in der MessageLoop des Taskdialogs,
wo also WM_QUIT, OnMessage, IsPreProcessMessage, IsHintMsg, IsMDIMsg, IsKeyMsg und IsDlgMsg nicht behandelt würden, während der Dialog angezeigt wird.