Dieses ominöse Verhalten mit den nicht-löschbaren 1.75GB (exakt so bei mir. Hatte es in meinem Blog-Beitrag in Bezug auf die Größe vor allem auch noch mit angeben wollen, aber war mir untergegangen
) hatte ich schon bei einigen Versionen des Slow-Rings lange vor .172 und .173 von dem die bekannte Fehlerbeschreibung im Blog berichtet, mit 19025 und 19030 und 19031 erlebt. Also Zeitpunkt etwa Beginn des Jahres, als Slow-Ring und Fast-Ring für kurze Zeit fast die gleichen Builds anboten. Damals war ich deshalb kurz auch mal auf den Fast-Ring umgestiegen, um diesen Bug mit den stehenbleibenden Update-Bereinigungen zu umgehen, aber hatte sich dann auf einmal ein pre_release des 20H2 installiert, von dem ich nicht mehr auf den zumindest Slow-Ring zurückkehren konnte... Und Fast-Ring ist eigentlich ausschliesslich Testing und je nach dem kaum für den Alltagsgebrauch geeignet.
Mich wundert, dass das immer wieder aufzutauchen scheint...
Aber mal eine andere Frage:
Vorweg aber erst ein liebes Danke für Deine Herleitung zur DISM-basierenden Deinstallation des im CBS.log aufgeführten Package.
Mal gespannt, ob sich der Bug auch ausgehend der 19041.208 beim nächsten Update erneut zeigen wird, und ich das zu deinstallierende auch über meine CBS.log dann ermitteln und durchführen kann...
Aber zu der Frage: Ist der 84.9% -Anzeigefehler bei der DISM-Bereinigung geblieben? Um es zu entwirren: Du hast von .207 auf .208 upgedatet, um das von mir geschilderte Fehlerbild zu reproduzieren. Per CBS.log das den Datenträger-Bereinigungs-Fehler (bzgl. der Update-Bereinigung) vermutlich bewirkende Packet ausfindig gemacht, es per DISM gelöscht/deinstalliert.
Hat sich damit auch der 84.9%-Anzeige-Bug per DISM-Bereinigung, der hierbei:
genau auftritt, mit-erledigt, oder ist er noch da? Ebenso der Fehler bei der Defragmentierung/Optimierung in Bezug auf die verlorengehenden "Zuletzt ausgeführt"-Daten?
Dieses ominöse Verhalten mit den nicht-löschbaren 1.75GB (exakt so bei mir. Hatte es in meinem Blog-Beitrag in Bezug auf die Größe vor allem auch noch mit angeben wollen, aber war mir untergegangen :kopfkratz: ) hatte ich schon bei einigen Versionen des Slow-Rings lange vor .172 und .173 von dem die bekannte Fehlerbeschreibung im Blog berichtet, mit 19025 und 19030 und 19031 erlebt. Also Zeitpunkt etwa Beginn des Jahres, als Slow-Ring und Fast-Ring für kurze Zeit fast die gleichen Builds anboten. Damals war ich deshalb kurz auch mal auf den Fast-Ring umgestiegen, um diesen Bug mit den stehenbleibenden Update-Bereinigungen zu umgehen, aber hatte sich dann auf einmal ein pre_release des 20H2 installiert, von dem ich nicht mehr auf den zumindest Slow-Ring zurückkehren konnte... Und Fast-Ring ist eigentlich ausschliesslich Testing und je nach dem kaum für den Alltagsgebrauch geeignet.
Mich wundert, dass das immer wieder aufzutauchen scheint...
Aber mal eine andere Frage:
Vorweg aber erst ein liebes Danke für Deine Herleitung zur DISM-basierenden Deinstallation des im CBS.log aufgeführten Package. :daumen: Mal gespannt, ob sich der Bug auch ausgehend der 19041.208 beim nächsten Update erneut zeigen wird, und ich das zu deinstallierende auch über meine CBS.log dann ermitteln und durchführen kann...
Aber zu der Frage: Ist der 84.9% -Anzeigefehler bei der DISM-Bereinigung geblieben? Um es zu entwirren: Du hast von .207 auf .208 upgedatet, um das von mir geschilderte Fehlerbild zu reproduzieren. Per CBS.log das den Datenträger-Bereinigungs-Fehler (bzgl. der Update-Bereinigung) vermutlich bewirkende Packet ausfindig gemacht, es per DISM gelöscht/deinstalliert.
Hat sich damit auch der 84.9%-Anzeige-Bug per DISM-Bereinigung, der hierbei: [code]DISM.exe /online /cleanup-image /restorehealth[/code] genau auftritt, mit-erledigt, oder ist er noch da? Ebenso der Fehler bei der Defragmentierung/Optimierung in Bezug auf die verlorengehenden "Zuletzt ausgeführt"-Daten?
