Fehler 0x0eedfade in Kernelbase.dll

[Klaus01]

.. hast Du die Möglichkeit MadExcept einzusetzen?

Grüße
Klaus

[OlafSt]

Wir haben das gleiche Phänomen hier mit einer D2007-Anwendung. Diese arbeitet aber sehr stark mit einem SQL-Server und produziert ab und zu eine Excel- oder PDF-Datei. Nach etwa 7 Minuten ohne Bedienung wird das Programm ohne jede Vorwarnung einfach aus dem Speicher geworfen, als würde man es mit dem Taskmanager abschießen.

MadExcept ist chancenlos, da es sich hier sehr wahrscheinlich um ein Windows-Problem handelt - der Eintrag im Eventlog zeigt das ja schon auf. Wir tippen auf ein Update seitens Windows, das nun plötzlich Stress macht. Wir konnten es nur noch nicht identifizieren.

[hoika]

Hallo,
das ist aber nicht das gleiche Phänomen.
Weil der TE immerhin eine Exception bekommt. Hier würde in der Tat MadExcept was bringen (siehe Klaus01).
Ich würde MadExcept einfach mit einem neuen leeren Projekt, wo z.B. eine "Division durch 0"-Exception provoziert wird.

Die Nutzung von MadExcept ist ja einfach.
- in Projekt-Optionen MadExcept einstellen (ein Haken "enable MadExcept")
in der DPR werden jatzt an ersteer Stelle diverse MadExcept-Unis eingebunden
(haken wieder raus und die Units sind wieder weg)
- beiden Compilereinstellungen alles rein was geht (Laufzeitfehler, Debug-Informationen ...)
Optimierung sollte so stehen bleiben wie im Release
- bei den Linkereinstellungen TD32 und externe Debugsymbole

Wenn die Exe jetzt 3mal so gross ist, war alles richtig.

Ein Test wäre

{$IFDEF MADEXCEPT}
i,j: Integer;
i := StrToInt('0');
j := 10 div i;
{ENDIF}
Das erzeugt die Div/0-Exception.

Ergebnis ist ein MadExcept-Dialog, unter Stack-Trace findet man die genaue Ziele, die die Exception verursacht, incl. Unit-/Prozedurname/Zeilennummer.

Einfach mal ausprobieren!

[Sumafu]

MadExcept sieht sehr vielversprechend aus, allerdings kostet das bei kommerzieller Nutzung was. Und ein "vielleicht könnte es helfen" wird dem Chef als Begründung vermutlich nicht reichen, zumal wir das nur für diesen einen Fall bräuchten, und sonst nicht.

[EWeiss]

Zitat:

denn ich bin mir selbst nicht sicher, was überhaupt der Fehler ist.

Traurig.

Zitat:

Am Ende wird aufgeräumt

Möchte ich bezweifeln denn es kommt nicht umsonst die Fehlermeldung EOutOfResources.. falls du die Meldung nicht kennst bzw. weist was es bedeutet hier nähere Informationen

Zitat:

MadExcept ist chancenlos, da es sich hier sehr wahrscheinlich um ein Windows-Problem handelt

Auch das möchte ich sehr bezweifeln denn die Fehlermeldung ist doch eindeutig.

Zitat:

MadExcept sieht sehr vielversprechend aus... Und ein "vielleicht könnte es helfen" wird dem Chef als Begründung vermutlich nicht reichen

Ohne es mal versucht zu haben und der Verwendung unserer altbewährten
wird dir hier wohl niemand weiter helfen können.

Ich würde überall da wo Handles erstellt werden einen Breakpoint setzen und beim beenden bzw. neu Erzeugung vorher prüfen ob das letzte freigegeben wurde.
Ansonsten kann man nur Raten. Von einem leeren Blatt Papier kann man nun mal nicht lesen.

gruss

[Sumafu]

Zitat von EWeiss:

Zitat:

denn ich bin mir selbst nicht sicher, was überhaupt der Fehler ist.

Traurig.

Zitat:

Am Ende wird aufgeräumt

Möchte ich bezweifeln denn es kommt nicht umsonst die Fehlermeldung EOutOfResources.. falls du die Meldung nicht kennst bzw. weist was es bedeutet hier nähere Informationen

Ich weiß sehr wohl was eine EOutOfRessource Fehlermeldung bedeutet. Allerdings weiß ich auch, dass diese Fehlermeldung in Delphi für alle möglichen Fehler zweckentfremdet wird. Klar KANN es ein Fehler beim Allokieren eine Handles sein, muss es aber nicht.
Eine weitere Analyse hat ergeben, dass der Fehler tatsächlich dann auftritt, wenn Delphi versucht, eine Form zu erstellen (Application.CreateForm). Aber nichts desto trotz ist das nicht ein typischer EoutOfResources Fehler, da der Rechner definitiv genügend Resourcen hat. Alle Gründe, aus denen "EoutOfResources" offiziell kommen sollte, treffen meiner Analyse nach nicht zu. Ich habe dahingehend auch schon diverse Tests gemacht mit verschiedenen Registry Schaltern, die Resourcen, Handles und GDI betreffen, alles ohne Erfolg.

[hoika]

Hallo,
EOutOfResources ist eine Delphi-Exception.
MadExcept müsste zumindestens die Zeile finden,
die diese Exception verursacht, also wahrscheinlich das FindFirst (weil der interne Speicher doch irgendwie nicht freigegeben wurde).

Zu langsam.

[Sumafu]

Zitat von hoika:

Hallo,
EOutOfResources ist eine Delphi-Exception.
MadExcept müsste zumindestens die Zeile finden,
die diese Exception verursacht, also wahrscheinlich das FindFirst (weil der interne Speicher doch irgendwie nicht freigegeben wurde).

Zu langsam.

Da muss ich dann zugeben, dass meine Vermutung, dass es an der Prüfroutine liegt, höchstwahrscheinlich falsch war (der Fall beschäftigt mich jetzt schon so lange, dass schon mal Informationen im Hirn verloren gehen).
Es ist die Startroutine, wenn Delphi versucht mit Application.CreateForm ein Fenster zu erstellen. Zumindest wird das FormCreate Event nicht mehr ausgeführt. Das Fenster ist ziemlich spartanisch und hat kaum GDI-Objekte, daran liegt es also nicht. Siehe auch meine letzte Antwort.

[EWeiss]

Zitat von hoika:

Hallo,
EOutOfResources ist eine Delphi-Exception.
MadExcept müsste zumindestens die Zeile finden,
die diese Exception verursacht, also wahrscheinlich das FindFirst (weil der interne Speicher doch irgendwie nicht freigegeben wurde).

Zu langsam.

Er will es nicht verwenden scheint dem Boss zu teuer von daher ist ein jeglicher weitere Versuch Helfen zu wollen sinnlos.
Deshalb bin ich auch wieder raus.
Viel glück hoffe du findest den Fehler noch.

PS:

Zitat:

da der Rechner definitiv genügend Resourcen hat

Was haben die Resourcen des Rechners mit dem nicht freigeben von Handles zu tun? Gar nichts.
Definiere doch einfach mal was bei dir ein typischer EoutOfResource Fehler ist. Dann hast du schon halb gewonnen.

Nun gut wie dem auch sei.

gruss