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