PostSP2: MSXML 4.0 SP2 Error 1603

**Lenge** · 19.11.2005, 13:22

Nachdem ich auf 3 PCs reproduzierbar "errorlevel 1603" bei der Installation des MSXML 4.0 SP2 als opt. PostSP2-Modul bekomme, es aber auf einem 4. PC klappt, hab ich folgende Begleitumstände gefunden:

Auf PC 4 habe ich die vorletzte PostSP2-Version übersprungen und direkt die letzte (09.11.) installiert. Das opt. Modul wurde beim Installieren automatisch angehakt und installiert problemlos ("erfolgreich").

Auf den anderen 3 PCs hatte ich zuvor alle alten PostSP2s installiert. Das opt. Modul wurde nicht automatisch angehakt. Die Installation liefert "errorlevel 1603". Im Ereignisprotokoll findet sich danach dieser Fehler:

Produkt: MSXML 4.0 SP2 Parser und SDK -- Fehler 1316. Beim Versuch, die Datei U:\Winhelpline PostSP2 2005-11-09\optional\11 MSXML 4.0 Service Pack 2 (2005-11-09)\054+msxmlger.msi zu lesen, ist ein Netzwerkfehler aufgetreten.

Weitere Informationen über die Hilfe- und Supportdienste erhalten Sie unter http://go.microsoft.com/fwlink/events.asp.

Offenbar will dfer Updater also zwingend, dass die Datei von "msxmlger.msi" in "054+msxmlger.msi" umbenannt wird. Wenn man das probeweise tut, installiert sie danach auch auf PC 1-3 erfolgreich.

Bleibt die Frage, unter welchen Umständen der Updater die Umbennenung zwingend erfordert, und warum es bei PC 4 auch mit dem Originalnamen klappt. Vielleicht hilft das Posting ja beim Eingrenzen der Ursache.

**HeikoBerlin** · 19.11.2005, 14:37

Sobald ich meine Vista Visite beendet habe, werde
ich mich deinem Prob nochmals ausführlicher widmen.
(zeit- und platztechnisch momentan eher ungünstig)

> Auf PC 4 habe ich die vorletzte PostSP2-Version übersprungen
Da bei letzter Aktualisierung des Updater keinerlei Update
entfernt wurde installiert der Neue also nur zusätzliches..

> anderen 3 PCs ..wurde nicht automatisch angehakt
Weil es nicht auffindbar war (deaktivierte, graue Schaltfläche)
wohl eher nicht da Du es ja scheinbar auswählen konntest, also
müsste es lt. Logdatei da bereits installiert sein, oder nicht?
Was für msxml4*.dll Versionen sind da im Windows\system32 Ordner?

> Offenbar will dfer Updater also zwingend, dass die Datei
> von "msxmlger.msi" in "054+msxmlger.msi" umbenannt wird

Funzt bei mir ausnahnmslos absolut problemfrei mit msxmlger.msi
Im gesamtem Quelltext des XPpostSP2updater (+ -neu) gibt es
die Zeichenkette 054 nur als Teil von "kb905414" !! - Auszug:

Code:

x = suchDatei(UpdDir & "optional\", "*msxmlger.msi")
If Len(DoptXML4) = 0 Then chkXML4 = 0: chkXML4.Enabled = False

Function suchDatei ..
Case "*msxmlger.msi"
If DoptXML4 = "" Then DoptXML4 = suchDatei

Die Erkennung optionaler wird ja sowieso alternativ probiert..
("Dateinamen-freie Erkennung der opt. Dateien" - s. Anm.)
Ansonsten kann ich dir nur anbieten das erste Zeichen wegzu-
nehmen: also "*sxmlger.msi" statt bisher "*msxmlger.msi"
Das müsste a) aber bei allen Optionalen Modulen so sein (?)
b) bei den 3 PC's auch funzen wenn ein x-beliebiges Zeichen
vorangestellt ist, oder? (oder muss msi vorher nach temp kopieren?)

**Lenge** · 21.11.2005, 12:12

> anderen 3 PCs ..wurde nicht automatisch angehakt
Weil es nicht auffindbar war (deaktivierte, graue Schaltfläche)
wohl eher nicht da Du es ja scheinbar auswählen konntest, also
müsste es lt. Logdatei da bereits installiert sein, oder nicht?
Was für msxml4*.dll Versionen sind da im Windows\system32 Ordner?

Auswählbar ist es schon, nur nicht defaultmäßig angehakt. In Windows\system32 liegen:

msxml.dll, msxmlr.dll, msxml2.dll, msxml2r.dll, msxml3.dll, msxml3r.dll, msxml4.dll, msxml4r.dll.

Funzt bei mir ausnahnmslos absolut problemfrei mit msxmlger.msi
Im gesamtem Quelltext des XPpostSP2updater (+ -neu) gibt es
die Zeichenkette 054 nur als [...]

Bei mir klappts nach wie vor nur auf einem PC ohne 1603. Der Gag ist, dass der Updater laut dem Windows-Ereignisprotokoll offenbar versucht, eine (nicht vorhandene) Datei "054+msxmlger.msi" zu öffnen. Und wenn man daraufhin die Datei entsprechend umbenennt, installiert sie ohne Murren auch auf PC 1-3.

Wenn der Updater "054" nicht im Quelltext hat, kann ich mir eigentlich nur folgendes vorstellen:

* MSXML4 wurde auf PC 1-3 schon früher[tm] von einer älteren Version des Updaters installiert. Dort hiess die entsprechende Datei möglicherweise evtl. "054+...". (Man musste/konnte bei alten Versionen des Updaters ja einige Module umbenennen).

* Windows bzw. der neue Updater stellen nun fest, dass das Teil bereits installiert ist (=> Kästchen wird nicht angehakt). Wenn man es manuell anhakt, wird der alte(!) Name der Installationsdatei irgendwo ausgelesen und versucht, diese erneut zu installieren.

Kann sowas sein?

**HeikoBerlin** · 21.11.2005, 13:37

Es ist in der Tat die einzigst logische Erklärung das die
Datei 054+msxmlger.msi zuvor installiert wurde, was der
Updater ja wohl auch erkennt weshalb es nicht vorausgewählt
ist und dies ebenso von msxmlger.msi bzw. dem Windows Installer
erkannt wird und dieser (nicht etwa der Updater) versucht diese
Datei wiederholt von deren ehemaligen Quelle aufzurufen.

Was soll ich da deiner Meinung nach machen?
Da könnte ja auch der ehemalige Quellpfad nicht mehr existent
sein weshalb der Versuch es dahin zu kopieren auch nicht viel
bringen würde. Ebenso unsinnig finde ich es -da es ja bereits
installiert ist- es zuvor zu entfernen um es neu zu insten.

> MSXML4 wurde auf PC 1-3 schon früher[tm] von einer
> älteren Version des Updaters installiert

Der Updater unterstützt MSXML4 erst seit der akt. Version (09.11.)
und das grafische Setup funzt schon immer ohne jegliche Umbenennung

Dank deiner Info sollte es mir jetzt auch möglich sein das entsprechend
zu rekonstruieren aber wie gesagt ist der Updater dafür nicht die Ursache.
Müsste also manuell installiert und umbenannt sowie verschoben zu dem
gleichen Ergebnis führen. Und das es im Einzefall Probleme beim wieder-
holten Insten gibt hatte ich ja u.a. bei Framework hier bereits erwähnt.

**HeikoBerlin** · 21.11.2005, 14:29

jau, habe es jetzt ohne Updater (!) auf einem
jungfräulichen Windows XP rekonstruiert:

Im Ordner test1 lasse ich testmsxmlger.msi insten: okay
Benenne danach test1 um und rufe in test2 die Installation
mit Originalnamen msxmlger.msi auf und erhalte das Ereignis:

Produkt: MSXML 4.0 SP2 Parser und SDK -- Fehler 1316.
Beim Versuch, die Datei C:\test2\testmsxmlger.msi zu lesen,
ist ein Netzwerkfehler aufgetreten.

Ist übrigens gar kein Netzwerk.. - und nu?
Soll ich deswegen bei allen (die es ggf. nicht Umbenennen)
die wiederholte Installation verhindern indem ich dessen
Auswahl überall deaktiviere, wo es schon vorhanden ist?

Sehe da eigentl. keinen Vorteil denn errorlevel 1603 führt
ja selbstverständlich auch nicht zum Abbruch des Updaters und
es war ja dein ausdrücklicher Wunsch es wiederholt zu insten.

Ansonsten könnte ich versuchen den vom Updater gefundenen Namen
der akt. Datei mit dem alten in der Reg zu vergleichen unter:

HKEY_CLASSES_ROOT sowie HKEY_LOCAL_MACHINE\SOFTWARE\Classes
\Installer\Products\6030E61781384634B8F8C04C9E73B6CA\SourceL ist

LastUsedSource + PackageName

**Lenge** · 21.11.2005, 15:42

Okay, dann haben wir die Ursache ja gefunden.

Ich würde den aktuellen Updater nicht ändern, weil nicht dieser die Ursache ist (sondern das mit alten Versionen verbundene Umbenennen einzelner Module). So wie ich Dich verstehe, müsste es bei solchen Problemen reichen, das jeweilge Modul manuell zu deinstallieren und dann wieder mit dem (neuen) Updater drüberzupacken.

In diesem Fall würde es IMO reichen, den Sachverhalt publik zu machen (z. B. unter "bekannte Probleme", "FAQ" oder sowas). Dann können betroffene User im Einzelfall selbst entsprechend reagieren.

**HeikoBerlin** · 21.11.2005, 16:26

Nur weil der Updater nicht Schuld ist ..
..heisst das nicht das er es nicht besser machen kann

Variante 1: Die Werte (Dateinamen) in der Reg (s.o.) entsprechend
dem akt. Dateinamen der in optional gefundenen anpassen. Der Pfad
steht da zwar eigentl. auch - aber da stört wohl keine Änderung.
(Unterschiedliche Dateinamen erkennt er gegenwärtig bei mir schon)
Funzt so sicherlich nur wäre das der erste Schreibzugriff des
Updater's in die Reg - was ich eigentl. weiter umgehen möchte.

Variante 2 wird sich daher wohl eher durchsetzen:
Ich belasse den urspünglichen Dateinamen (auch wenn nicht mehr akt.)
in de Reg und kopiere eine ggf anders heissende msi Datei vor dem
Aufruf in das Temp Verzeichnis, gebe dieser den Ursprungsnamen
und rufe es dort mit diesem zuletzt verwendeten Dateinamen auf.

Ansonsten probiere ich hier noch ob ich dem Windows Installer
nicht klar machen kann, das er diese Werte ignorieren bzw. neu
schreiben soll - schau'n wa mal.. - eilt ja nicht soo sehr

XML 3.0 SP7 ist übrigens ebenso betroffen

**Lenge** · 24.11.2005, 16:20

Notiz am Rande: Ich habs mehrmals probiert, wie schon vermutet funktioniert manuelles Deinstallieren und Neuinsten per Updater auf allen PCs.

Wenn der Updater angepasst wird, würd ich dennoch eher Variante 1 bevorzugen, weil das Problem bei Variante 2 IMO nur umgangen, aber nicht gelöst wird:

Ursache des Problems ist ja, dass bei alten Versionen des Updaters die Dateien manuell unbenannt werden mussten (bzw. konnten) und daher ein "falscher" Dateiname (bzw. nicht der original von MS verwendete) in der Reg eingetragen wurde. Bei Variante 2 verbleibt dieser "falsche" Name in der Registry bestehen, d. h. auch ein späteres manuelles Überinstallieren mit der MS-Originaldatei führt erneut zum Fehler.

Variante 1 wäre zwar ein Schreibzugriff in die Reg, aber dieser "verbiegt" ja nichts, sondern korrigiert einen vorhandenen "Fehleintrag", der aus dem Anwenden eines alten PostSP-Updaters herrührt. Danach ist das Problem dann dauerhaft gelöst, d. h. man kann hinterher sowohl mit Hilfe des PostSP-Updaters als auch von Hand mit der MS-Originaldatei fehlerfrei überinstallieren.

Da bei alten PostSP-Updatern regelmäßig fast alle opt. Module umbenannt wurden, vermute ich, dass neben den beiden XMLs noch eine Reihe weiterer Module betroffen sein dürften.

**HeikoBerlin** · 24.11.2005, 16:37

> dass neben den beiden XMLs noch eine Reihe
> weiterer Module betroffen sein dürften.

Ausser den beiden XML ist mir nix aufgefallen.. alle akt. probiert

Es gibt und gab zwar mehr msi Dateien die installiert werden/wurden
jedoch sind die Anderen als exe verpackt und entpacken sich zu immer
gleichbleibenden Dateinamen in Temp, dabei gibt's das Problem nicht.

Hast schon Recht, das die o.g. Variante 1 "sauberer" wäre
(die theoretische Variante 3 -mittels Aufruf- ist nicht anwendbar)
Mich würde ja auch nur stören das ich nicht mehr behaupten kann:
"Der Updater selbst ändert gar nichts" - aber wenn's keinen stört..
..wäre ja auch NUR dann wenn eine opt. msi Datei zuvor mit anderem
Dateinamen schonmal installiert wurde und es dennoch aktiviert wird.
Wenn's keinerlei Widerspruch gibt bin ich überzeugt.