Nachdem ich mich bereits 2015 sehr intensiv mit Windos 10 und Kompatibiltätsproblemen auseinandergesetzt habe, ist es eigentlich an der Zeit, dieses Stück der eigenen Fehlersuche noch einmal zu überarbeiten und erneut zu veröffentlichen. So blöd es klingen mag – aber es hat sich bisher nichts geändert. Nur Skype ist mittlerweile fast unbenutzbar geworden, aber das ist ein komplett anderes Thema. Selbst 2023 sieht man sich immer mal wieder vor vermeintlich unlösbare Probleme gestellt. Und das hier Beschriebe gilt leider immer noch, sogar bei Windows 11.
Die Crux mit .NET als nur ein Beispiel von vielen
Das heutige Beispiel ist wirklich nur ein Beispiel von vielen, denn man kennt das ja. Hat man sich wirklich in die Registry vorgewagt, dann passiert es gar nicht so selten, dass man, obwohl man mit dem Adminstratorkonto eingelogt ist, bestimmte Einträge nicht ändern oder löschen kann. Doch kommen wir zum Beispiel. Das .NET-Framework zieht sich mittlerweile wie ein roter Faden durch Hilfe-Foren und Kummerkästen, wobei wir zu Microsofts Entlastung fairerweise auch festhalten wollen, dass viele auftretenden Probleme eher auf das Unwissen oder Nachlässigkeit der Programmierer zurückzuführen sind, die sehr oberflächlich mit den Versionsabfragen umgehen.
Major-Version, Minor-Version oder Build – so manches Setup oder Programmodul kann mit neueren Versionen innerhalb der gleichen Major-Version nur schlecht etwas anfagen. Nun ist es aber nicht so, dass dies ausschließlich irgendwelche Wald- und Wiesen-Programme betrifft, sondern auch Produkte solch namhafter Softwarehersteller wie beispielsweise Autodesk! Wer unter Windows 10 beispielsweise versucht, eines der Sprachpakete für AutoCAD 2015 oder neuer nachzuinstallieren, der bekommt statt der Installation vom Microsoft Installer diese Meldung samt Abbruch:
Nun betrifft dies nicht nur Autodesk, sondern auch viele andere Programme. Wer nämlich denkt, er könne .NET 4.5 einfach extra herunterladen und installieren, der wird arg enttäuscht, denn dieses Setup meldet, das .NET 4.5 bereits installiert sei. Noch wirrer wird es, wenn das Setup intelligenterweise versucht, .NET während des Installationsprozesses nachzuladen. Wer Glück hat, wird mit dem Programmabbruch belohnt, der Rest landet dann in einer Endlosschleife.
Der Grund ist simpel: Während beispielsweise bei .NET 3.5 das Service-Pack später mit 3.5.1 – wir erinnern an die Unterschiede von Major- und Minor-Version und Build – anmeldet, nutzt Windows 10 schlicht und ergreifend eine andere Minor-Version. So kommt .NET 4.6 zum Einsatz, was theoretisch abwärtskompatibel ist. Dumm nur, wenn die programminternen Abfragen auf 4.5 festgetackert sind und nur die Builds, aber nicht die Minor-Version ignorieren.
Abhilfe durch einen Registry-Hack
Wichtiger Hinweis: In der Registry sollte man nur dann manuelle Eingriffe tätigen, wenn man a) weiß, was man tut, und b) keine andere Lösung existiert. Das hier beschrieben.
Nichts ist unmöglich, auch wenn wir hier ein wenig weiter ausholen müssen. Wir beschreiben deshalb die Vorgehensweise Schritt für Schritt und erklären auch, wie man Berechtigungen so setzt, dass man überhaupt den Zugriff auf manche Schlüssel und deren Werte bekommt. Doch dazu gezwungenermaßen gleich noch mehr. Zunächst melden wir uns als Administrator erneut an (falls man als eingeschränkter Nutzer angemeldet sein sollte) und erst danach klicken wir mit der rechten Maustaste auf den Start-Button:
Danach wählen wir im Popup-Menü den Eintrag Ausführen und bestätigen dies mit einem Links-Klick. Das Ausführen-Fenster öffnet sich, wir geben nun regedit ein und bestätigen dies mit Ok.
Im Registrierungs-Editor wechseln wir in der Baumanzeige zu folgendem Schlüssel, der die Installer-Werte der aktuell vorhandenen .NET-Versionen enthält und der von vielen Programmen zur Abfrage genutzt wird:
In den Schlüsseln Client und Full verbirgt sich der betreffende Wert, den wir jetzt ändern müssen. Wir müssen zudem den im Folgenden für den Schlüssel Client beschriebenen Vorgang auch für den Schlüssel Full wiederholen. Was wir hier sehen, ist der Grund des Übels, denn die 4.6.xxxxx bringt uns so nicht weiter.
Wer nun aber glaubt, diesen Wert einfach ändern zu können, wird auch als Admin an seine Grenzen stoßen und diese Fehlermeldung erhalten:
Fehlende Rechte und der TrustedInstaller
Wir wollen uns nicht im Detail verlieren, aber zum Verständnis nur so viel: Auch der Microsoft-Installer ist als Service eine Art Nutzer, allerdings mit Vollzugriffsrechten, die die Rechte der normalen Adminstratoren weit übersteigen. Ist der sogenannte TrustedInstaller Besitzer dieses Schlüssels, dann lässt sich dieser ohne Berechtigung auch nicht ändern. Wirklich nicht? Wir hebeln diesen Schutz jetzt einfach mal aus!
Mit einem Rechts-Klick auf den Schlüssel Client (für Full machen wir es danach genau so), öffnen wir das Popup-Menü und wählen dann per Links-Click den Menüpunkt Berechtigungen.
Im sich nun öffenenden Fenster mit den Berechtigungen halten wir uns gar nicht lange auf und klicken dort auf Erweitert.
Wer sehen nun in den erweiterten Sicherheitseinstellungen, dass der TrustedInstaller der Besitzer ist und als einziger Vollzugriff besitzt. Selbst wir als Admin dürfen nur Werte lesen. Das wollen wir nun natürlich ändern und genau deshalb klicken wir nun auch auf Ändern:
Wir suchen das passende Objekt (in diesem Fall alle Nutzer mit Administrator-Rechten), indem wir das Wort Administratoren in das Textfeld eingeben (1) und danach auf Namen überprüfen klicken (2).
Das Ganze bestätigen wir dann noch mit OK und schon sind wir einen großen Schritt weiter.
Nun sind wir also die Besitzer und nicht mehr der TrustedInstaller. Doch ganz fertig sind wir damit immer noch nicht, denn wir besitzen immer noch keine vollen Rechte. Dafür müssen wir zunächst den Besitzer-Wechsel mit OK bestätigen, um danach ins vorige Fenster zurückzukehren.
Aus der Benutzerauflistung suchen wir uns nun Administratoren heraus und markieren den Listeneintrag. Danach muss im Berechtigungs-Feld Vollzugriff noch der Haken gesetzt werden. Wir bestätigen mit Übernehmen und/oder OK und sind auch schon fast fertig.
Jetzt öffnen wir den Zeichenfolge-Wert für Version und editieren diesen.
Wir ersetzen einfach die Sechs durch eine Fünf und speichern diese Änderung mit OK.
Das Ergebnis ist nun wie erhofft eingetragen. Wir wiederholen das Ganze noch einmal für den Schlüssel Full und können nun die gewünsche Software installieren oder nutzen.
Zurücksetzen ins Original und Rechte wiederherstellen
Es empfiehlt sich in jedem Fall, diese Versionsnummer wieder auf dem Ausgangswert hochzusetzen, indem man einfach den Wert, wie eben beschrieben, wieder auf Sechs setzt. Die nötigen Rechte besitzen wir ja noch. Allerdings sollte auch diese Maßnahme wieder rückgängig gemacht werden. Wir wiederholen also die ganzen Schritte für die Änderung des Besitzers, tragen dann aber eben nicht Administratoren ein, sondern den unten abgebildeten Objektnamen NT ServiceTrustedInstaller, den man über die Suche so nicht aufgelistet bekommt.
Wer eigene Registry-Einträge vor Spitzklickern und fremden Programmen schützen möchte, der kann natürlich jedem beliebigen Schlüssel den Besitzer TrustedInstaller zuweisen. All dies ist oftmals hilfreich, geschieht aber auf eigene Gefahr.
12 Antworten
Kommentar
Lade neue Kommentare
Mitglied
Urgestein
Urgestein
Neuling
Urgestein
Veteran
1
Veteran
Urgestein
Mitglied
Urgestein
Mitglied
Alle Kommentare lesen unter igor´sLAB Community →