Hast Du mit ausführlicher MAP-Datei kompiliert? Eventuell findest Du dort eine Adresse, die dem angegebenen Wert "ähnlich" ist, dann könnte der Fehler in der Nähe des dort angebenen Bereiches zu finden sein.
Nein, leider nicht - die Adressen in der MAP-Datei sind alle wesentlich niedriger (eher so, wie Dein Beispiel...)
Ich habe jetzt mal MadExcept mit Option "check for frozen main thread" mitlaufen lassen.
Nachdem dieser den Hänger feststellt, zeigt er mir folgenden Stack an:
Code:
7736FF74 +0044 ntdll.dll RtlEnterCriticalSection
4002FE37 +0007 rtl70.bpl Classes ThreadList.LockList
01984929 +015D vcl70.bpl Controls TWinControl.PaintControls
773A508B +004B ntdll.dll KiUserCallbackDispatcher
753A101A +000A win32u.dll NtUserPeekMessage
769FBB99 +0169 user32.dll PeekMessageW
75D4A0EE +003E shcore.dll # 161
75D49E73 +0013 shcore.dll ShCreateThread
und davor kommt meine letzte Code-Zeile, in der erfolgt der Wrapper-Aufruf von
IFIleOperation.PerformOperations
Es sieht hier doch so aus, als ob er auf die Freigabe / den Zugriff auf eine gesperrte Ressource wartet?!
Wenn ich das ganze statt mit meine IFileOperation-Implementierung mit "CopyFileW" mache, sieht der MadExcept Call-Stack bei der Freeze-Erkennung folgendermaßen aus:
Code:
7736FF74 +0044 ntdll.dll RtlEnterCriticalSection
4002FE37 +0007 rtl70.bpl Classes ThreadList.LockList
01984929 +015D vcl70.bpl Controls TWinControl.PaintControls
773A508B +004B ntdll.dll KiUserCallbackDispatcher
769FBB99 +0169 user32.dll PeekMessageW
75286B21 +9E1 RPCRT4.dll NdrClientCall2
761A6C3A +000 combase.dll ObjectSublessClient32
76139579 +0B9 combase.dll CoCreateInstance
3788EF44 +2F4 CRPE32.dll PEOpenEngineEx
378941A5 +0B5 CRPE32.dll PEOpenEngine
die weiteren Aufrufe sind in meinem Code bzw. im "Crystal Reports"-Wrapper beim Setzen von Reportdaten... (also nicht beim Kopieren!)
Auch hier wieder das Warten auf den Zugriff auf eine Ressource...
(das kann aber natürlich auch einfach ein anderer und nicht der eigentliche Problemthread sein...
)