Ursache für hängende Applikation herausfinden

[Bodenseematze]

Zitat von hoika:

Hallo,
bei MadExcept auch "check for frozen main thread" eingestellt?

Zitat von Bodenseematze:

Ich habe jetzt mal MadExcept mit Option "check for frozen main thread" mitlaufen lassen.

Zitat von Delphi.Narium:

Du schreibst u. a. von Datenbank, Freigaben, Resourcen, ...

Der Datenbankserver ist ein MS SQL-Server, der auf einem anderen Rechner läuft.
Beim Rest habe ich Zugriff auf Ressourcen (also z.B. Dateien / Verzeichnisse / Semaphoren etc.) auf dem lokalen Rechner gemeint.
Und mit Freigaben eben die üblichen Sperr-/und Freigabe-Mechanismen von Windows für diese Ressourcen (Mutex, Semaphoren, Critical Section, ...).

Zitat von Delphi.Narium:

Dies könnte eventuell auch eine Erklärung dafür sein, dass identischer Code andernorts keine Probleme bereitet, andererseits aber vollständig unterschiedliche Implementierungen der gleichen Aufgabe zu einem identischen Problem führen.

Es ist nicht andernorts, es ist auf dem selben Rechner - nur ein anderes Delphi-Programm .
Und bzgl. der unterschiedlichen Implementierungen: die Auswirkung des Problems sind die gleichen (das Programm "hängt") - aber zumindest das interne Verhalten ist doch etwas unterschiedlich.
Im CopyFileW-Fall wird wohl noch die Kopie der Datei angelegt (hier kommt noch die Log-Ausgabe nach dem Aufruf) und erst danach hängt das Programm in einem "WaitForCriticalSection"-Aufruf.
Im IFileOperation-Fall hängt es direkt im API-Aufruf (wobei es dort auch so aussieht, als ob da intern der WaitForCriticalSection-Aufruf gemacht wird).
Ich sehe nur nicht, auf _was_ da gewartet wird bzw. mit welchem System-Objekt die CriticalSection verknüpft ist...