Seltsamer unreproduzierbarer Bug

[mael]

Hallo,

Ein Nutzer hat einen seltsamen Bug den ich bisher nur auf seinem System reproduzieren kann. Ungünstigerweise funktioniert Remote-Debugging nicht, die Dateien werden übertragen, aber dann bricht die Session ab, vielleicht ein Latzenz-Problem. (Gibt es da einen Schalter/Option?)

Madexcept erkennt keine Exception, und Logging jeder Funktion (meines eigenen Codes) bringt auch keine schlüssigen Ergebnisse. Alle Funktionen werden alle fehlerfrei ausgeführt (enter und exit), aber danach ist plötzlich Schluss. Muss also wohl in einer Systemfunktion passieren, vielleicht verzögert ausgelöst.

Plötzlich beendet sich HxD einfach, ohne weitere Meldungen, auch nicht von Windows.

Im der Windows-Ereignissanzeige gibt es einen Eintrag, Exception 0x409, raised in ntdll.dll, aber sonst nichts.

Sein Windows-System ist x64 Windows 10.

Hat jemand eine Idee wie man den Bug finden kann?

[Jasocul]

Leider schreibst du nichts, in welcher Situation das beim Anwender passiert.
Als ich gesehen habe, dass es um HxD geht, kam mir sofort die Idee, dass es am AV-Programm liegen kann. Hast du das schon geprüft? Und bitte nicht den MS-Defender vergessen.
Wenn es daran nicht liegt, könnte ich mir auch vorstellen, dass die Datei, die der Anwender ansehen will, defekt ist, bzw. die Platte an der Stelle einen Fehler hat.

Ich habe auch noch das Internet bemüht und bin auf dies hier gestoßen. Vielleicht hilft das ja weiter.

[TiGü]

Kann der Kunde das zuverlässig reproduzieren und dir das Log vom Sysinternals Process Monitor, gefiltert auf HxD.exe, schicken?

[mael]

Es passiert direkt beim Start von HxD, ohne irgendeine Datei zu öffnen, auch mit der portablen Version, also ohne dass am System was verändert wurde.

Ich vermute auch ein Antivirenprogram, oder irgendein Gameschutz, aber konnte nichts finden.

Ich hatte Zugriff auf das System des Nutzers, da er mir erlaubt hat es per TeamViewer zu testen. Bin aber etwas ratlos, außer schrittweise alles auszukommentieren.

Process Monitor versuche ich mal. Gibt es sowas ähnliches auch für Windows Botschaften WM_*?

P.S.: Das Nutzersystem ist auch nicht up-to-date, aber ich würde gerne den Bug finden (oder rausfinden ob es ein Problem mit dem System ist), bevor ich ein Update vorschlage und dieser Bug nicht mehr reproduzierbar ist (aber vielleicht sonst "still" trotzdem Probleme verursacht).

[mael]

Zitat von Jasocul:

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.