EOSError - Systemfehler. Code: 1400.

[Martin Elsner]

Hallo erstmal,

ich bekomme aus einer Anwendung jetzt zum zweiten Mal die Exception "EOSError - Systemfehler. Code: 1400.
Invalid window handle". Leider ist das so nicht reproduzierbar, deswegen kann ich da nichts debuggen. Das Programm beinhaltet mehrere Threads, die aber überhaupt nichts mit Window handles zu tun haben sollten. Eigentlich sollten alle Exceptions abgefangen werden, aber dieser seltsame Fehler taucht an irgendeiner unerwarteten Stelle auf.

Hat jemand eine Idee, woher dieser Fehler kommen kann?

Danke für jeden Hinweis!

Gruß, Martin

[Hagen Reddmann]

Dieser Fehler wird meistens bei der Erzeugung eines Fensterhandles ausgelösst. Also meistens in der TWinControl.CreateWnd Methode. Es ist KEIN OS-Fehler, sondern ein durch die Delphi VCL erzeugter Fehler der darauf hinweisst das CreateWindow() = 0 zurücklieferte.<br>

Sollten deine Threads z.B. über .Synchonize() arbeiten so wird intern dazu ein Fensterhandle benötigt. Vielleicht kommt genau da dieser Fehler her.<br> Der Exceptionframe in Threads wiederum ist abhängig von der Delphiversion nicht ganz korrekt und fängt diese Exception nicht ab. Du solltest also im TThread.Execute() einen eigenen Exceptionframe reinbauen, etwa so

<pre>

procedure TMyThread.Execute;
begin
try
while not Terminated do
begin
.. dein code hier
end;
except
end;
end;

</pre>

Gruß Hage

[Martin Elsner]

Hallo Hagen,

danke schonmal für Deine Antwort. Die Exceptions in Execute fange ich schon ab, weil ich selber so meine Erfahrungen gemacht habe ...

Ich benutze höchstens critical sections, passiert da etwas ähnliches? Die Threads haben eigentlich gar keine Oberfläche und kommunizieren nur über Variablen mit dem Hauptthread.
Ich hatte schonmal die Idee, dass der Fehler vielleicht beim Erzeugen des Fehlerfenster für eine schwerwiegende Exception auftauchen könnte, ist aber auch nur geraten.

Gruß, Marti

[Hagen Reddmann]

An den CS's kann es eigentlich nicht liegen, die werden vollständig durch das Kernel implementiert und haben so keinerlei Bezug auf das User API, sprich Fensterhandles.<br>

Aber du sagst das innerhalb der Threads über Variablen mit der Hauptanwendung kommuniziert wird. Ich nehme an das machst du nciht über .Synchronize() sondern blockst per CS ?<br>

Hast du schon mal die Threads deaktiviert und versucht den Fehler nur über die Hauptanwendung zu reproduzieren ??<br>
Ich bekam diese Fehlermeldung immer nur dann wenn ich zu viele Fensterhandles gleichzeitig erzeugt hatte.<br>
Andere Möglichkeiten wären:
<li>Fremdkomponenten
<li>bestimmte COM Port Komponenten arbeiten mit Fensterhandles
<li>TTimer
<li>verschieden TCP/IP, z.b. Indy, arbeiten mit Fenstern als Kommunikationshandler
<li>DDE Connection ?!
<li>COM/ActiveX Controls die z.B. OLE zu Word usw. aufbauen, d.h. diese Exception könnte von diesen externen Anwednungen stammen

Gruß Hage

[Martin Elsner]

Leider kann ich den Fehler so nicht reproduzieren, er tritt beim Kunden in unregelmäßigen Abständen auf, aber nicht bei mir ...

Der Kommunikation läuft so, dass der Haupthread nur auf die Variablen zugreift, wenn der einzelne Thread suspended ist (in den Threads steht in Execute ein Block
repeat
...
suspend;
until ProgramEnd;
und die Threads werden mit Resume wieder gestartet)

Zu den anderen Möglichkeiten kann ich nur sagen:
<ul>
<li> Timer gibt es, aber sie allein werden doch wohl kein Problem darstellen?
<li> Indy-Komponenten gibt es (IdTCPClient in den Einzelthreads, IdTCPServer im Haupthread). Dabei werden auch Nachrichten zwischen Einzelthreads und Hauptthread ausgetauscht.
<li> der Rest scheidet aus
</ul>

Gruß Marti

[Hagen Reddmann]

Bist Du dir sicher das es nicht an den Indy/Timer liegt ? Vieleicht liegt es ja garnicht an deinen Threads !<br>
Man müsste nun einen Kunden finden der als "Betatester" auftritt und mit einer Anwendung arbeiten will die zusätzliche Debuginformationen erzeugt.<br>

Gruß Hage

[Martin Elsner]

Sicher bin ich mir nicht, aber es gab ja Betatests, und bei diesen Tests trat der Fehler nie auf!
Deswegen sehe ich im Moment nur eine Möglichkeit darin, mehr über diesen Fehler und mögliche Ursachen herauszufinden.
Wenn es denn an Timer oder Indy liegen sollte - woran dann genau? Normalerweise funktionieren die Objekte, es scheint also nur irgendwelche seltenen Situationen zu geben, in denen etwas schiefgeht. Irgendwie wird ja an irgendeiner Stelle ein falsches window handle übergeben, sollte das ein Fehler in Delphi sein? Oder bleibt als einzige Möglichkeit das Überschreiben eines fremden Speicherbereichs?

Gruß Marti

[H. Leesch]

Hallo,

welche Indy Version ?
hatte glaube das gleiche Prob...
in OnConnect oder OnDisconnect vom Server
wenn da z.B. "Label1.Caption := 'Connect'" oder
so was, da OnConnect oder Dis.. ja ein anderer Thread ist musste ich das so machen AThread...Syncronice also die sync Func vom neuen Thread oder PostMessage,
oder benutzt du SendMessage um nachrichten an Threads loszuwerden?

H.Leesc

[Martin Elsner]

Hallo,

> welche Indy Version ?

6.0

> hatte glaube das gleiche Prob... in OnConnect oder OnDisconnect vom Server ...

Habe gerade mal geprüft, aber in OnConnect und OnDisconnect scheint alles durch Critical Sections abgesichert zu werden, werde der Sache aber nochmal nachgehen.
Die Kommunikation zwischen den Threads läuft bei mir über einfache Variablen, auf die ich von außen nur zugreife, wenn der Thread suspended ist. Allerdings gibt es eine Verbindung zwischen einem Indy-Server im Hauptthread und einem Indy-Client im Nebenthread, möglicherweise knallt es da in manchen Fällen.

Gruß Marti