COM-Objekte innerhalb von Threads

[CalganX]

Hi,
der ganze OLE/COM-Kram treibt mich gerade zum Wahnsinn.

Ich habe einen Thread, der im Execute Folgendes stehen hat:

Delphi-Quellcode:

  CoInitializeEx(nil, COINIT_MULTITHREADED);
  TunesApp := CoiTunesApp.Create;
  try
    repeat
      {Tue was mit dem TunesApp-Interface}
    until false;
  finally
    TunesApp := nil;
    CoUninitialize;
  end;

Jetzt fliegt mir irgendwann eine EOleSysError-Exception (Erste Gelegenheit für Exception bei $7C812A5B. Exception-Klasse EOleSysError mit Meldung 'Starten des Servers fehlgeschlagen'. Prozess InfoTunes.exe (1708)) an den Kopf, die an folgender Stelle geraiset wird:

Delphi-Quellcode:

class function CoiTunesApp.Create: IiTunes;
begin
  Result := CreateComObject(CLASS_iTunesApp) as IiTunes;
end;

Durch das unmoegliche Debugging von Threads kann ich absolut nicht einschaetzen, warum das alles so passiert und wann genau es zu dieser Exception kommt. Ich vermute, dass der COM-Server ist gar nicht mag, dass in jedem Thread eine neue Referenz erzeugt werden soll.

Weiss jemand, woran das liegen koennte und wie man das Problem loest?

Bin fuer jeden Vorschlag dankbar. Das treibt mich schon den ganzen Tag in den Wahnsinn.
Chris

[Bernhard Geyer]

Du meinst du tust permanent diese Schleife ablaufen lassen?
Also entweder hat das ITunes-Interface irgendeine Quit/Exit-Methode die man Aufrufen muß bevor man das Interface freigibt oder ITunes hat Speicherlücken die vielen Anforderungen irgendeine Ressourcen (GDI, FileHandels, ...) volllaufen läuft.

Für Fall a, einfach dieses Quit/Exit aufrufen.
Für Fall b, Interface "cachen" und nicht permanent anfordern/freigeben oder auf fehlerbereinigte Version von ITunes warten.

[CalganX]

Hi Bernhard,

Zitat:

Zitat von Bernhard Geyer

Für Fall a, einfach dieses Quit/Exit aufrufen.

Ein Quit existiert, hat aber nicht geholfen. Wie es scheint kommt er nichtmal bis dahin. Es gibt schon beim ersten Versuch des CoiTunesApp.Create ein Problem. Genauer gesagt bleibt er erstmal sehr lange in dieser Methode hängen und spuckt nach einiger Zeit den Fehler aus.

Zitat:

Für Fall b, Interface "cachen" und nicht permanent anfordern/freigeben oder auf fehlerbereinigte Version von ITunes warten.

Habe ich jetzt auch versucht: im Dienst-Modul, wo der erste Thread erzeugt wird, wird eine Instanz auf das Interface übergeben. Die wird dann bis zum Ende mitgeschleppt. Aber selbst im Dienst kommt es zum Fehler, d.h. der Dienst startet nicht (da ich so schnell nicht den Debugger anwerfen kann, kann ich nicht sagen, ob es wieder zu einer Exception kommt, aber ich nehme es mal stark an).

Und wie gesagt funktioniert es problemlos, wenn ich keinen Dienst verwende, sondern eine einfache VCL-Anwendung. :?

Danke für deine Hilfe,
Chris

[sakura]

Rufe im Thread.Create CoInitialize(nil) auf und im Thread.Destroy CoUnitialize() auf.

Du kannst das natürlich auch an anderer Stelle tun, aber alle COM-Aufrufe und Objekte müssen zwischen Init und Uninit stattfinden.

...:cat:...

[CalganX]

Hi,
habe ich bereits drin. Habe es jetzt korrigiert und in den Service geschrieben:

Delphi-Quellcode:

procedure TInfoTunesService.ServiceCreate(Sender: TObject);
begin
  CoInitialize(nil);

  FTunesInstance := CoiTunesApp.Create;
end;

procedure TInfoTunesService.ServiceDestroy(Sender: TObject);
begin
  CoUninitialize;
end;

Der Service startet immer noch nicht, d.h. er lädt und lädt (in der Systemsteuerung => Dienste) und gibt nach einiger Zeit folgende Fehlermeldung aus:

Zitat:

Der Dienst "..." auf "Lokaler Computer" konnte nicht gestartet werden.

Fehler 1053: Der Dienst antwortete nicht rechtzeitig auf die Start- oder Steuerungsanforderung

Und wie gesagt vermute ich, dass da irgendwo noch eine EOleSysError-Exception geworfen wird, die aber nicht zum Vornschein kommt (da man Dienste ja nur schwer debuggen kann, kann ich hier auch nur vermuten, dass der Fehler immer noch existiert, nur an anderer Stelle).

Chris

[sakura]

Der Aufruf muss in jeden Thread, evtl. auch in den Service.

Wenn das alles nichts hilft, dan schaue Dir die madExcept Komponenten an - Tutorial in der Tut-Sparte. Für die private Nutzung sind die kostenlos.

...:cat:...

[CalganX]

Hi,
ah, eine Veränderung.
Nachdem ich nun das Erstellen des COM-Objekts in das OnStart verlagert habe und CoInitializeEx mit COINIT_MULTITHREADED verwende, startet der Dienst zumindest:

Delphi-Quellcode:

procedure TInfoTunesService.ServiceCreate(Sender: TObject);
begin
  CoInitializeEx(nil, COINIT_MULTITHREADED);
end;

procedure TInfoTunesService.ServiceDestroy(Sender: TObject);
begin
  CoUninitialize;
end;

procedure TInfoTunesService.ServiceStart(Sender: TService;
  var Started: Boolean);
begin
  FTunesInstance := CoiTunesApp.Create;

  FTCPServer := TTCPDaemon.Create;
  FTCPServer.FTunesInstance := FTunesInstance;
  Started := true;
end;

Jedoch bekomme ich jetzt folgende Nachricht von Windows beim Starten des Dienstes:

Zitat:

---------------------------
Dienste
---------------------------
Dienst "InfoTunes-Service" wurde auf "Lokaler Computer" gestartet und dann angehalten. Einige Dienste werden automatisch angehalten, wenn sie sich im Leerlauf befindet, wie z. B. Leistungsprotokoll- und Alarmdienste.
---------------------------
OK
---------------------------

Im OnExecute steht aber:

Delphi-Quellcode:

procedure TInfoTunesService.ServiceExecute(Sender: TService);
begin
  // Endlosschleife ftw
  while not Terminated do begin
    ServiceThread.ProcessRequests(True);
  end;
end;

Chris

Edit: madExcept ist ein guter Tipp, danke. Dummerweise funktioniert das nicht, weil ich im Moment mit Turbo Delphi entwickle und er das Paket nicht laden kann (ich nehme an, weil man bekanntlich keine Dritt-Anbieter-Komponenten installieren kann).

[CalganX]

:wall: Man sollte gelegentlich auch mal in's Eventlog gucken:

Zitat:

Ereignisinformationen: Service fehlgeschlagen bei start:Starten des Servers fehlgeschlagen, ClassID: {DC0C2640-1415-4644-875C-6F4D769839BA}.

Ich könnte... :cry:

Und es funktioniert immer noch problemlos ohne den Dienst, in einer normalen Anwendung. Das kann doch irgendwie nicht sein. :/

Chris

[OldGrumpy]

Ich hab iTunes bisher auch nur aus einer normalen Applikation heraus benutzt, vielleicht mag iTunes es nicht, wenn der Aufrufer kein Window hat? :) Was auch noch wichtig ist: iTunes reagiert sehr träge auf Aufrufe, Services dürfen wenn ich mich recht entsinne nur kleine Timeslices in Anspruch nehmen, meine Testapplikation hängt z.B. mehrere Sekunden (singlethreaded, Aufruf im Mainthread, dient nur zum Testen) bevor das CoCreate fertig ist. Sowas könnte bei einem Service fatal sein.

[CalganX]

Inzwischen vermute ich das auch. Dann muss ich wohl das ganze ein wenig umbasteln. :wall:

Na gut, danke für eure Hilfe und falls jemand doch ne Lösung kennt: immer her damit.

Chris

[shmia]

Ich würde das Interface für iTunes nur einmal erzeugen und zwar im Hauptthread.
Dann gibt man das Interface beim Erzeugen des Thread-Objekts "einfach" weiter.
Wenn 5 Threads das Interface benützen, dann steht RefCount auf 6 (5 Thread + die Referenz im Hauptthread).

Wenn Interface-Pointer von einem Thread an einen anderen Thread weitergereicht werden soll,
dann muss man Marshaling anwenden.
siehe: http://www.techvanguards.com/com/tut...s%20apartments

[CalganX]

Hi shmia,
wie soll denn der Pointer weitergegeben werden? Reicht ein einfaches zuweisen, wie ich es oben schon probiert habe? Das Marshalling versuche ich nachher.

Danke,
Chris

[shmia]

Zitat:

Zitat von CalganX

Das Marshalling versuche ich nachher.

Ohne Marshaling geht es nicht! Andernfalls erscheint der Fehler: "The application called an interface that was marshaled for a different thread"
Auf der obigen Webseite werden 2 Techniken gezeigt; die 2. Technik mit dem Hilfs-Interface IGlobalInterfaceTable
ist für deinen Zweck am Besten.

[CalganX]

Hi shmia,
ja, die Fehlermeldung hatte ich zwischen durch auch mal, aber wie gesagt, kommt jetzt im Moment der Fehler ja in erster Linie bei CoiTunesApp.Create und das passiert ja vor dem marshalen, oder?

Chris

[CalganX]

Hi,
hab es jetzt auch so implementiert, wie es auf der Seite gezeigt wird. Der Fehler beim Erzeugen ist immer noch da. Und wie gesagt nehme ich an, dass iTunes es nicht mag, wenn man es über Dienste ansteuert.

Chris

[OldGrumpy]

Falls es nur am fehlenden Fenster liegt, kannst Du Dir ja ein unsichtbares Fenster mittels AllocateHwnd holen (das musst Du aber auch mit UnAllocateHwnd wieder freigeben!), nen Test kann ja nicht schaden.

[CalganX]

Und was soll ich mit dem Fenster machen? Woher will iTunes denn wissen, ob ich ein Fenster habe oder nicht? Es wird nirgendwo ein Parameter gefordert, der so einen Schluss zulassen würde.

Chris

Edit: Einfach so ein Handle zu erzeugen, hilft aber nicht.

[OldGrumpy]

iTunes könnte z.B. sich das Top Level Window des Callers holen wollen (wozu auch immer, seitdem ich Entwicklerfeuerwehr spiel, halte ich keine Idee mehr für unmöglich *g*), dazu musst Du keinen Parameter übergeben.

Edit: Na jut, dann hat sich das wohl erledigt. Naja, ist nicht das erste Mal dass iTunes für graue Haare sorgt :)