Die Setuproutine wirft uns nach der Installation den Returncode -103 zurĂĽck. Der Fehler tritt in erster Linie bei Systemen auf die den 2.3.0 zuvor installiert hatten. Die Setup soll als Update genutzt werden.
Ich habe dann in das Installationslog vom PDF Creator geschaut und folgendes entdeckt:
Scheinbar scheint die Installation funktioniert zu haben, aber der Printer konnte selber nicht aktualisiert werden. Kann mir Jemand sagen was UpdatePDFCreatorPrinter: ResultCode=3 [failed] bedeuten kann?
Die Programmversion ist nach der Setuproutine 2.5.1 und scheint auch soweit normal zu funktionieren.
der ResultCode 3 steht für “internen Fehler”, leider lässt sich daraus nicht wirklich ableiten, was tatsächlich schiefgelaufen ist/sein könnte. Wenn der PDFCreator nach dem Update noch korrekt funktioniert, hat der Fehler im Setup vermutlich keinerlei Auswirkung auf die Funktionalität der Anwendung. Welche Version hat die pdfcmon.dll in Windows\system32 bei Dir?
Evtl. gab es ein Problem dabei, diese auszutauschen, das sollte aber an sich auch im Log auftauchen.
danke fĂĽr die Info! Die Datei hat die Version 0.8.4.0 und einen Zeitstempel von 26.09. Denkst du man kann den Fehler ignorieren? Dann kann ich in meiner Softwareverteilung das Paket so bauen das er den Returncode -103 als erfolgreich behandelt wird.
Von 419 Installationen sind nämlich ca 210 Systeme mit diesem Returncode beendet worden und 189 mit dem Returncode 0 (also erfolgreich) abgeschlossen worden. Jetzt weiß ich aktuell nicht wie ich damit umgehen soll…
Hier mal das komplette Setup Log von einem Beispiel Client:
jetzt wissen wir zumindest schonmal, was schiefgelaufen ist; die Monitor.dll konnte nicht ausgetauscht werden, diese sollte nach dem Update die Version 0.9.4.0 haben; leider heiĂźt das auch, dass der Fehler nicht ignoriert werden sollte. Ist der Fehler reproduzierbar, bzw. tritt dieser erneut auf, wenn man erneut versucht das Update auf einer der betroffenen Maschinen zu installieren?
das teste ich mal durch… Bisher hatte ich noch keine erneuten Installationsversuche unternommen da sich die User bisher noch nicht gemeldet haben und wohl damit arbeiten könne. Ich werde mir das morgen mal in Ruhe tiefer anschauen und gucken ob ich den Fehler reproduziert bekomme.
also das Neuinstallation führt wieder zum gleichen Fehler. Jetzt wo ich nochmal drüber nach gedacht habe… Unsere Softwareverteilung markiert die Installation auch erst als fehlgeschlagen nach dem er 3x probiert hat und dann ist das System schon neugestartet worden.
Woher hast du denn erkannt das die Monitor.dll nicht aktualisiert wurde? Im Log kann ich irgendwie nichts zu der Monitor.dll finden.
Hi zusammen.
ich schließe mich hier einfach mal an…
Wie Robin schon sagte, liegt es daran, dass die pdfcmon.dll nicht aktualisiert wird. Warum das auf gefühlt der Hälfte aller Systeme nicht passiert ist fraglich. Für mich ist bei den Geräten kein Muster erkennbar. Wenn ich diese Datei händisch umbenenne, bevor ich das 2.5.1 Setup silent starte, läuft es sauber durch und gibt auch den exitcode 0 zurück. Die Zugriffsrechte auf die Datei sind aber für alle beteiligten Accounts gegeben und so weit ich das beurteilen kann ist diese auch nicht anderweitig in Benutzung.Was auch auffällt ist, dass dieser Fehler nicht in derart sporadisch auftritt, sondern dass die Systeme, die diesen Fehler haben, den auch bei jedem weiteren Versuch bekommen.
Es wäre also interessant, was hier der Grund dafür ist, dass bei diversen Systemen die Datei nicht aktualisiert werden kann, während das bei anderen Geräten problemlos funktioniert.
I can’t say for sure, but it could be related to the current status of the Windows spooling subsystem, as this uses the pdfcmon and in some more abstract cases (e.g. trying to delete the pdfcmon.dll by hand) it is required to stop the spooler beforehand, or the pdfcmon.dll will be in use. The setup should detect this and automatically take the required action; perhaps something is not working as expected here. Using switches like /NoRestart might of course produce these kind of problems, as the restart might be required in order to exchange the file properly.
@apelz Das war zunächst nur eine Vermutung, welche sich dann dadurch bestätigte, dass die pdfcmon.dll bei Dir noch die alte Versionsnummer hat.
danke für die Antwort! Scheint auch tatsächlich daran zu liegen. Wenn wir lustigerweise die dll vorher umbenennen funktioniert das Update. Auf den Parameter /norestart können wir leider nicht verzichten, wenn die Systeme hier unkontrolliert rebooten gibs Ärger.
FĂĽr mich siehts nach einem Bug in der Setup Routine aus, wir werden jetzt ein entsprechendes Skript schreiben.
