Fehlermeldung beim Herunterfahren

[CodeX]

Ich habe hier eine etwas komplexere Delphi-Anwendung, die bei ein paar ganz wenigen Anwendern beim Herunterfahren von Windows eine Fehlermeldung produziert und damit den Herunterfahrvorgang anhält.

Die Fehlermeldung lautet:
Die Anwendung in 0x00123456 verweist auf Speicher 0x01234567. Der Vorgang read konnte nicht im Speicher durchgeführt werden.
Klicken Sie auf „OK“, um das Programm zu beenden.

Nun ist es so, dass ich den Fehler bei keinem der vielen Versuche reproduzieren konnte.
Der Fehler tritt bei den betroffenen Personen anscheinend bei fast jedem Herunterfahren auf; jedoch nie beim normalen Beenden der Anwendung.
Die Anwendung läuft standardmäßig im Tray, wird vom Anwender vor dem Herunterfahren also so gut wie nie manuell beendet.
Es scheinen nur Windows 7 Anwender betroffen zu sein.
Ich habe versucht, den Fehler mit madExcept zu lokalisieren, jedoch tritt der Fehler bei Verwendung von madExcept nicht mehr auf! (nein, es ist keine Lösung, madExcept dauerhaft drin zu lassen).

Ich kann mir nicht erklären, womit der Fehler zusammenhängen könnte. Ggf. wird irgendeine Ressource beim Herunterfahren unerwartet freigegeben, wo die Anwendung aber trotzdem noch darauf zugreift!?

Nun bin ich leider ziemlich ratlos, was ich noch tun kann. Bei den betroffenen Anwendern kann ich nicht debuggen. Besteht irgendeine andere Möglichkeit, etwas mehr Details zur Fehlermeldung zu erhalten, die weiterhelfen? Oder lässt sich notfalls irgendein Workaround implementieren, dass beim Beenden der Anwendung grundsätzlich keine Fehler mehr geworfen werden? Ich weiß nicht, wo ich den

Delphi-Quellcode:

try except

Block überhaupt drumherum machen könnte. Das würde zwar nicht die Ursache beheben, aber in Anbetracht der Tatsache, dass dies wohl irgendeine Sonderkonstellation ist, die nur ganz wenige Anwender betrifft, vielleicht eine gangbare Lösung.

[TiGü]

Zitat:

Zitat von CodeX (Beitrag 1298006)

Oder lässt sich notfalls irgendein Workaround implementieren, dass beim Beenden der Anwendung grundsätzlich keine Fehler mehr geworfen werden? Ich weiß nicht, wo ich den

Delphi-Quellcode:

try except

Block überhaupt drumherum machen könnte. Das würde zwar nicht die Ursache beheben, aber in Anbetracht der Tatsache, dass dies wohl irgendeine Sonderkonstellation ist, die nur ganz wenige Anwender betrifft, vielleicht eine gangbare Lösung.

TApplication.OnException
Hier ranhängen und ggf. erden?!

[jobo]

Tja, was passiert denn beim Runterfahren?

• Programme schreiben Konfiguration/Status in die Registry oder Datei (Netzwerk)
• melden sich irgendwo ab
• ..

Da Du extra WIN7 schreibst:
Ist es eigentlich (historisch) eine XP Anwendung?
UAC Verhalten geprüft?
registry 64 / 32 Zugriff unter Kontrolle?

Da Du nicht schreibst, was das Programm eigentlich macht und welche Ressourcen es nutzt, ist es ziemlich spekulativ in der Richtung weitere Vorschläge zu machen.

Aber die genannten Punkte könnte man abklopfen beim Versuch der Fehlerreproduktion. Ein Logging Ansatz ist natürlich nie verkehrt, besonders, wenn der Fehler reproduzierbar ist.

[CodeX]

Zitat:

Zitat von jobo (Beitrag 1298031)

Tja, was passiert denn beim Runterfahren?

Beim Beenden der Anwendung werden ein paar Aktionen durchgeführt (z.B. Event-Handler abgemeldet, Objekte freigegeben, etc.), aber das habe ich schon mit einer Log-Ausgabe schon ausgelotet. Die eigenen Code-Blöcke laufen alle problemlos durch. Der Fehler tritt erst danach auf, also in keinem eigenen Code mehr.

Zitat:

Zitat von jobo (Beitrag 1298031)

Da Du extra WIN7 schreibst:
Ist es eigentlich (historisch) eine XP Anwendung?
UAC Verhalten geprüft?
registry 64 / 32 Zugriff unter Kontrolle?

Ja, alles schon längst für 7/8/10 und 32/64 angepasst. Ich kenne auch keinen Fall, wo dieser Fehler mit Windows 8 (oder XP) auftritt. Vielleicht ist das auch nur Zufall. Ich habe 7 nur deshalb erwähnt, falls irgendjemand mal ein ähnliches Problem hatte.

Zitat:

Zitat von TiGü (Beitrag 1298028)

TApplication.OnException
Hier ranhängen und ggf. erden?!

Da habe ich irgendwie überhaupt nicht dran gedacht, weil ich Exceptions normalerweise nur lokal behandle. Danke! Das wird wohl der nächste Ansatzpunkt sein. Muss mal schauen, ob ich der Exception damit etwas mehr Informationen entlocken kann. Wenn ich die Ursache nicht finde, sollte es damit aber immerhin möglich sein, Exceptions beim Herunterfahren zu unterdrücken (zuvor per WM_QUERYENDSESSION erkennen).

Bin gerne auch noch für andere Vorschläge offen!