Ich habe auch noch das Internet bemüht und bin auf
dies hier gestoßen. Vielleicht hilft das ja weiter.
"Fail Fast
Exception" erklärt warum kein
Exception Handler dies auffangen konnte, und deswegen madexcept oder Logging nicht funktioniert. Siehe auch:
RaiseFailFastException WinAPI
Danke, wird nützlich sein in Zukunft.
Es war ein Pointer-Truncation-Bug. Das wesentliche Problem war dass auf dem Nutzer-System VirtualAlloc Adressen aus dem oberen Bereich des Adressraums liefert, auch wenn der Prozess gerade erst gestartet wurde.
Seltsamerweise obwohl auf meinem Testsystem (VM mit Win10 x64) als auch dem "Bug"system (Win10 x64) die gleichen ASLR-Optionen ausgewählt sind. Deaktiviert man allerdings ASLR auf dem "Bug"system liefert VirtualAlloc wieder Adressen unter 4GiB.
In eigenem Code, der Window Procedures hooked, wird ein Pointer der von System.Classes.MakeObjectInstance zurückgeliefert wird zu DWORD anstatt LONG_PTR gecastet (war damals vor Win64 so in den Delphi-Quellen, und habe ich beim anpassen an x64 übersehen).
Ich kann das Problem reproduzieren wenn ich die unteren 4GiB reserviere, direkt beim Prozessstart, und somit VirtualAlloc zwinge Adressen > 4GiB zu liefern.
Unter Win8.1 kriege ich eine
Exception die direkt auf den Fehler zeigt (wenn ich die unteren 4GiB reserviere), unter Win10 nicht. Hier musste ich mit minidumps (die von WER erzeugt werden) und Visual Studio einen Stacktrace finden und mit Delphi's CPU-View dann die Adressen aus diesem Trace in Zeileninformation übersetzen.
Details wie ich den Fehler gefunden habe hier:
http://forum.madshi.net/viewtopic.ph...t=28825#p53528
Bleibt die Frage welche Optionen unter Windows dieses Verhalten -- VirtualAlloc gibt hohe Adressen zurück -- bewirken.