Programm wird einfach geschlossen - Kernelbase.DLL

[Uwe Raabe]

Wenn es wirklich am Fast-User-Switching liegt, wird das nicht einfach zu debuggen sein. Vielleicht helfen aber die Hinweise von MS zu diesem Thema das Problem einzugrenzen. Insbesondere da die Anwendung noch aus der Delphi 5 Ära stammt, können da noch gravierende Lücken vorliegen.

[EWeiss]

Zitat von Uwe Raabe:

Wenn es wirklich am Fast-User-Switching liegt, wird das nicht einfach zu debuggen sein.

Ich bin ja dumm destotrotz eine Frage noch.
Wenn dem so ist kann man diesen dann nicht mit seiner Anwendung selbst Ausführen\Emulieren oder was sonst noch.
Dann sollte es doch einfach sein das Problem zu lokalisieren.

Keine Ahnung was Fast-User-Switching bewirkt.

gruss

[Uwe Raabe]

Zitat von EWeiss:

Wenn dem so ist kann man diesen dann nicht mit seiner Anwendung selbst Ausführen\Emulieren oder was sonst noch.
Dann sollte es doch einfach sein das Problem zu lokalisieren.

Keine Ahnung was Fast-User-Switching bewirkt.

Beim Fast-User-Switch wird ein anderer Benutzer angemeldet ohne den aktuellen Benutzer abzumelden. Normalerweise stellt das für laufende Programme kein Problem dar. Allerdings sind gerade alte Programme auf dieses Szenario oft nicht vorbereitet.

Was das Debuggen betrifft, hat man halt das Problem, daß mit dem User-Switch einem auch die IDE unter den Fingern weggezogen wird. Eventuell könnte man von einem anderen System mit Remote-Debugging noch was erreichen.

[EWeiss]

@Uwe.. Danke für die Infos.

gruss

[hoika]

Hallo,
hier hilft doch nur ein extensives Loggen (Textdatei oder Netzwerk).

[jaenicke]

Ich bin mir da nicht so sicher, ob Logging helfen würde. Denn wenn das selbst von MadExcept nicht gefunden wird...
Deshalb wäre das für mich das letzte Mittel angesichts des Aufwands.

Ich würde es einmal mit Eurekalog versuchen. Das hat bei uns mehr abgefangen.

Und dann macht es Sinn aus den Debuginformationen .dbg Dateien für Windows zu erstellen, damit Windows auch richtige Stacktraces schreiben kann. Dazu sollten Dumps für Crashes aktiviert werden, damit Stacktraces und weitere Informationen auch geschrieben werden:
https://docs.microsoft.com/en-us/win...ser-mode-dumps
Zumindest solltest du so Speicheradressen bekommen, an denen du nachschauen kannst.

[OlafSt]

Vielen Dank für die vielen Anregungen und Ideen !

Um die gestellte Frage zu beantworten: Das Programm startet, liest ein paar Daten aus einer INI-Datei (TMemIniFile). Dann wird eine Verbindung zur Datenbank hergestellt und ein paar Fenster im Hintergrund werden erzeugt. Anschließend kommt der Login-Dialog, der auf eine Reaktion wartet. Etwa 7 Minuten später macht es ZAPP und die Anwendung ist weg.

Bitte nicht mosern, das man die Fenster auch nach dem Login-Dialog erzeugen könnte... Ich hab den Mist nicht verzapft, bin erst seit eineinhalb Jahren damit beschäftigt, den z.T. heftigen Unsinn da geradezubiegen...

Ob es wirklich am Fast-User-Switching liegt, wissen wir noch nicht. Aber es ist uns aufgefallen, das dies im Eventlog anhand des Timestamps quasi direkt vor dem Stack Overrun unserer Anwendung erfolgt. Remote Debugging ist etwas kompliziert, denn D2007 hat sowas noch nicht. Aber ein Blick auf Eurekalog kann nicht schaden und auch den Weg der DBG-Files werden wir versuchen zu verfolgen. Ist nur die Frage, wie man D2007 dazu bringt, sowas zu erzeugen ?