[English]Manche Windows Updates werden von Microsoft als permanent eingestuft und besitzen keine Option zum Deinstallieren. Im Blog-Beitrag zeige ich, wie man das Problem lösen und die Pakete doch noch deinstallieren kann. Die Screenshots und das Beispiel stammen aus Windows 7, die Technik lässt sich aber auch unter Windows 8.1 und Windows 10 verwenden.
Anzeige
Das Problem kurz angerissen
Gibt es mit einem installierten Update unter Windows Probleme, kann man über die Systemsteuerung zu Programme und Funktionen gehen. Klickt man dann auf Installierte Updates anzeigen lässt sich unter Installierte Updates die Liste der installierten Pakete einsehen.
Markiert man ein Update, wird eine Schaltfläche Deinstallieren eingeblendet (siehe obigen Screenshot), über den man das Paket auch wieder deinstalliert bekommt. Bei Problemen die letzte Rettung bzw. eine Diagnosemöglichkeit, um herauszufinden, ob ein Update Fehlfunktionen verursacht.
Aber das funktioniert nicht immer. Manche Updates besitzen keine Option zum Deinstallieren. Das ist mir erstmals beim Servicing Stack-Update KB3177467 vom 11. Oktober 2016 klar geworden (siehe Windows 7: Servicing Stack-Update KB3177467 (11.10.2016).
Anzeige
Geht man über die Systemsteuerung auf Programme und Funktionen –> Installierte Updates anzeigen und wählt das Update aus, wird keine Schaltfläche Deinstallieren in der Kopfzeile (rechts neben Organisieren) eingeblendet (siehe obiger Screenshot).
Kommt es zu Problemen, bei denen man das betreffende Paket vermutet, lässt sich dieses offiziell nicht deinstallieren. Man kann also nichts deinstallieren. Die Lösung besteht darin, Windows per Systemwiederherstellung auf den Punkt vor der Update-Installation zurück zu rollen. Alternativ ließe sich ein Systembackup, erstellt vor der Update-Installation, zurückspielen. Was aber, wenn beide Optionen nicht zur Verfügung stehen?
Warum und wie macht Microsoft das?
Manche Updates greifen tief ins System ein und sind Voraussetzung, um weitere Updates zu installieren. Dann erklärt Microsoft die Updates in den betreffenden .msu-Dateien als "permanent", im Gegensatz zu den üblicherweise als "removable" eingestuften sonstigen Updates. In den KB-Artikeln wird gelegentlich auf diesen Umstand hingewiesen (siehe hier).
Die Steuerung, welchen Status ein Update erhält, erfolgt über sogenannte .mum-Dateien (mum steht für Microsoft Update Manifest). Die .mum-Dateien sind Bestandteil der .msu-Pakete und werden nach der Installation im Ordner C:\Windows\servicing\Packages\ abgelegt.
Es handelt sich um XML-Dateien, in denen jeweils vermerkt ist, welche Pakete das Update benötigt, ob Sprachanpassungen oder ein Neustart nach der Installation erforderlich sind.
Ich habe einige Einträge in obigem Screenshot mit Pfeilen markiert. Die Steuerung, ob ein Update permanent, also nicht deinstallierbar ist, erfolgt über das XML-Attribut:
permanence="permanent"
Ein Attributwert
permanence="removable"
oder ein fehlendes Attribut ermöglicht dagegen das Deinstallieren eines Pakets per Systemsteuerung oder mittels dism (Windows 8 und höher).
Dies Informationen finden sich in diversen Webseiten, wie z.B. hier (extrem kurz), in diesem MS-Answers-Forenthread (Post von PhilipdayWF) – und ist ausführlicher in deutsch bei deskmodder.de hier für Windows 8.1 beschrieben.
Stopp: Das Entfernen eines permanenten Updates durch den nachfolgend beschriebenen Eingriff birgt aber die Gefahr, dass sich später ausgerollte Updates nicht mehr installieren lassen. Für KB3177467 verweise ich auf den Kommentar von André (sowie diesen und diesen Kommentar von ihm), der auf das Risiko einer Servicing Stack-Update-Deinstallation hinweist. Dies kann bei der Installation neuer Servicing Stack-Updates zu Fehlern (STATUS_SXS_COMPONENT_STORE_CORRUPT) führen, wenn Bezug auf die entfernten Pakete genommen wird.
Hinweise zur Analyse von Update-Fehlern bei Servicing Corruption finden sich übrigens im Technet-Beitrag Advanced guidelines for diagnosing and fixing servicing corruption. Die Analyse von Update-Fehler ist hier beschrieben. Hinweise zur Struktur der in .msu-Dateien enthaltenen .cab-Dateien hat jemand hier zusammen getragen.
Ein Paket deinstallierbar machen
Sofern die obige Warnung berücksichtigt wird (ggf. einen Wiederherstellungspunkt oder ein Backup anfertigen), kann man die obigen Hinweise verwenden, um die betreffende .mum-Datei anzupassen. Da es sich um XML-Dateien handelt, reicht der Windows-Editor zum Ändern.
Allerdings gibt es ein Problem: Nur der TrustedInstaller-Dienst hat Vollzugriff auf die .mum-Dateien. In den oben verlinkten Webseiten gibt es dann den lapidaren Hinweis, die Berechtigungen der .mum-Dateien anzupassen, um diese zu editieren. Letztendlich läuft es aber auf die Übernahme des Besitzes hinaus, um unter einem Benutzerkonto die .mum-Dateien ändern zu können. So etwas ist komplex und der "Ansatz mit der Brechstange" gefällt mir nicht, insbesondere, weil es auch anders geht.
Nachfolgender Ansatz nutzt den Trick, den Windows-Editor Notepad.exe mit den Privilegien bzw. im Kontext des TrustedInstallers auszuführen.
1. Laden Sie sich von der Seite sodrum.org die portable Freeware PowerRun herunter und entpacken Sie das ZIP-Archiv in einen Ordner.
2. Starten Sie PowerRun, wählen den Eintrag notepad.exe mit einem Rechtsklick an und verwenden Sie den Kontextmenübefehl Datei laufen.
3. Wählen Sie im Editor Datei – Öffnen und stellen Sie den Dateifilter auf Alle Dateien (*.*).
4. Navigieren Sie in der Symbolleiste des Dialogfelds Öffnen zum Ordner C:\Windows\servicing\Packages.
5. Geben Sie im Suchfeld den Suchbegriff (z.B. KB3177467*.mum) ein, um die betreffenden Dateien zu finden.
6. Wählen Sie die erste Datei an und klicken Sie auf die Schaltfläche Öffnen, um die .mum-Datei zu laden.
7. Suchen Sie den Eintrag permanency="permanent" und ändern Sie diesen in den Wert permanency="removable"
8. Im Anschluss speichern Sie die Änderung (z.B. durch Schließen des Editorfensters). Das Speichern sollte klappen, da der Editor mit den Privilegien des TrustedInstaller läuft.
9. Wiederholen Sie die obigen Schritte mit allen im Dialogfeld Öffnen bei der Suche angezeigten .mum-Dateien (im konkreten Beispiel sind es drei Dateien).
Wenn die obigen Schritte korrekt ausgeführt wurden, lässt sich das Update-Paket mit folgenden Schritten deinstallieren.
1. Gehen Sie über die Systemsteuerung auf Programme und Funktionen –> Installierte Updates anzeigen.
2. Wählen Sie das gewünschte Update aus und klicken Sie auf die Schaltfläche Deinstallieren.
Beim Update KB3177467, welches weiter oben als nicht deinstallierbar aufgeführt wurde, ist jetzt die Schaltfläche Deinstallieren sichtbar. Man kann die Deinstallation auch in einer administrativen Eingabeaufforderung mit folgendem Befehl veranlassen:
wusa /uninstall /kb:3177467 /quiet /norestart
wobei 3177467 für die KB-Nummer des Updates steht (siehe auch hier und hier). Die hier beschriebenen Ansätze funktionieren bei allen Windows-Versionen, von Windows 7 bis Windows 10.
Im Anschluss kann man das System auf beschädigte Systemdateien prüfen (mit sfc /scannow) oder ab Windows 8 den Komponentenstore überprüfen lassen (siehe Windows 8: Komponentenstore reparieren).
Abschließende Hinweise: Eingangs hatte ich diesen deskmodder.de-Beitrag erwähnt – und hier im Blog gab es ebenfalls entsprechende Kommentare, dass man das Servicing Stack Update KB3177467 mittels der .mum-Eingriffe deinstalliert habe. Der deskmodder-Beitrag bezieht sich auf einen speziellen Fall – die dort aufgeführten Registrierungseingriffe sind nicht erforderlich.
Die Eingriffe und Deinstallation erfolgen auf eigene Gefahr – insbesondere gilt mein eingangs gegebener Hinweis, dass es nach der Deinstallation von Servicing Stack Updates zu Problemen bei weiteren Update-Installationen kommen kann. Sofern man aber ein System mit Fehlfunktionen hat, kann man mit obigem Ansatz zumindest klären, ob es am fraglichen Update hängt. Falls nicht, ließe sich das Update per Offline-Installation erneut installieren oder ein Zurückrollen per Systemwiederherstellung auf den Zustand vor Deinstallation des Updates versuchen. Vielleicht hilft der Blog-Beitrag daher Betroffenen weiter.
Ähnliche Artikel
Windows 7: Servicing Stack-Update KB3177467 (11.10.2016)
Windows 7: Servicing Stack-Update KB3177467 – Korrekturen
Oktober-Patchday: Einstieg in Windows 7/8.1 Rollup-Updates
Patchday-Infos: Was ab Oktober für Windows 7/8.1 kommt
Windows 10: Upgrade-Fehler analysieren und beheben
System auf beschädigte Systemdateien prüfen
Windows 8: Komponentenstore reparieren
Anzeige
Danke! Sehr interessanter Beitrag, auch der Hinweis auf das Tool "PowerRun", welches ich bislang nicht kannte.
Bedanke mich ebenfalls für die Ausführungen und den Softwaretipp.
Grüße
Hallo Hr. Borns. Im Titel hätte man vielleicht auch den Bezug aufs OS erwähnen können.
"Windows-Updates: Deinstallation nicht entfernbarer Pakete unter Windows 7 erzwingen"
oder
"Windows 7 -Updates: Deinstallation nicht entfernbarer Pakete erzwingen"
Ansonsten ein Danke natürlich auch von meiner Seite für diesen Tip!
Steht im Artikel und ist generell mit "Windows" verschlagwortet: d.h. der Artikel gilt für Windows 7 bis Windows 10! Ich habe jetzt aber noch einen Satz zur Klarstellung im Textanriss aufgenommen – danke für den Hinweis, dass das nicht ganz klar rausgekommen ist.
Ok, das gilt also doch für Windows 7 bis Windows 10. Gut zu wissen. Danke. Denn irgendwann – spätestens ab dem Jahr 2020 – werde wohl auch ich mich mit diesem Windows 10 anfreunden müssen, zwangsläufig.
Funktioniert! War wohl meine letzte Chance, ohne Neuaufsetzten des Betriebssystems, mit der WIN 10 -1607- Version weiter zu arbeiten. Diese Version funktioniert an meinem Notebook perfekt bis zum August 2017 Update. Jetzt im Dezember habe ich leichtsinnigerweise mal die neuesten Updates für die 1607 Version installieren lassen.
Großer Fehler meinerseits!! Ich musste erschreckend feststellen, dass Microsoft ihre privaten Win 10 Home Anwender nun endgültig komplett entmündigt hat. Die neuen Updates haben dafür gesorgt, dass mein deaktivierter Dienststatus "Windows-Update" einfach immer ignoriert worden ist, und sich diverse Folgeupdates inklusive Funktionsupdate 1709 runtergeladen haben!!! Das ist wohl die größte Frechheit, die sich fu..ing Microsoft erlauben kann?? (Mein Notebook funktioniert bis Version 1607 einwandfrei, alles darüber gab/gibt gravierendste Probleme!!)
Dank Ihres Tutorials konnte ich ein permanentes Update von ~ Okt.2017 (KB4049065) deinstallieren, sodass ich jetzt wieder auf dem Stand, wie vorher bin. War ganz schöner Aufwand, da ich ungefähr 60-70 Einträge (Packages) ändern musste. Zu allem Überfluss hatte sich auch noch währenddessen eine Microsoft Update App ganz heimlich in mein System installiert, wodurch mein PC automatisch die neueste Win 10 Version (1709) runtergeladen hat. Zum Glück habe ich diese App heute entdeckt und sofort deinstalliert!!
Das Gute in meinem Fall ist nun, dass Ihre Warnung für zukünftige Updateprobleme bei mir tatsächlich eintrifft. Das neue Funktionsupdate konnte von MS nicht installiert werden!!! (Fehlercodemeldung) Für mich ein Grund zum Feiern, da alles nach August 2017 für mein 1607-System unakzeptabel ist!!!
Bleibt zu hoffen, dass ab heute der deaktivierte Diensstatus "Windows-Update" wieder dauerhaft so bleibt. Falls sich an der Microsoft-Update-Politik nichts gravierendes mehr ändert, war das mein letztes Betriebssystem dieser Firma.
PS: Wer mich nun auf das Microsoft eigene Tool wushowhide verweisen möchte: Das reicht nicht und hätte mir diese Eskapaden nicht erspart!!!
Super – danke!
Bei mir gibt es aber mehrere mum-Dateien von ein und demselben kb (kb4480970) und alle sind vom 02.01.2019.
Dieses KB4480970 lässt sich nicht deinstalieren, es installiert sich quasi immer wieder automatisch neu!
Kann mir aber nicht vorstellen, dass wenn das Update vom 02.01.19 ist, dass es mit meinem aktuellen Problem zusammenhängt.
Sobald mein Beitrag hier freigeschaltet ist seht ihr worum es mir geht:
https://www.borncity.com/blog/2019/01/09/netzwerkprobleme-mit-kb4480970-monthly-rollup/?unapproved=70782&moderation-hash=544ea3394a617be0c56ba75dcd0b0111#comment-70782
Leider finde ich keiner der Manifest-Dateien den "permanence"-String. Wenn ich diesen manuell mit permanence="removable" hinzufüge, ändert sich nichts. Es geht um das Update KB4054854 (.Net-Framework 4.7.1). Laut Microsoft (https://docs.microsoft.com/de-de/archive/blogs/connector_space/windows-server-2012-r2-uninstalling-net-framework-4-6-4-6-1-4-6-2-4-7-4-71) soll das sogar einfach so deinstallierbar sein…
Möglicherweise gibt dieser Forenthread die Antwort. In bestimmten Umgebungen ist das kein einfaches Update, sondern ein Inplace-Upgrade, was nicht deinstalliert werden kann. Aber vielleicht habe ich dass beim schnellen Querlesen falsch interpretiert (ist ja schließlich alles Neuland für mich).
Vielen Dank für diesen Hinweis!
Der Artikel führt über Umwege zum Blog von Aaron Stebner (https://docs.microsoft.com/de-de/archive/blogs/astebner/mailbag-how-to-revert-to-older-versions-of-the-net-framework-4-family), in dem er erklärt, daß .Net Versionen nicht parallel zueinander existieren. Somit kann ich durch Installation von .Net 4.8 die Version 4.71 entfernen. Damit habe ich die Anforderungen meines Software-Herstellers erfüllt, um weitergehende Hilfe bei der Fehlersuche zu erhalten.
Halllo allesamt,
ich versuchte dies auf ein frisch installiertes Windows 8.1 Pro (Build 9600) anzuwenden, welches bereits das Telemetrieteil KB2976978 beinhaltet.
Leider weisen die fünf *.mum Dateien keinen solchen "permanence" Eintrag auf.
Hat jemand eine Idee, wie man sich dieses Telemetriepaketes dennoch entledigen könnte, bzw. wo man ein koscheres Windows 8.1 (Pro) ISO bekommen könnte, dass noch frei von diesem Paket ist?
Danke.
funktioniert leider nicht mit dem Windows 8.1 Telemetrie-Update KB2976978… eine Sache noch, auf den Notepad-Screenshots oben heißt es permanencE="removable", im Artikel selbst aber permanencY="removable", welche Variante ist die richtige? Hatte aber eh beide ausprobiert.
Screenshot ist richtig – aber wie ich schrieb, hat sich da bei einigen Updates wohl was geändert – der Beitrag ist aus 2016.
Hallo,
vollkommen veralteter Beitrag. Powerrun.exe ist seit geraumer Zeit nich mehr funktionsfähig.
Dann könnte man sich die folgenden Beiträge ansehen, um die Prozesse als TrustedInstaller auszuführen:
The Art of Becoming TrustedInstaller
AdvancedRun, NSudo: Programme als SYSTEM oder Trusted Installer ausführen
Guten Abend.
Zum Thema ´windows-updates-fehlende-deinstallation-erzwingen´ muß ich bedauerlicher-weise mitteilen – rückmelden -, daß die KB-Nummern der in ´Update deinstallieren´ aufgeführten Liste als diese Nummer suchen in C:/Windows/servicing/Packages/ dort nicht gefunden wird.
Damit ist mir die zugehörige mum-Datei nicht auffindbar und nicht editierbar.
(Beispiel (uninstallierbares: Sicherheitsupdate für Microsoft Windows) KB5026361.
Bemerkung: es gibt noch 5 weitere Updates, die ebenfalls nicht deinstallierbar sind, und die Windows 10 extrem verlangsamen.)
Ergänzung:
Selbst mit vollständigem ´Zurücksetzen´ – nicht die Wiederherstellung gemeint – und extra ausgebauter WLAN-Karte (für ohne Internet: die Updates verhindern) bleiben diese uninstallierbaren Updates erhalten.
Bleibt mir (aktuell) nur diese Lösung:
Von Win10-iso – ob Original, oder aus Internet Herunter-Geladene – neu installieren *. Für die Installation nicht versäumen WLAN (für, bzw. Internet) deaktivieren, damit die Updates nicht sofort wieder mit installiert werden.
Und VOR Aktivierung der Internet-Verbindung (WLAN, Netzwerk) wieder,
diesen Schlüssel in der Registry erzeugen, der keine Updates mehr automatisch installiert:
Per (Run bzw. Ausführen) ´regedit´ [ENTER-Taste] zum Schlüssel
HKEY_LOCAL_MACHINESOFTWAREPoliciesMicrosoftWindowsWindowsUpdateAU
WindowsUpdate ist vermutlich nicht vorhanden:
Mit rechter Maus-Taste auf ´Windows´ und in Menu ´Erstellen Schlüssel´ "WindowsUpdate" eingeben [ENTER-Taste], Rechte Maus-Taste auf ´WindowsUpdate´ und neuen Schlüssel erstellen: "AU".
Diesen Schlüssel klicken und in rechtem freien Feld rechte Maus-Taste Menu ´Neu´ Schlüssel erstellen:
(für Win 10: 32-bit) DWORD,
(für Win10: 64-bit) QWORD,
wählen.
NoAutoUpdate [ENTER-Taste],
Und mit rechter Maus-Taste auf diesen Schlüssel und nach der Auswahl "Ändern" den Wert (0) auf 1 setzen.
Damit gibt es über Updates nur noch Benachrichtigungen und muß sorgfältig gelesen werden, damit nicht doch installieren gewählt ist/wird.
(Das Regedit-Fenster schließen. Ich empfehle danach einen Neu-Start.)
(Leider erinnere ich gerade die Quelle dafür nicht mehr.
Diese Quelle schnell dafür gefunden: unter "Methode 2: Windows-Registry"
* Bei nicht Original-Installation (iso aus Internet) soll ANGEBLICH (mehr weiß ich nicht) die Aktivierung bezogen auf den letzten Aktivierungs-Schlüssel automatisch erfolgen.
Bzw. wohl nicht, solange die Internet-Verbindung nicht besteht.
Da es um das Verhindern der Updates geht, nach Erstellen des Schlüssels zur Verhinderung der Updates: danach erst die Internet-Verbindung wieder-herstellen.
(Ich hoffe, es ist OK, diese Lösung hier mit anzubieten. Danke.)