[English]Beim Upgrade von Windows 7 SP1 auf Windows 10 Version 1903 (dürfte bei Version 1909 das Gleiche sein), kann es anschließend zu Problemen kommen. Die Einstellungen-Seite sowie die Windows-Apps können nicht mehr geöffnet werden. Im Internet gibt es viele Vorschläge, die aber wohl selten funktionieren. Ein Blog-Leser hat mir seine Erkenntnisse geschickt, die vielleicht weiter helfen.
Anzeige
Blog-Leser Markus B. hatte mich schon Mitte August 2018 auf das Thema hingewiesen, ich habe es aber verbaselt. Beim Bereinigen meines Posteingangs bin ich dann erneut auf den Hinweis gestoßen (es geht nix verloren). Daher heute nachgereicht, denn ich gehe davon aus, dass bald eine Reihe Firmenrechner mit genau dieser Konstellation auf Windows 10 aktualisiert werden müssen.
Worum geht es genau?
Das Szenario betrifft Rechner, auf denen Windows 7 SP1 installiert ist, die dann aber möglichst per Inplace Upgrade auf Windows 10 Version 1903 (oder 1909) hochgerüstet werden sollen. Inplace Upgrade, um die Einstellungen und Programme zu behalten. Markus schreibt dazu:
Im Zuge meiner aktuellen Inplace Upgrades von vielen Win7 > Win10 Firmenrechnern bin ich erneut auf ein Problem gestoßen, über das ich im Internet auf keine passende Lösung gestoßen bin.
Zu den Details der zu aktualisierenden Firmenrechner mit Windows 7 SP1 hat mir Markus noch folgende Informationen gegeben:
Vorgabe sind div. Windows 7 Systeme die kein Auffälligkeiten zeigen. [Das] Inplace Upgrade wird mit aktuellen ISOs 1903 durchgeführt [und die Upgrades] scheinen auch problemlos zu klappen.
Eigentlich ein gängiger Vorgang in Firmen. Da es keine Fehlermeldungen gibt, muss ein Administrator davon ausgehen, dass daher auch alles mit dem installierten Windows 10 in Ordnung ist. Aber weit gefehlt, wie Markus schreibt.
Anzeige
Nach Fertigstellung der Win 10 Installation können die Windows Einstellungen (WIN+I, oder auch über Startmenü) nicht mehr geöffnet werden. Shortcuts (ms-settings:display etc…) klappen auch nicht.
So können z. B. auch die Anzeige-Einstellungen über Rechts-Klick Desktop > Anzeigeeinstellungen nicht geöffnet werden.
Die Windows 10-Shell ist also ziemlich kaputt, nachdem das Inplace Upgrade ausgeführt ist. Mit den Patchday-Problemen beim Startmenü kann das auch nicht zusammen hängen, da diese erst nach August 2019 auftraten und die Info von Markus sich auf frühere Zeitpunkte beziehen. Was noch seltsamer ist: Je nachdem welche Methode vom Benutzer gewählt wird, äußert sich das Ergebnis anders:
- WIN + I: Im Einstellungen-Fenster ist als Rahmen kurz zu sehen, aber das Fenster schließt sofort wieder.
- Anzeige-Einstellungen über Desktop: Popup Meldung: „Dateisystemfehler (-2147163901)" (siehe auch hier).
- WIN+R und „ms-settings:display": Der Datei ist kein Programm zum Ausführen dieser Aktion zugeordnet
Das zeigt einerseits, dass in der GUI der Windows 10-Shell intern wohl in so manchem Code-Teil keine saubere Fehlerprüfung erfolgt, sonst müssten konsistente Fehlermeldungen angezeigt werden.
Viele Fundstellen im Web, Lösungen helfen nicht
Markus wies in seiner Mail darauf hin, dass der Fehler auf verschiedenen Webseiten beschrieben wird. In diesem Microsoft Answers-Forenthread (English) wird das Ganze durch viele Nutzer diskutiert. Einen deutschsprachigen Thread aus Microsoft Answers gibt es hier sowie hier. In beiden Fällen haben sich die Leute damit beholfen, dass sie sich ein zweites Administratorkonto angelegt haben (sollte per Systemsteuerung oder netplwiz aus einem Administratorkonto gehen). Die Lösungsansätze die teilweise helfen sollen:
- Mit wsreset.exe (in der Eingabeaufforderung oder im Dialogfeld Ausführen eingeben) die Windows-Apps zurücksetzen.
- Eine Reparatur des Systems mit Dism ausführen lassen (siehe meinen Blog-Beitrag Windows 8: Komponentenstore reparieren).
- In der Windows PowerShell-Konsole den nachfolgenden Add-AppxPackage-Befehl ausführen lassen.
Der PowerShell-Befehl zum Reparieren der Einstellungen ist in einer administrativen Konsole (Rechtsklick auf die Start-Schaltfläche und Kontextmenübefehl wählen) folgendermaßen einzugeben (siehe):
powershell -ExecutionPolicy Unrestricted Add-AppxPackage -DisableDevelopmentMode -Register $Env:SystemRoot\ImmersiveControlPanel\AppxManifest.xml
Bleibt zu hoffen, dass das funktioniert und nicht mehr kaputt macht als es repariert. Falls der Store klemmt, den Befehl:
PowerShell -ExecutionPolicy Unrestricted -Command "& {$manifest = (Get-AppxPackage Microsoft.WindowsStore).InstallLocation + '\AppxManifest.xml' ; Add-AppxPackage -DisableDevelopmentMode -Register $manifest}"
ausführen lassen. Dann den ersten PowerShell-Befehl wiederholen. Blog-Leser Markus schreibt aber, dass bei ihm diese Ansätze bisher nicht geholfen haben. Das gilt wohl auch für diesen Praxistipp. Nach seiner Erklärung ist es auch logisch, dass die obigen Ansätze (außer ein neues Konto anlegen) i.d.R. nicht weiter führen.
Ursache und Lösung
Markus kam es seltsam vor, dass wenn ein Benutzer neu angelegt wird, klappt es mit dem Aufruf der Einstellungen-Seite und den Apps, beim ursprünglichen Konto treten dagegen die Fehler auf. Es muss also ein Benutzer-bezogenes Problem sein, irgend etwas wird nicht sauber beim Upgrade aufgesetzt. Da die Standardantwort 'Neuinstallation' in seiner Firmenumgebung nicht praktikabel ist, hat er sich auf Lösungssuche gemacht. Dabei hat er auch den Progmon von den Sysinternals verwendet. Er schreibt, dass er schon ein paar Stunden brauchte, aber schlussendlich die Lösung finden konnte.
Markus schreibt, dass beim Inplace Upgrade ein Unterschlüssel im Zweig HKCU der Registrierung scheinbar nicht korrekt nachbearbeitet wird (was auch erklärt, warum es bei einem neuen Benutzer funktioniert). Es geht um diesen Registrierungszweig:
HKEY_CURRENT_USER\Software\Microsoft\Windows\
CurrentVersion\Policies\Explorer
Der ProzessMonitor meldet beim Initialisieren der SystemSettings.exe (C:\Windows\ImmersiveControlPanel): ACCESS DENIED. Der Prozess der Shell zum Aufrufen der Einstellungen-App kann also nicht auf den Schlüssel zugreifen. Ein zum Test hinzugefügtes "Vollzugriff – Jeder" des Registierungsschlüssels hat das Problem sofort und rekonstruierbar beseitigt, die Einstellungen konnten problemlos geöffnet werden. Vielleicht hilft das Betroffenen weiter. Danke an Markus für den Hinweis.
Ähnliche Artikel
Windows 7 Reparatur, Inplace Upgrade bei SP1
Windows 10: Langsame (Inplace-)Upgrade-Installation beschleunigen
Windows 8: Komponentenstore reparieren
Windows 10 V 1511: Vorsicht vor Add-AppxPackage
Windows 10 V1709: Workaround für fehlende Apps …
Windows 10: Keine De- und Re-Installation des Microsoft Store
Fix: Microsoft Edge funktioniert nicht mehr oder stürzt ab
Windows 10: Sie benötigen eine neue App zum Öffnen von ms-windows-store
Windows 10: "Klasse nicht registriert" beim Öffnen von Fotos
Windows 10-Fix: Store startet / funktioniert nicht mehr
Anzeige
W10 ist die kippeligste Software der Menschheit. Hoch empfindlich … Ich rate jeden, das nur sauber zu installieren. Alles andere ist Murks!
Darum bleibe ich auch nach dem Supportende bei Windows 7.
Windows as a Service und damit Windows 10 sind der größte Murks.
Nur solltest du bedenken, dass es nach dem 14. Januar 2020 dann keine Sicherheitspatches/-fixes, Updates und Co. mehr gibt, wenn neue Sicherheitslücken in Windows 7 auftauchen. Das Risiko ist dann ganz auf deiner Seite. Und wie Uwe schon sagt: Wenn man Windows 10 frisch installiert, sind die Probleme weitaus kleiner als nach Upgrades.
Windows 7 wird auch nach dem Supportende mit
den nötigen Dingen versorgt, da bin ich mir sicher.
Das haben viele auch schon bei Windows XP vermutet… Mag sein, dass es ein, zwei Jährchen versorgt wird, aber darüber hinaus rechne ich nicht damit.
Eher auf Linux umsteigen.
Komischer Weise bin ich von den ganzen bisher aufgetauchten Update-Problemen verschont worden. Win10 läuft bei mir nach wie vor stabiler als Win7.
Für unseren Spezi @Hans Thölen, setze ich einen interessanten Link:
https://www.dedoimedo.com/computers/windows-7-end-of-support-guide.html
Gruß
nachlesbar z.B. dort:
https://www.deskmodder.de/blog/2019/12/07/windows-7-erweiterte-sicherheitsupdates-esu-erhalten-wird-moeglich-sein/
Ist auch hier im Blog am Rande thematisiert – das werde ich aber erst thematisieren, wenn das wirklich getestet werden kann. Aktuell läuft es auf den Austausch einer DLL hinaus, die testet, ob das Test-Update installiert werden kann. Wie das später mit Updates und der Prüfung der ESU-Keys ausschaut, da lege ich keine Hand ins Feuer.
Ok, mal vom W10-Bashing zurück zum eigentlichen Thema: Bei uns tritt das Problem exakt so auf. Wir werden das mal ausprobieren, danke schön.
Trifft dies wirklich nur bei Rechnern zu die in einer D0main sind ?
Mit welchem User wurde das Update denn initiiert ? Domain Admin ? Localer Admin ?
War der Virenscanner während des Updates noch installiert und aktiv ?
Wurden unter WIN7 vom DC Policies verteilt und dieser erst einmal bereinigt/zurückgesetzt um Problem zu vermeiden ? Wurde versucht das Gerät einmal aus der Domain zu nehmen, das Inplace-Update durchzuführen und dann wieder in die Domäne aufzunehmen ?
Wer von Win7 auf Win10 umsteigt, installiert ein völlig neues Betriebssystem, auch wenn es Gemeinsamkeiten bei der Codebasis gibt und beides unter der Marke "Windows" läuft. Das heißt erstens, dass das neue Betriebssystem am besten von Grund auf sauber installiert werden muss und dass sich zweitens die Frage stellt, für *welches* neue Betriebssystem man sich entscheidet, wenn ein Umstieg schon nicht zu vermeiden ist. Markentreue ist kein zweckdienliches Argument, sondern nur Bequemlichkeit, die den Zwecken des Anbieters dient.
Bei mir war es der Umstieg von Win7 auf Linux Mint; bei anderen mag es Win10 sein. Wer mit seinem OS nur privat unterwegs ist und keine Kundendaten zu schützen hat, kann in Win10 eine Option sehen, aber vielleicht nicht die einzige. Die gefühlt 1000 Geschmacksrichtungen von Linux, das stark vereinheitlichtes MacOS und das serverfreundliche BSD bieten zahlreiche Optionen über Win10 hinaus.
Hallo,
ich habe das gleiche Problem, würde gerne die Lösung von Markus ausprobieren,
habe aber keine Ahnung, wie das geht, bräuchte genaue Anweisung, wie und wo.
Bei einem anderen Konto auf dem Rechner funktioniert es nämlich reibungslos.
Öffne den Registrierungseditor (regedit) als Administrator, während Du am Rechner in dem betroffenen Account angemeldet bist.
Navigiere zu dem angegebenen Schlüssel
HKEY_CURRENT_USER\Software\Microsoft\Windows\
CurrentVersion\Policies\Explorer
Rechtsklick auf Zugriffsrechte, und der Gruppe "JEDER" den "Vollzugriff" einräumen.
Hallo,
1 Jahr später antworte ich hier. Konnte die anzeige Einstellungen nicht mehr öffnen, auch die Suche und die Starttaste funktionierten nicht mehr. Ganzes Win im Grunde unbenutzbar.
Hab den Tipp hier befolgt, hatte nur nei HKEY current user, keinen explorer im policies ordner, daraufhin bin ich in local machine, da war er. hab dann dort alle zugriffe auf vollzugriff gestellt und neugestartet. seitdem geht es wieder, danke!!!
werde trotzdem win neuinstallieren, nur so kann ichs noch ein paar tage länger hinauszögern. wollte nur mal sagen, dass der trick verbreitet werden sollte, hab das sonst nirgends so gefunden und alles andere hat nicht geklappt. vielen danke nochmal!
Nach Upgrade von Server 2012 R2 auf 2022
Gleiches Problem andere Lösung:
Ich habe ebenfalls alle genannten Tips probiert. Keine Lösung. Problem betraf auch einen neu angelegten user.
EInträge in der Ereignisanzeige (comruntime 18214 und DCOM 10020) deuteten auf Berechtigungsprobleme.
Lösung: Start, Programme, Verwaltung, Komponentendienste, Konsolenstamm, Komponentendienste, Computer, Eigenschaften von Arbeitsplatz, COM-Sicherheit, Start- und Aktivierungsberechtigungen, Standard bearbeiten
HIer fehlt der Eintrag "Selbst" mit "lokaler Zugriff" und "remote Zugriff"
Neustart
-> alles OK