Wenn ein Plugin sich nicht registrieren lässt: Der wahre Grund hinter einem MSI-Fehler 1603

Ein Kunde aus dem Gesundheitswesen bat um Unterstützung bei einem hartnäckigen Installationsproblem: Ein 3D-Erweiterungsmodul für die zahnärztliche Bildgebungssoftware Sidexis 4 ließ sich auf einem neu aufgesetzten Windows-11-Rechner partout nicht installieren. Der Windows-Installer brach jedes Mal mit dem berüchtigten Fehlercode 1603 ab – einer Sammelmeldung, die für sich genommen fast nichts über die eigentliche Ursache verrät. Der Fall zeigt gut, warum man bei "1603" nicht aufhören sollte zu fragen.

Der erste Blick: nur die Hülle des Fehlers

Ein Blick ins Ereignisprotokoll und die anwendungseigenen Logdateien der Installationsquelle brachte die erste konkrete Fehlermeldung zutage:

[ERROR] PIMan: Register failed, GetReserved PlugIn
        ...\Plugin\XG3D.exe, sc=-2147417851 !
[ERROR] PIMan: Register failed, file
        ...\Plugin\XG3D.exe
        doesn't contain any valid plugin info !
[ERROR] PIMan: PI registration failed
        ...\Plugin\XG3D.exe !

Das Muster dahinter: Das Installationspaket kopiert die Programmdateien zunächst erfolgreich, ruft danach aber den herstellereigenen Plugin-Manager der Bildgebungssoftware auf, damit dieser das neue Modul als Erweiterung registriert. Genau diese Registrierung schlägt fehl – der Plugin-Manager bekommt vom frisch installierten Programm keine verwertbaren Plugin-Informationen zurück. Der Installer wertet das als fehlgeschlagene Aktion und bricht mit 1603 ab. Der Fehlercode 1603 ist also nur die Hülle; der eigentliche Fehler liegt eine Ebene tiefer, in der Kommunikation zwischen zwei Komponenten.

Der Statuscode sc=-2147417851 entschlüsselt sich als RPC_E_SERVERFAULT – ein interner COM-Server ist bei der Anfrage abgestürzt oder hat nicht ordnungsgemäß geantwortet. Auffällig dabei: Ein anderes Erweiterungsmodul derselben Software zeigte kurz zuvor exakt dasselbe Registrierungsproblem. Zwei unterschiedliche Plugins, derselbe Fehler – ein deutliches Indiz dafür, dass nicht ein einzelnes, defektes Installationspaket die Ursache war, sondern etwas Grundsätzlicheres in der Umgebung.

Der zweite Blick: eine Ablaufverfolgung auf Systemebene

Verbose-Logging des Installers half nicht entscheidend weiter, da der eigentliche Fehler außerhalb des MSI-Prozesses selbst liegt. Der nächste Schritt war deshalb eine systemnahe Ablaufverfolgung (Process Monitor) direkt während des Installationsversuchs, gefiltert auf den Prozess des neuen Plugins. Aus mehreren tausend aufgezeichneten Dateisystem- und Registry-Zugriffen ließen sich die entscheidenden Zeilen isolieren:

...  ProgID SIDEXISNG.OptionsManager  -> CLSID gefunden
...  Thread Create, OLE/RPC-Marshalling für IDispatch           OK
...  eigene CLSID ...\LocalServer32                              OK
...  HKCR\WOW6432Node\CLSID\{88D969C0-...}   NAME NOT FOUND
...  HKCR\CLSID\{88D969C0-...}               NAME NOT FOUND
...  QueryDirectory  ...\Plugin\XGDataConfig.xml    NO SUCH FILE
...  Plugin initializing… / Version 1.6.0.56
...  GetReserved called…
...  Process Exit, Exit Status 0

Die CLSID {88D969C0-F192-11D4-A65F-0040963251E5} steht für Msxml2.DOMDocument.4.0 – eine Komponente aus MSXML 4.0, dem vierten, längst historischen Major-Release von Microsofts XML-Bibliothek. Diese Klasse wird in beiden Registry-Sichten gesucht, der 32-Bit- und der 64-Bit-Ansicht, und in keiner von beiden gefunden. Unmittelbar danach findet das Plugin auch seine eigene Konfigurationsdatei nicht mehr, protokolliert noch den Einstieg in seine Initialisierungsroutine – und beendet sich dann sauber, mit Exit-Status 0. Kein Absturz, kein Crash-Dump, einfach ein stiller, kontrollierter Rückzug, weil eine Voraussetzung fehlte.

Die Ursache: eine Komponente, die Windows nie mitbringt

Ein Vergleich mit einer bekannt funktionierenden Umgebung derselben Software bestätigte den Verdacht restlos: Dort war msxml4.dll im System-Verzeichnis vorhanden, korrekt registriert und mit vollständigen Registry-Einträgen samt Policy-Schlüsseln versehen. Auf dem neuen Rechner fehlte die Datei komplett – dort waren nur die deutlich neueren MSXML-Versionen 3 und 6 vorhanden, die Windows von Haus aus mitbringt.

Der entscheidende Punkt: MSXML 4.0 war nie Bestandteil von Windows. Es musste immer separat installiert werden. Auf älteren, über Jahre gewachsenen Rechnern lag es oft noch aus einer früheren Installation herum – ein stiller Mitbewohner, an den niemand mehr dachte. Ein frisch aufgesetztes Windows 11 bringt diese Komponente nicht mit, und das Installationspaket des 3D-Plugins selbst liefert sie ebenfalls nicht mit. Eine vollständige Durchsuchung der Installationsablage nach Dateien mit Bezug zu MSXML lieferte konsequent keine Treffer. Das Plugin setzt eine Komponente voraus, die es selbst nicht mitbringt und die auf modernen Windows-Installationen schlicht nicht mehr vorhanden ist.

Die Korrektur – und ein Kompromiss, den man offen ansprechen muss

Die Lösung war im Kern einfach: MSXML 4.0 Service Pack 3 über das offizielle Installationspaket nachinstallieren, danach die Registrierung des Plugins erneut anstoßen. Ein Detail dabei ist wichtig für jeden, der vor einem ähnlichen Problem steht: Die fehlenden Dateien einfach von einem funktionierenden Rechner zu kopieren, wäre der falsche Weg gewesen. MSXML 4.0 braucht neben der reinen DLL auch korrekt gesetzte Registry- und Policy-Schlüssel, die nur ein ordnungsgemäßer Installationslauf zuverlässig anlegt.

Zur Ehrlichkeit gehört aber auch ein Kompromiss, den man nicht verschweigen sollte: MSXML 4.0 ist seit April 2014 offiziell abgekündigt und erhält seither keine Sicherheitsupdates mehr. Wer diese Komponente heute nachinstalliert, holt sich bewusst eine über ein Jahrzehnt alte, nicht mehr gepflegte Bibliothek auf einen aktuellen Rechner. Das ist keine Empfehlung, die man leichtfertig ausspricht – es ist schlicht die Voraussetzung, die dieses konkrete Plugin nun einmal hat. Der sauberere Weg ist, beim Softwarehersteller gezielt nachzufragen, ob es inzwischen einen Build des Plugins gibt, der ohne diese veraltete Abhängigkeit auskommt. Mit der Ablaufverfolgung als Beleg lässt sich eine solche Anfrage präzise und nachvollziehbar stellen, statt nur "es installiert nicht" zu melden.

Nach der Nachinstallation lief die Registrierung des Plugins beim nächsten Versuch fehlerfrei durch. Weil derselbe Rechnertyp in der Praxis mehrfach im Einsatz war, wurde vor dem flächendeckenden Rollout zunächst auf jedem betroffenen Arbeitsplatz einzeln geprüft, ob dieselbe Komponente fehlte, bevor die Nachinstallation gezielt dort erfolgte, wo sie tatsächlich nötig war – statt pauschal auf allen Rechnern vorsorglich einzugreifen.

Fazit

Drei Lehren, die sich auf ähnliche Installationsprobleme übertragen lassen:

Erstens: Ein generischer Fehlercode wie 1603 beschreibt nur, dass eine Aktion während der Installation fehlgeschlagen ist, nicht warum. Die eigentliche Ursache steckt fast immer eine Ebene tiefer, in den anwendungseigenen Protokolldateien oder – wenn diese nicht reichen – in einer systemnahen Ablaufverfolgung.

Zweitens: Wenn derselbe Fehler bei mehreren, voneinander unabhängigen Komponenten auftritt, deutet das auf eine gemeinsame, tiefer liegende Ursache hin – nicht auf ein einzelnes defektes Paket. Diese Beobachtung hat hier wertvolle Zeit gespart, weil sie die Suche von Anfang an in die richtige Richtung gelenkt hat.

Drittens: Nicht jede fehlende Abhängigkeit lässt sich bedenkenlos nachinstallieren. Wenn die Lösung eine veraltete, nicht mehr gepflegte Komponente ist, gehört die Abwägung zwischen kurzfristiger Funktionsfähigkeit und langfristigem Risiko offen auf den Tisch – und die Rückfrage beim Hersteller, ob es einen zeitgemäßeren Weg gibt, in jedes Ticket.

Dieser Beitrag beschreibt ein anonymisiertes, reales Fallbeispiel aus unserem IT-Support-Alltag. Konkrete Kundennamen, Gerätebezeichnungen, Dateipfade und Uhrzeiten wurden entfernt oder verallgemeinert.