After I have already dealt very intensively with Windos 10 and compatibility issues in 2015, it is actually time to revisit this piece of my own troubleshooting and publish it again. As stupid as it may sound – nothing has changed so far. Only Skype has become almost unusable by now, but that’s a completely different topic. Even in 2023 you are confronted with seemingly unsolvable problems every now and then. And what is described here is unfortunately still true, even with Windows 11.
The crux with .NET as only one example of many
Today’s example is really only one example of many, because you know it. If you have really ventured into the registry, then it happens not so rarely that you, although you are logged in with the adminstrator account, can not change or delete certain entries. But let’s get to the example. The .NET framework now runs like a red thread through help forums and grief boxes, although to Microsoft’s relief we also want to state fairly that many problems that occur are rather due to the ignorance or negligence of the programmers, who deal very superficially with the version queries.
Major version, minor version or build – many a setup or program module can only badly do something with newer versions within the same major version. Now, it is not the case that this exclusively affects any forest and meadow programs, but also products of such renowned software manufacturers as Autodesk, for example! If you try to install one of the language packs for AutoCAD 2015 or newer under Windows 10, for example, you get this message from the Microsoft installer instead of the installation, including termination:
Now this does not only affect Autodesk, but also many other programs. If you think you can simply download and install .NET 4.5, you will be disappointed, because this setup reports that .NET 4.5 is already installed. It gets even more confusing when the setup intelligently tries to reload .NET during the installation process. If you are lucky, you will be rewarded with a program abort, the rest will end up in an endless loop.
The reason is simple: While, for example, with .NET 3.5 the service pack later logs in with 3.5.1 – we remember the differences between major and minor version and build – Windows 10 simply uses a different minor version. Thus, .NET 4.6 is used, which is theoretically backward compatible. It’s just stupid when the program-internal queries are stuck on 4.5 and only ignore the builds, but not the minor version.
Remedy with a registry hack
Important note: In the registry you should only make manual interventions if you a) know what you are doing and b) no other solution exists. This described here.
Nothing is impossible, even if we have to go a little further here. We therefore describe the procedure step by step and also explain how to set permissions in such a way that you get access to some keys and their values at all. But more about this in a moment. First we log in again as administrator (if you are logged in as a restricted user) and only then we click with the right mouse button on the start button:
After that we select in the popup menu the entry Execute and confirm this with a left-click. The Execute window opens, we now enter regedit and confirm this with Ok.
In the registry editor, we change to the following key in the tree display, which contains the installer values of the currently existing .NET versions and which is used by many programs for querying:
In the keys Client and Full hides the relevant value, which we now need to change. We also need to change the value specified below for the Client key also for the Full key. What we see here is the root of the evil, because the 4.6.xxxxx does not get us anywhere like this.
But if you now think you can simply change this value, even as an admin you will reach your limits and get this error message:
Missing rights and the TrustedInstaller
We don’t want to get lost in details, but for understanding only this much: The Microsoft-Installer as a service is also a kind of user, but with full access rights, which exceed the rights of normal administrators by far. If the so-called TrustedInstaller Owns this key, then it cannot be changed without authorization. Really not? Let’s just lever out this protection now!
With a right-click on the key Client (for Full we do the same afterwards), open the popup menu and then left-click on the menu item Permissions.
In the now opening window with the permissions we don’t stay long and click there on Advanced.
We now see in the advanced security settings that the TrustedInstaller is the owner and the only one with full access. Even we as admin are only allowed to read values. Of course we want to change this and that’s why we now also click on Change:
We search for the appropriate object (in this case all users with administrator rights) by entering the word Administrators into the text field (1) and then clicking on Check Names (2).
We then confirm the whole thing with OK and we are one big step further.
Now we are the owners and no longer the TrustedInstaller. But we are still not completely finished, because we still do not have full rights. For this we first have to confirm the change of owner with OK and then return to the previous window.
From the list of users we now look for Administrators and select the list entry. After that we have to set in the permission field Full access must be checked. We confirm with Apply and/or OK and we are almost done.
Now we open the string value for Version and edit it.
We simply replace the Six with a Five and save this change with OK.
The result is now entered as hoped. We repeat the whole thing again for the key Full and can now install or use the desired software.
Reset to original and restore rights
In any case, it is recommended to set this version number back to the original value by simply resetting the value as just described to Six as just described. We still have the necessary rights. However, this measure should also be undone. So we repeat all the steps for changing the owner, but then we don’t enter Administrators but the object name shown below NT ServiceTrustedInstallerwhich is not listed in the search.
If you want to protect your own registry entries from spy-clickers and foreign programs, you can of course give any key the owner TrustedInstaller to any key. All this is often helpful, but at your own risk.
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 →