+1 800 256 3608 (toll-free in North America) or +49 7531 90 60 10| service@combit.com

LL20: Runtime error


(Henrik Reimers) #1

Hallo!

Beim initialisieren der ListLabel() Klasse kommt es gelegentlich zu einem “Runtime error 204 at 07C46CB5”.
Die Meldung erscheint in einem kleinen Nachrichtenfenster.
Wenn man “OK” klickt, erscheint dann noch “Runtime error 204 at 08EE6CB5”.

Wenn ich den Druck-Job stoppe und noch mal laufen lasse, kommt es wieder zu diesem Fehler.
Auch alle anderen Druck-Jobs wollen nicht mehr und brechen mit der gleichen Meldung ab.
Das einzige was dann hilft, ist nur noch ein Neustart des Servers.
Danach laufen die Drucke wieder; für ein paar Tage.

Der Fehler tritt bei folgender Anweisung auf:

ListLabel myLL = new ListLabel();

Im Anhang noch die Screenshots der Meldungen.

Für eine Beschreibung der Ursache des Problems wäre ich sehr dankbar, da die Meldung selber nicht weiter hilft, die Fehler (nur) beim Kunden und meistens Nachts auftreten und die LKWs vom Hof wollen…

Dank und mfG,
Henrik Reimers

LL-Fehler_2015-12-15.png


(Günther Schwarze) #2

Hallo,

ein ähnliches Problem hatte ich auch mal (nicht beim Start aber beim Beenden des Druckjobs) - da hat es geholfen, das von mir nicht benötigte OLE-Objekt zu löschen (cmll20oc.llx).

G.


(Henrik Reimers) #3

Hallo!

Danke für Ihre Hilfe. Ich habe die cmll20oc.llx entfernt.
Knappe fünf Tage lief es.
Jetzt ist der Job allerdings wieder abgebrochen.
Dieses Mal mit der Fehlermeldung: “Die DLL “cmll20.dll”: Eine DLL-Initialisierungsroutine ist fehlgeschlagen. (Ausnahme von HRESULT: 0x8007045A) kann nicht geladen werden.”
Dieser Fehler trat wieder bei folgender C# Anweisung auf:

ListLabel myLL = new ListLabel();

Da der Fehler beim Initialisieren des L&L liegt, kann ich leider nicht mehr viel tun.
Und um L&L vor Weihnachten noch raus zu schmeißen, reicht die Zeit wohl nicht mehr. ;-(

Dank und mfG,
Henrik Reimers


(Günther Schwarze) #4

Hallo,

da würde ich mal den Speicherverbrauch anschauen. Es gibt auch einige wichtige Hinweise dazu zu beachten, ein “Basisjob” sollte außenrum immer offen bleiben, damit die DLLs nicht ständig geladen und entladen werden. Also ganz außen ein ListLabel dummy = new ListLabel(). Dann würde auch das Laufzeitverhalten deutlich optimiert.

Im Prinzip sind das (auch ohne Multithreading) die Hinweise aus diesem Artikel hier:

https://www.combit.net/reporting/support/list-label-knowledgebase/knowledgebase/allgemeine-hinweise/multithreading-mit-list-label/

Schau mal ob das nicht hilft :slight_smile:

G.


(Henrik Reimers) #5

Hallo,

danke Ihnen!
Gerade in der Windowswelt habe ich die Erfahrung gemacht, dass es gut ist, wenn Prozesse aufgerufen und danach wieder ordnungsgemäß entladen werden; aber nicht ewig laufen.
Da ich nicht sagen kann wann und wie viel gedruckt wird, da es von Kunde zu Kunde unterschiedliche ist, lasse ich pro Druck ein Job laufen und danach wieder beenden.
Jetzt müsste ich einen Job oder Dienst für L&L erstellen, der sich nie beendet. Ist das gut? Läuft es dann stabiler?
Wissen Sie, ob es hierzu ein Beispiel gibt, wie aus L&L Sicht so ein Prozess aussehen muss, damit viel und lange gedruckt werden kann?

Vielen Dank und Gruß im Voraus!


(Günther Schwarze) #6

Gerade einige System-DLLs sind leider keine Weltmeister im Ressourcensparen. Bei jedem Laden und Entladen von LL werden viele andere DLLs mitgeladen und entladen. Wenn nur eine davon ein Ressource-Leak hat (ich meine mich an einen Kommentar bezüglich der richedit-DLLs von Microsoft zu erinnern) passiert genau das, was bei Ihnen passiert. Auch Druckertreiber können Handleleaks haben, dann passiert auch da das gleiche.

Ein Dienst der sich nie beendet ist - wenn er denn 24/7 verfügbar sein soll - nichts schlechtes. So lange nichts gemacht wird verbraucht er auch keine weiteren Systemressourcen, sobald was gemacht werden soll ist er schneller am Start. Ich sehe eigentlich nur Vorteile.

Wie sieht denn Ihre Applikationsarchitektur aus? Da ist ja sicher noch mehr als nur LL beteiligt :-)? Sonst könnten Sie den LL-Teil ja auch in einen anderen Teil der Applikation integrieren, der ohnehin immer läuft?

G.