rtl90.bpl wird nach Neustart vermisst

[Medium]

Hallo zusammen,

ich habe die dOPC Komponenten der Fa. Kassl im Einsatz. Leider habe ich dort nur die Packages bis Delphi 2005, nutze aber Delphi 2007. Ich hatte die nötigen Anpassungen im Code vor einiger Zeit selbst gemacht, und das ganze lief über Jahre ganz wunderbar.

Nun habe ich die VM, in der das ganze unter Win7 läuft, neu von unserer Sicherung kopieren müssen. Diese möchte nach dem Booten sofort einen Neustart machen, um "die Änderungen zu übernehmen" - ich habe jedoch keine gemacht. Auch nicht in den VMware Player Optionen. Nur gestartet.

Verneine ich den Neustart, kann ich ohne Probleme Projekte mit den Komponenten öffnen und Kompilieren. Sobald ich die VM aber ein Mal neu gestartet habe, bekomme ich beim Öffnen eines Projektes mit dOPC Komponenten die Meldung:

Code:

---------------------------
bds.exe - Systemfehler
---------------------------
Das Programm kann nicht gestartet werden, da rtl90.bpl auf dem Computer fehlt. Installieren Sie das Programm erneut, um das Problem zu beheben. 
---------------------------
OK   
---------------------------

Die VM ist eine Kopie von der, die ich bisher auch immer verwendet habe.

Ich habe meine Registry mal ganz optimistisch nach den Strings "rtl90" und "rtl100" durchsucht: rtl90 kommt nicht vor, und rtl100 steht brav in den required keys für die dOPC Komponenten drin.
Ich finde in den Packages von dOPC auch nirgends eine Option oder Codestelle an der explizit nach der rtl90 verlangt wird, und ich habe die vollständigen Quellen davon.

Kopieren und Umbenennen der rtl100.bpl zu rtl90.bpl in Windows\System32 führt dazu, dass beim Öffnen eines Projektes die Datei nicht mehr vermisst wird, aber Prozedureinsprungpunkte nicht gefunden werden. (Nachvollziehbar, aber war einen Versuch wert.)
Neuinstallieren der Komponenten (mit anschließendem Code-Fixing) brachte leider auch keine Änderung.

Nicht Neustarten zu können ist etwas blöd, weil ab und zu muss man das ja.

Kann sich hier jemand einen Reim darauf machen, was da passiert, und wie sich das lösen ließe? Danke euch schon mal! (Neukauf mit aktuelleren Versionen wäre wirtschaftlich fragwürdig, da wir damit lediglich ein einziges und zudem recht kleines, altes (ursprünglich unter D7 entwickeltes) Projekt alle paar Jahre mal pflegen.)

[Delphi.Narium]

In Windows\System32 liegt die rtl100.bpl aber keine rtl90.bpl?

Gibt es die rtl90.bpl "irgendwo" anders, wo sie ohne Neustart gefunden werden kann (z. B. über die Angaben in %PATH%), wobei %PATH% nach 'nem Neustart dann einen anderen Inhalt hat, sodass rtl90.bpl dann nicht mehr gefunden werden kann?

[jaenicke]

Am einfachsten kann man das mit dem Process Monitor prüfen. Wenn du den Filter auf path ends with rtl190.bpl setzt, siehst du alle Zugriffe darauf und eben auch, wo gesucht wird.

[himitsu]

Du hast nur die vorkompilierten Kompilate (BPL/DCP/DCU), oder auch für ALLES die Quellcodes (DPR/DPK und PAS) ?

Wenn nicht, dann altes Delphi, bis 2005, oder Neues von Kassl kaufen.



Sonst ist doch alles gesagt, was wichtig ist. :wink:

Zitat:

Leider habe ich dort nur die Packages bis Delphi 2005, nutze aber Delphi 2007

PackageVersion 9.0 aka 90 ist Delphi 2005

Packages (BPL) und auch kompilierte Units (DCU) sind genau für eine Delphi-Version und funktionien auch ausschließlich nur dort (teilweise sogar genau in einer bestimmten Update/Hotfix-Version)
Es ist unmöglich sie in Delphi 2007 zu benutzen, egal ob man die Dateien umbenennt oder sich diese Dateien aus D2005 kopiert.

(2006/2007 gab es nur mal den Sonderfall, dass der selbe Compiler drin steckte und daher Einiges kompatibel war)

Zitat:

Gibt es die rtl90.bpl "irgendwo"

Ja, wenn du Delphi 2005 installierst.



Seiten Embarcadero gibt es hier auch keine Lösung.
Sie können nur D7 und alles seit D2007 bis jetzt bereitstellen. (für davor hatten sie sich keine Rechte gekauft)
https://www.embarcadero.com/de/produ...vious-versions

[Medium]

Brat mir einer einen Storch.

Ein anderes Projekt mit denselben Komponenten lässt sich ohne Probleme öffnen. Der Witz: Das ist im Grunde genau das selbe Programm, nur eine Variation von dem nicht mehr funktionierenden, und die Unterschiede betreffen die OPC-Funktionen überhaupt nicht.

Nach der Meldung, dass die rtl90.bpl nicht gefunden wurde kommt beim nicht mehr funktionierenden Projekt übrigens noch die Meldung:
"Package C:\Users\Public\Documents\RAD Studio\5.0\Bpl\dOPCDA9.bpl kann nicht geladen werden. Das angegebene Modul wurde nicht gefunden."

Gehe ich in dieses Verzeichnis, liegt dort aber eine Datei namens "dOPCDA9.bpl" drin! Selbe VM, selbes Delphi, ohne Neustarts zwischendrin, 15sek nacheinander probiert. Ein Projekt öffnet sich problemlos, das andere nicht.

Das kapiere ich nun gar nicht mehr.

[himitsu]

Das ist, weil die Meldung falsch ist und Microsoft es seit Jahren nicht hinbekommt zum GetLastError noch eine API mit freiem DetailString zum Fehlercode hinterlegen zu können,
wie z.B. welche DLL nicht geladen werden konnte.

Windows gibt nur einen Fehlercode ala 123 raus, aka "eine dll konnte nicht geladen werden" und einige Programme schreiben dann dazu noch den Namen, was sie laden wollten.
DIESES ist aber nicht unbedingt das Gleiche.

*

Delphi-Quellcode:

LoadLibrary('A.dll');

oder .bpl
* diese DLL bindet eine weitere DLL ein und Jene wurde nicht gefunden

[Medium]

Hmm okay, das erklärt zumindest, warum die falsche Datei angemeckert wird. Leider aber noch nicht, warum sogar exakt dasselbe Projekt, bevor ich es vor ein paar Tagen neu gespeichert hatte, sich ebenfalls problemlos öffnen lässt.

Da muss irgend etwas sehr esoterisches passiert sein...

[jaenicke]

Wie ich geschrieben habe:
All das kann man mit dem Process Monitor sehen. Welche Dateien werden gesucht, wo werden sie gesucht, ...

Vielleicht wird nach der Datei ja an der falschen Stelle gesucht. Vielleicht ist auch die PATH-Variable zu lang. Da gibt es viele Möglichkeiten.

[himitsu]

falsche Stelle sollte es nicht sein direkt sein
aber ja, Suchpfade in den Projektoptionen.

Es darf garnicht nach 90 (D2005) gesucht werden, weil du ja für 110 (D2007) kompilierst.


Versionsnummer/Postfix hartcodiert und vergessen zu ändern, als das Projekt auf Delphi 2007 umgezogen wurde (OK, ging damals nicht anders, weil $(auto) wurd erst vor Kurzem erfunden)
-> nicht nach Dateinamen, sondern IN deinen Dateien/Quellcodes suchen

[Medium]

Zitat:

Zitat von himitsu (Beitrag 1513773)

Versionsnummer/Postfix hartcodiert und vergessen zu ändern, als das Projekt auf Delphi 2007 umgezogen wurde (OK, ging damals nicht anders, weil $(auto) wurd erst vor Kurzem erfunden)
-> nicht nach Dateinamen, sondern IN deinen Dateien/Quellcodes suchen

Der Umzug war eigentlich von D7 auf D2007. D2005 kommt nur ins Spiel, weil das Package für die Komponente eigentlich für D2005 ist. Da ich aber die vollen Sourcen habe, hab ich darin kurzerhand die nötigen IFDEFs angepasst, und konnte sie komplett neu für D2007 kompilieren. Das hatte ich ja schon vor etlichen Jahren gemacht und seit dem auch desöfteren ohne Probleme damit gearbeitet.

Was mich halt gerade extrem wundert, ist dass dasselbe Projekt in einer Version von vor ein paar Tagen klaglos läuft. Also muss es ja etwas am Projekt selber sein - aber die Änderungen, die ich zuletzt gemacht habe, betrafen lediglich das Logging in einem Memo, haben also nichts was mit OPC zu tun hat angefasst. Auch Projektoptionen habe ich nicht geändert.

Bevor ich weiter auf Geisterjagd gehe, versuche ich einfach mal die Änderungen nochmals auf Basis der Vor-Version zu machen. Mal schauen, wie die sich dann verhält.

[Medium]

Neue Erkenntnis:

Das Problem taucht dann auf, wenn ich eine Komponente aus dem Package neu auf das Formular packe. Ich erinnere mich daran, dass ich beim Machen der letzten Änderungen aus Versehen Strg-X mit einer dieser im Fokus gedrückt habe, und dann einfach mit Strg-V wieder eingefügt. (Aus meiner Sicht also "nichts geändert".)
Wenn die Komponente bereits vorhanden ist, gibt es keine Probleme. Spannend ist auch: Copy&Paste solch einer Komponente geht. Aber neu aus der Palette aufs Form ziehen nicht! Da kommt dann genau derselbe Fehler wie beim Öffnen. Welcher allerdings auch beim Öffnen kommt, wenn die Komponente vorher funktionierend kopiert wurde.

Was auch wunderbar geht: Komponente zur Laufzeit erzeugen! Einfach im OnCreate der Form als Felder der Form-Klasse, Ereignisse zuweisen, go. Ohne Probleme.

Muss ich wohl doch mal den PE zu Rate ziehen. Noch nie erlebt sowas.

[Rolf Frei]

Zitat:

Zitat von Medium (Beitrag 1513778)

Der Umzug war eigentlich von D7 auf D2007. D2005 kommt nur ins Spiel, weil das Package für die Komponente eigentlich für D2005 ist. Da ich aber die vollen Sourcen habe, hab ich darin kurzerhand die nötigen IFDEFs angepasst, und konnte sie komplett neu für D2007 kompilieren. Das hatte ich ja schon vor etlichen Jahren gemacht und seit dem auch desöfteren ohne Probleme damit gearbeitet.

Was mich halt gerade extrem wundert, ist dass dasselbe Projekt in einer Version von vor ein paar Tagen klaglos läuft. Also muss es ja etwas am Projekt selber sein - aber die Änderungen, die ich zuletzt gemacht habe, betrafen lediglich das Logging in einem Memo, haben also nichts was mit OPC zu tun hat angefasst. Auch Projektoptionen habe ich nicht geändert.

Bevor ich weiter auf Geisterjagd gehe, versuche ich einfach mal die Änderungen nochmals auf Basis der Vor-Version zu machen. Mal schauen, wie die sich dann verhält.

Das solltest du nicht so machen! Damit ist das Package noch nicht für D2007 fertig. Die ganzen Requires müssen da genauso an die Packages von D2007 angepasst werden udn auch der Packagename sollte auf irgendwas mit D2007 im Namen angepasst werden. Dann kann es sein, dass dein Projekt das problemlos läuft ohne Packages kompiliert wurde und dein neues mit. Schalte die die Nutzung der Packages in deinem neuen Projekt einfach aus oder kontrolliere da die verwendeten Packages. Du ahst da vermutlch ncoh den selben Dateinamen für das D2007 Package wie für das D2005 Package und das ist ein absolutes NOGO! Vermutlch versucht dein Programm die flache D2005 Pacakge zu laden, welches wiederumm die besagte rtl90 laden will, dies es aber garnicht gibt. in deinem neuen Package müsste rtl110 im required des Package eingetragen sein.

[himitsu]

Man kann z.B. im Require die Packages mit oder ohne Version angeben, wenn sie mit LIBSuffix erstellt wurden, also die "Version" nicht im Dateinamen steht.
also RTL oder eben RTL123 ... bei Letzterem hast die Version fest verknuppelt und mußt das natürlich beim Upgrade (neues Delphi) auch mit anpassen.


In neueren Delphis ab 10.4 kann man beim Erstellen von eigenen Packages auch $(auto) als LIBSuffix angeben.
Zusammen mit dem "ohne Nummer" im Require lassen sich somit (bedingt) Projekte nun auch für mehrere Delphi-Vesionen benutzen, bzw. einfach upgraden ... ansonsten braucht man pro Delphi-Version eine DPK/DPROJ, bzw. muß beim Upgrade immer wieder die Nummern ändern.

[Delphi.Narium]

Zitat:

Zitat von Medium (Beitrag 1513779)

Neue Erkenntnis:

Das Problem taucht dann auf, wenn ich eine Komponente aus dem Package neu auf das Formular packe. Ich erinnere mich daran, dass ich beim Machen der letzten Änderungen aus Versehen Strg-X mit einer dieser im Fokus gedrückt habe, und dann einfach mit Strg-V wieder eingefügt. (Aus meiner Sicht also "nichts geändert".)
Wenn die Komponente bereits vorhanden ist, gibt es keine Probleme. Spannend ist auch: Copy&Paste solch einer Komponente geht. Aber neu aus der Palette aufs Form ziehen nicht! Da kommt dann genau derselbe Fehler wie beim Öffnen. Welcher allerdings auch beim Öffnen kommt, wenn die Komponente vorher funktionierend kopiert wurde.

Was auch wunderbar geht: Komponente zur Laufzeit erzeugen! Einfach im OnCreate der Form als Felder der Form-Klasse, Ereignisse zuweisen, go. Ohne Probleme.

Muss ich wohl doch mal den PE zu Rate ziehen. Noch nie erlebt sowas.

Dann gibt es (höchstwahrscheinlich) Unterschiede in der zum Projekt gehörenden Konfiguration der Packages.

Unter D7: Menü "Komponenten" Untermenü "Packages installieren"

Analog dazu in deinen Delphis mal schauen, ob dort Unterschiede zu finden sind.

Die IDE scheint nicht in der Lage zu sein etwas aus der Palette in ein Formular einzufügen, zu dem zwar der Paletteneintrag vorhanden ist, aber das Package in der Entwicklungsumgebung fehlt.

Bei Copy&Paste wird einfach der Quelltext des Kopierten neu eingefügt. Da muss das entsprechende Package nicht vorhanden sein, da ja schon alle nötigen Infos per Copy&Paste geliefert werden.

Es fehlt Dir da in der IDE vermutlich das Design-Time-Package.

Das die Fehlermeldung nicht zwingend so ganz korrekt ist, hat himitsu ja weiter oben schon beschrieben. Es fehlt also nicht zwingend rtl90.bpl sondern eventuell "irgendetwas", das von rtl90.bpl benötigt wird oder "irgendetwas" aus einer ganzen Reihe von Abhängigkeiten, in der rtl90.bpl u. a. auch eine Rolle spielen könnte.

[Uwe Raabe]

Zitat:

Zitat von himitsu (Beitrag 1513786)

Man kann z.B. im Require die Packages mit oder ohne Version angeben, wenn sie mit LIBSuffix erstellt wurden, also die "Version" nicht im Dateinamen steht.
also RTL oder eben RTL123 ... bei Letzterem hast die Version fest verknuppelt und mußt das natürlich beim Upgrade (neues Delphi) auch mit anpassen.

Ich möchte nur mal anmerken, dass diese Technik mindestens seit Delphi 7 existiert und von Borland empfohlen wird. Es ist erstaunlich, ja eigentlich beschämend, dass das selbst heute noch von vielen Komponentenherstellern ignoriert wird.

[himitsu]

Mal als FeatureRequest, für's nächste Jahrtausend, dass der Compiler eine Warnung wirft.


Nja, das neue, paar Jahre alte $AUTO hat auch noch paar Probleme ... z.B. in den Makrovariablen fehlt im $(Outputfilename) die Version.

[Medium]

Zitat:

Zitat von Uwe Raabe (Beitrag 1513791)

Zitat:

Zitat von himitsu (Beitrag 1513786)

Man kann z.B. im Require die Packages mit oder ohne Version angeben, wenn sie mit LIBSuffix erstellt wurden, also die "Version" nicht im Dateinamen steht.
also RTL oder eben RTL123 ... bei Letzterem hast die Version fest verknuppelt und mußt das natürlich beim Upgrade (neues Delphi) auch mit anpassen.

Ich möchte nur mal anmerken, dass diese Technik mindestens seit Delphi 7 existiert und von Borland empfohlen wird. Es ist erstaunlich, ja eigentlich beschämend, dass das selbst heute noch von vielen Komponentenherstellern ignoriert wird.

Ist in diesem Fall nicht beschämend, weil dort die versionsfreien requires Angaben gemacht wurden. Die hatte ich mir bereits angeschaut. Dort steht einfach nur "rtl.bpl" drin.

[himitsu]

es wurde auch schon genannt

* ProzessExplorer
* da siehst du dann wann und von wo diese rtl90 versucht wird zu laden
* und man sieht auch, welche BPL/DLLs vorher geladen wurden ... meistens sind es Jene, welche dann auch diese DLL/BPL laden,
* * bzw. man siehst sich den ProzessStack an, aus welchem Modul das Laden wirklich kam

[Medium]

Zitat:

Zitat von Delphi.Narium (Beitrag 1513789)

Die IDE scheint nicht in der Lage zu sein etwas aus der Palette in ein Formular einzufügen, zu dem zwar der Paletteneintrag vorhanden ist, aber das Package in der Entwicklungsumgebung fehlt.

Bei Copy&Paste wird einfach der Quelltext des Kopierten neu eingefügt. Da muss das entsprechende Package nicht vorhanden sein, da ja schon alle nötigen Infos per Copy&Paste geliefert werden.

Es fehlt Dir da in der IDE vermutlich das Design-Time-Package.

Das klingt interessant. Da muss ich mal gucken, ob es noch ein separates Designtime-Package gibt. Allerdings erinnere ich mich daran, 2 Packages installiert zu haben: "Kassl common dOPC" (vermutlich Runtime Package), und "Kassl dOPC DA" (vermutlich Designtime, weil daraufhin bestätigt wurde, dass die Komponente "TdOPCServer" der Palette hinzugefügt wurde. (Um welche es hier letztlich geht.)

Die beiden Packages werden auch als installiert und aktiviert in der Übersicht angezeigt - bis zu dem Zeitpunkt, an dem ich die Komponente platziere. Ab dann sind sie daraus verschwunden. Starte ich Delphi ohne Projekt neu, sind sie wieder drin.

[Medium]

Zitat:

Zitat von himitsu (Beitrag 1513805)

es wurde auch schon genannt

* ProzessExplorer
* da siehst du dann wann und von wo diese rtl90 versucht wird zu laden
* und man sieht auch, welche BPL/DLLs vorher geladen wurden ... meistens sind es Jene, welche dann auch diese DLL/BPL laden,
* * bzw. man siehst sich den ProzessStack an, aus welchem Modul das Laden wirklich kam

Was mich hiervon bisher abgehalten hat ist, dass sich die Datei rtl90.bpl niemals auf dem PC befunden hat. Ich habe sowohl das frisch kopierte Backup, als auch die neugestartete Version komplett nach "rtl90*.*" durchsuchen lassen - nirgends.
Was auch Sinn macht, da ich D2005 nie besessen habe.

[Uwe Raabe]

Der Verweis auf rtl90.bpl steht in der rtl.dcp die beim Compilieren verwendet wurde. Vielleicht hilft das bei der weiteren Suche.

[Delphi.Narium]

Zitat:

Zitat von Medium (Beitrag 1513807)

Die beiden Packages werden auch als installiert und aktiviert in der Übersicht angezeigt - bis zu dem Zeitpunkt, an dem ich die Komponente platziere. Ab dann sind sie daraus verschwunden. Starte ich Delphi ohne Projekt neu, sind sie wieder drin.

Es gibt einmal eine Packagekonfiguration für die IDE, die dann gilt, wenn man sie startet und dann für alle neuen Projekte.

Man kann aber in einem geöffneten Projekt Packages dazuinstallieren und auch welche entfernen. Dies gilt dann immer für "dieses Projekt", egal was die IDE beim Neustart nun an Packages lädt oder nicht lädt.

Sind die von Dir benötigten Packages bei den installierten Packages auch dann aktiv / installiert, wenn Du Dein "Problemprojekt" geladen hast.

Was ist in der Konfiguration für die IDE enthalten, wenn Du sie neu startest?
Was ist in der Konfiguration für die IDE enthalten, wenn Du Dein Projekt lädtst?
Gibt es da Unterschiede?

Wenn die Packages genau in dem Moment aus der Liste der installierten Packages verschwinden, in dem Du per Platzieren darauf zugreifst, prüfe bitte mal nicht nur, ob sie da sind oder nicht, aktiviert sind oder nicht, sondern auch, ob die Pfadangaben mit denen übereinstimmen, die dort stehen, wenn die IDE neu gestartet wird.

Im Zweifelsfalle die Packages deinstallieren und neu installieren.

Zitat:

Zitat von Medium

Was mich hiervon bisher abgehalten hat ist, dass sich die Datei rtl90.bpl niemals auf dem PC befunden hat. Ich habe sowohl das frisch kopierte Backup, als auch die neugestartete Version komplett nach "rtl90*.*" durchsuchen lassen - nirgends.
Was auch Sinn macht, da ich D2005 nie besessen habe.

Über den ProzessExplorer bekommst Du aber heraus, wer denn da bitte ein unstillbares Verlangen nach der rtl90.bpl hat. Und das ist der Übeltäter, nicht die rtl90.bpl.

Es muss sich da wohl "irgendwo" eine Abhängigkeit zur rtl90.bpl eingeschlichen haben, z. B. ein "beliebiges" anderes Package im Suchpfad, im Bibliothekspfad, woauchimmer, ..., welches nicht zu Deiner Delphiversion passt, eine Abhängigkeit zur rtl90.bpl aufweist und trotzdem von der IDE geladen werden soll.

Insgesamt entsteht der Eindruck, dass hier (wodurch auch immer) in Mischmasch aus Packages ... mehrerer Delphiversionen entstanden sein könnte.

Wie sehen die Bibliothekspfade aus, weist da in dem Projekt einer auf eine Stelle, an der Sachen von Delphi 2005 liegen?
Wie sieht der Bibliothekspfad für eine neues, funktionierendes Projekt aus?
Wo sind die Unterschiede?

Notfalls alle Bibliothespfade, Suchpfade, ... leeren und dann neu, entsprechend den Anforderungen der IDE und der Projekte, neu zusammenstellen.

[himitsu]

Das hieße dann aber, dass er eine alte DCP verwenden würde.
Nja, mal "rtl90" in allen Dateien zu suchen, wurde bereits genannt.

Zitat:

Was mich hiervon bisher abgehalten hat ist, dass sich die Datei rtl90.bpl niemals auf dem PC befunden hat

Egal.
Der ProzessExplorer zeigt nicht nur was gemacht wurde, sondern auch was versucht wurde.
z.B. CreateFile auf eine nichtexistierende Datei und dessen Fehlercode.

Zitat:

Man kann aber in einem geöffneten Projekt Packages dazuinstallieren und auch welche entfernen. Dies gilt dann immer für "dieses Projekt", egal was die IDE beim Neustart nun an Packages lädt oder nicht lädt.

Die Exclude-Liste in der/allen DPROJ soll aber quasi leer sein.

[Medium]

Viele interessante Ansätze, danke euch! Ich hoffe, mich morgen weiter darum kümmern zu können. Ist zwar mittles Erzeugung zu Laufzeit soweit lösbar, dass ich dem Kunden sein Update zubereiten kann, aber irgendwie fuchst mich das :)

[himitsu]

Für unser Programm hatte ich vor Kurzem mal rausgesucht, wie man sich bei Windows registriert, um DLL-Lade-Notifications zu bekommen ... diesen Code könnte man eigentlich mal via OTA in die IDE reinhängen und dann im Log ausgeben wann welche DLL/BPL ge-/entladen würde.
(ist zwar die alte API, welche seit Jahren auf deprecated steht, aber die war einfach um längen einfacher, als das Neue :oops:)

Dann sähe man zumindestens ob/wann "wirklich" was da ist.


Einige Jahre vorher bei allen "unseren" Packages das Log manuell in jedes Package reingemacht, damit beim Laden und Kompilieren sichtbar wird, welche DesignTimePackages ich gegenseitig (ent)laden, bzw. wenn es beim Kompilieren/Laden/Entladen knallt, wo es knallt (was zuletzt ge-/entladen wurde).
So (neu) bekommen wir nun auch Meldungen von den Milliarden DevExpress-Packages. :freak:


Meinen Versuch mich ins Windows-EventLogging reinzuhängen ist noch nicht weit genug (hatte mit der Registry angefangen und die ist grade das Perverseste von allen SystemLogs) ... sonst könnte man nun ganz einfach außerhalb der IDE sehen, wann die ge-/entladen werden.