Zitat von Stevie:

Was hat LLVM mit ner 64bit VCL Anwendung zu tun?

War es nicht so dass der Hersteller von Delphi den 64Bit compiler nicht nochmal geschrieben hat sondern für alle versionen die nicht Win32 sind konsequent LLVM als compiler ziel benutzt? Ich weiß nicht wie sehr LOW LEVEL LLVM wirlich ist oder ob vielleicht threads ein paar high level ansätze haben.

habe mal nachgesehen...
tatsächlich
sind nur diese LLVM basiert
DCCIOSARM
DCCIOSARM64
DCCAARM
DCCAARM64
DCCLINUX64
DCCOSX64
also ist Windows64 einfach nur ein sau langsamer compiler, ohne guten grund.
Das hat mich wohl in die irre geführt.

@Stevie:
Moin, habe das mal untersucht und nachdem ich auf den Stop Button im Profiler geklickt hatte, kam nach ein paar Sekunden die Anzeige, dass das Programm keine Rückmeldung mehr hat. Im Taskmanager waren 0% CPU Auslastung unf 12MB Speicher belegt. Meine Anwendung lief währenddessen noch weiter. Diese habe ich dann manuell beendet und dann kam der Profiler auch wieder "zurück". 94% Local und Global Ratio mit 4828 Samples ist die win32u.dll mit dem Aufruf NtUserMsgWaitForMultipleObjectsEx.
Ich denke mal, dass heißt, dort steht er am längsten drinne oder?
Das ist eigentlich auch klar, da dieser Aufruf von meinen Threads überall so gemacht wird (mit der MessageQueue) und dann anschließend mit dem PeekMessage.
Im Profiler die ersten Funktionen, die direkt mit meinem Quelltext zu tun haben, sind bei einem Ratio von 0.04% und <4 Samples.

So richtig sagt mir das jetzt erstmal noch nichts

Edit: Ich habe zu dem Thema Thread, Queue und Events ein separaten Beitrag aufgemacht, da es in diesem Beitrag eigentlich um die Analyse des VCL Hängers gehen soll

So, neue Erkenntnisse:

Aufgrund des Profilers von Stevie, bin ich darauf aufmerksam geworden, dass ich den Hänger 2x nicht nachstellen konnte.
Warum?
Weil die Exe aus dem Profiler gestartet wurde und nicht aus der IDE.

Nochmal den Test ohne Profiler gemacht und es ist tatsächlich so.

Starte ich die Anwendung aus der Delphi IDE, kann ich den Fehler jedes Mal reproduzieren.
Starte ich die Anwendung OHNE die Delphi IDE, ist es nicht mehr reproduzierbar.

Mehrmals mit beiden Konstellationen versucht und immer das gleiche Ergebnis.
Also hängt sich der Debugger da irgendwo rein und erzeugt den Hänger in irgendeiner Form...
Na toll, muss man erstmal drauf kommen

Hast Du schon mal den Application Verifier probiert?

Zitat:

Hast Du schon mal den Application Verifier probiert?

Sagt mir gar nichts.
Von wem ist der, wo gibts den und was soll er machen?

Zitat:

Der Unterschied liegt insbesondere bei Multithreadanwendungen im Timing beim Threadscheduling. Das Zusammenspiel der Threads ändert sich dadurch.

Das kann auch umgekehrt auftreten, nämlich, dass es im Debugger nicht passiert.

Das heißt allerdings nicht, dass das Debuggen direkt mit dem Fehler zu tun hat. Es bedeutet nur, dass es diesen leichter oder schwerer nachstellbar macht.

Ein Punkt, der direkt die Delphi IDE betrifft:
Diese setzt mit timeBeginPeriod..timeEndPeriod systemweit die Timer-Auflösung herunter, ich glaube auf 1. Dadurch verhalten sich insbesondere Aufrufe von Sleep anders.

Danke für den Hinweis Sebastian!

Den Application Verifyer gibts von microsoft (https://learn.microsoft.com/de-de/wi...ation-verifier). Er hat mir schon ein paar mal geholfen, wenn ich seltsame, teilweise im Debugger nicht nachvollziehbare Fehler hatte.

Zitat von AJ_Oldendorf:

Also hängt sich der Debugger da irgendwo rein und erzeugt den Hänger in irgendeiner Form...

Der Unterschied liegt insbesondere bei Multithreadanwendungen im Timing beim Threadscheduling. Das Zusammenspiel der Threads ändert sich dadurch.

Das kann auch umgekehrt auftreten, nämlich, dass es im Debugger nicht passiert.

Das heißt allerdings nicht, dass das Debuggen direkt mit dem Fehler zu tun hat. Es bedeutet nur, dass es diesen leichter oder schwerer nachstellbar macht.

Ein Punkt, der direkt die Delphi IDE betrifft:
Diese setzt mit timeBeginPeriod..timeEndPeriod systemweit die Timer-Auflösung herunter, ich glaube auf 1. Dadurch verhalten sich insbesondere Aufrufe von Sleep anders.