Programm wird einfach geschlossen - Kernelbase.DLL

[OlafSt]

Hallo Freunde,

da der andere Thread mit Kernelbase.DLL eine andere Richtung nimmt, mache ich mal einen neuen für mein Problem auf.

Ich habe hier eine ur-ur-alte Anwendung, die ich von Delphi 5 auf Delphi 2007 "gehoben" habe. Diese zeigt nun seit etwa zwei Wochen ein seltsames Verhalten.

Man startet die Anwendung und läßt sie einfach stehen (egal wo, egal welches Fenster geöffnet ist, selbst der vorgeschaltete Login-Dialog genügt). Nach etwa 7 Minuten verschwindet die Anwendung ohne jede Meldung. Sie wird knallhart aus dem Speicher entfernt, im Taskmanager ist anschließend keine Spur mehr von ihr zu finden.

Im Eventlog findet man einen Eintrag, das die Anwendung wegen eines Fehlers in Kernelbase.DLL geschlossen wurde. Errorcode ist 0xC0000409, Stack Buffer Overrun.

MadExcept ist drin und aktiviert und reagiert überhaupt nicht, weshalb ich die dringende Vermutung habe, das es nicht der Delphi-Code ist. Das schließt Timer-Events und ähnliches aus. Wir haben aber bemerkt, das quasi direkt vor dem Rauswurf unserer Anwendung ein Fast-User-Switch setens Windows 10 vorliegt, können uns da aber keinen rechten Reim drauf machen.

Jemand eine Idee, wo wir ansetzen könnten ?

[DP-Maintenance]

Dieses Thema wurde am "13. May 2019, 10:22 Uhr" von "mkinzler" aus dem Forum "Algorithmen, Datenstrukturen und Klassendesign" in das Forum "Win32/Win64 API (native code)" verschoben.

[EWeiss]

Zitat:

Im Eventlog

welches?

Zitat:

Jemand eine Idee, wo wir ansetzen könnten ?

Das ist immer schwierig ohne Quelltext als außenstehender zu verstehen bzw. Tip's zu geben.

Ich würde bei den Windows Protokollen ansetzen denn wenn es ein Fehler seitens Windows ist müsste da diesbezüglich etwas stehen.
Verwaltung\Windows Protokolle\Anwendungen

Sonst fällt mir auch nichts ein..
Vielleicht noch die Anwendung wenn möglich hier mal hochladen so das man es selbst mal testen kann.
So kann man zumindest ausschließen wenn es woanders läuft das es an Windows nicht liegt.

gruss

[OlafSt]

Danke fürs verschieben ;)

Der Eintrag erfolgt in Windows-Protokolle/Anwendung und sieht so aus:

Name der fehlerhaften Anwendung: BlaBla.exe, Version: 2018.1.1.124, Zeitstempel: 0x2a425e19
Name des fehlerhaften Moduls: KERNELBASE.dll, Version: 10.0.17134.556, Zeitstempel: 0xadca2670
Ausnahmecode: 0xc0000409
Fehleroffset: 0x001118a2
ID des fehlerhaften Prozesses: 0x20ac
Startzeit der fehlerhaften Anwendung: 0x01d5095ee242d808
Pfad der fehlerhaften Anwendung: C:\Bla\BlaBla.exe
Pfad des fehlerhaften Moduls: C:\Windows\System32\KERNELBASE.dll
Berichtskennung: a72c09d0-71e9-466b-a3d4-91a3f9465631
Vollständiger Name des fehlerhaften Pakets:
Anwendungs-ID, die relativ zum fehlerhaften Paket ist:

Die Anwendung hochladen wird schwierig. Das sind etwa 550 Formulare und dazu gehören noch etwa 120 DLLs und allein die ganzen Komponenten in Delphi zu installieren wird sich keiner antun wollen :D Gute 300MB Sourcecode, wird also nicht so recht was ;)

[EWeiss]

Zitat:

Die Anwendung hochladen wird schwierig.

Ohne irgendwelche Möglichkeiten es selbst zu testen, sorry dann kann ich nicht mehr dazu sagen..
Da hilft wohl nur debuggen, debuggen, debuggen..

Anwendung im Debugmodus starten und warten bis sie sich verabschiedet. Verabschiedet sich die IDE dann liegts wohl an Windows.
Nebenbei hatte ein ähnliches Problem was auch einen Kernelbase Error ausgelöst hat.

Meistens liegt es an irgendwelchen Handles die nicht korrekt freigegeben wurden. (Bei mir war es das Icon Handle)

PS:
Versuche doch mal das CrashDump zu analysieren.. die werden ja nicht umsonst abgelegt.
C:\Users\xxx\AppData\Local\CrashDumps

gruss

[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:

Zitat von Uwe Raabe (Beitrag 1432061)

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

[Dalai]

Zitat:

Zitat von OlafSt (Beitrag 1432050)

Wir haben aber bemerkt, das quasi direkt vor dem Rauswurf unserer Anwendung ein Fast-User-Switch setens Windows 10 vorliegt, können uns da aber keinen rechten Reim drauf machen.

Was heißt das genau? Wie stellt sich das dar bzw. wie genau ist der Ablauf?

Sind alle Compiler-Warnungen bearbeitet? Fehler im Windows werden zwar nach meinem Eindruck häufiger, aber trotzdem glaube ich, dass der Fehler in der Anwendung liegt. Was macht denn die Anwendung, bis sie zum Login-Form gelangt und während selbige sichtbar ist?

Grüße
Dalai

[Uwe Raabe]

Zitat:

Zitat von EWeiss (Beitrag 1432120)

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 ?

[TiGü]

Zitat:

Zitat von OlafSt (Beitrag 1432193)

Remote Debugging ist etwas kompliziert, denn D2007 hat sowas noch nicht.

Ohne jetzt Delphi 2007 direkt vor mir zu haben, aber wenn mich meine Erinnerung nicht täuscht, dann gab es das damals schon.


EDIT: Ja, das gab es damals schon
http://docs.embarcadero.com/products...oteov_xml.html

[Delphi.Narium]

Ging schon mindestens seit Delphi 7.

Eine Anleitung dazu oder zumindest ein hilfreicher Text? Remote Debugger

[Dalai]

Zitat:

Zitat von OlafSt (Beitrag 1432193)

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.

Und was machen die erzeugten Forms in dieser Zeit? Irgendein Timer aktiv? Reagieren sie auf Windows Messages?

Eine Anwendung, die nichts tut, sollte nicht abstürzen. Daher denke ich, dass die Anwendung irgendetwas tut. Denkbar ist z.B. die regelmäßige Anforderung von Speicher/Ressourcen (ohne Freigabe dieser), was irgendwann zur Erschöpfung irgendwelcher Ressourcen führt.

Zitat:

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.

Löst die Anwendung denn den Fast User Switch aus? Bisher habe ich deine Ausführungen so verstanden, dass nur zufällig zum gleichen Zeitpunkt zwei verschiedene Dinge - Beendigung der Anwendung und Fast User Switch - passieren.

Ist das Verhalten der Anwendung auf einem anderen System und/oder anderen Windows(-Version) nachvollziehbar?

Grüße
Dalai