News Windows 10 Creators Update: Microsoft warnt vor Risiken bei manuellen Updates

Ozzy83 schrieb:
Mir geht die Art auf den Zeiger wie Windows geupdated wird. Heute morgen PC angeschaltet...bitte warten...Neustart, bitte warten.... auf die Arbeit und zurück, nochmal Neustart...bitte warten. Und bei Linux? Live update während man seinen üblichen Kram macht.

Daran wird sich leider nichts ändern, solange MS an ihrer Registry-Datenbank weiter festhalten, die man aber sicher nicht von heute auf morgen ablösen kann. Aber unter Linux muss auch bei Kernel-Updates gebootet werden.
 
Das hat bei Windows nichts mit der Registry zu tun sondern damit wie Files geblockt werden. Programme die grad laufen können nicht auf der Platte verändert werden (bei Linux geht das). Wobei man bei Linux dann trotzdem nicht vergessen darf das der Patch erst aktiv wird wenn man zumindest das Programm neu startet... bei Windows ist durch das Blocken gewährleistet dass die Version im Speicher mit der auf der Platte übereinstimmt.

Edit: mich nervt die Art des Windows Updates aber auch... da gäbs noch einiges an Verbesserungspotential. Vor allem der Punkt das wenn ich beim Shutdown sag "Updates installieren", warum macht er dann nicht alles komplett fertig inkl. aller notwendigen Reboots? Meistens macht er dann nämlich nur das was bis zum ersten Reboot fällig ist und schaltet dann aus. beim nächsten hochfahren geht's dann mit dem Rest weiter (den er eigentlich längst vorher hätte machen können...)
 
Zuletzt bearbeitet:
Es hat nichts mit der Registry zu tun, richtig.

Es liegt leider an der Architektur von Windows. Windows ist seit Windows Vista in zig kleine Pakete zerlegt (siehe %windir%\winsxs). Von einem Paket können mehrere Versionen vorliegen. Es kann aber immer nur eine Version aktiv sein (das sind die Dateien die man dann in system32 usw. sieht -- das sind NTFS Hardlinks). Das Problem ist jetzt, dass es Abhängigkeiten gibt, da manchmal bei Updates neue Funktionen hinzukommen oder Funktionsparameter geändert werden. D.h. eine abhängige Komponente muss dann in einer Version vorliegen, welche mit der geänderten Abhängigkeit harmoniert usw. Gleichzeitig soll auch noch sichergestellt werden, dass die Integrität der Systemdateien gewahrt ist.

Jeder hier wird das Problem kennen: Installierte man Windows 7 zuletzt neu (vor dem SP2 was nicht SP2 genannt werden darf) brauchte es 200+ Updates. Man sollte tunlichst vermeiden 200+ Updates am Stück zu installieren. Nach ca. 50 Pending Updates war der TrustedInstaller fertig mit sich selber.... weil bei jedem neuen Update der Ist-Zustand + alle geplanten Änderungen erneut validiert werden mussten.

Das Problem existiert nach wie vor.

Durch diese Combo-Updates muss jetzt zumindest nur noch 1x geprüft werden...

Naja, und wenn neu gestartet wird kommt dann eben die eigentlich Arbeit: Die Links müssen aufgehoben und neu gesetzt werden (inkl. erneuter Abhängigkeitsprüfung). Außerdem soll das bitte auch Rollback-fähig sein...

Unter Linux als auch MacOS läuft es anders. Letzteres macht Systemupdates zwar auch im Zuge eines Neustarts, hier müssen aber wirklich nur Dateien kopiert werden (ein Grund weswegen es bei nicht-Combo Updates manchmal zu Fehlern kommt: Es fehlen dann möglicherweise Abhängigkeiten, weswegen Mac-Experten dazu raten immer das komplette Update anzuwenden).


https://blogs.technet.microsoft.com...008-and-windows-vista-and-why-is-it-so-large/


Ein ähnliches Problem gibt es auch bei MSI-basierten Installationen. Prominentes Beispiel ist hier Visual Studio. Der ein oder andere wird sich noch daran erinnern, dass SPs hier 2+ Stunden gedauert haben während VS selbst in <20min installiert wurde. Siehe dazu https://blogs.msdn.microsoft.com/he...or-longer-to-install-than-the-target-product/
 
Whistl0r schrieb:
Es liegt leider an der Architektur von Windows. Windows ist seit Windows Vista in zig kleine Pakete zerlegt (siehe %windir%\winsxs). Von einem Paket können mehrere Versionen vorliegen. Es kann aber immer nur eine Version aktiv sein (das sind die Dateien die man dann in system32 usw. sieht -- das sind NTFS Hardlinks). Das Problem ist jetzt, dass es Abhängigkeiten gibt, da manchmal bei Updates neue Funktionen hinzukommen oder Funktionsparameter geändert werden. D.h. eine abhängige Komponente muss dann in einer Version vorliegen, welche mit der geänderten Abhängigkeit harmoniert usw.

Das was du beschreibst ist das Verhalten VOR "WinSxS". Damals gab es das Problem, dass Komponenten von Updates überschrieben wurden und danach manche Anwendungen nicht funktioniert haben oder dass Bibliotheken im Programmordner, sobald sie geladen wurden, zum Fehler in einer anderen Anwendung geführt haben.

Das ist eben seit dem von dir genannten "WinSxS" (Side-by-Side) Geschichte!
https://www.ghacks.net/2010/07/24/the-winsxs-folder-explained/
https://en.wikipedia.org/wiki/Side-by-side_assembly

Vereinfacht ausgedrückt, kann seit Vista jede Anwendung "ihre" Version einer Bibliothek mitbringen. Side-by-Side sorgt nun dafür, dass jede Applikation ihre Version nutzt (wenn sie es möchte) und ein Update andere Programme nicht beeinflusst.
 
Zuletzt bearbeitet:
xexex schrieb:
Das was du beschreibst ist das Verhalten VOR "WinSxS". Damals gab es das Problem, dass Komponenten von Updates überschrieben wurden und danach manche Anwendungen nicht funktioniert haben oder dass Bibliotheken im Programmordner, sobald sie geladen wurden, zum Fehler in einer anderen Anwendung geführt haben.

Das ist eben seit dem von dir genannten "WinSxS" (Side-by-Side) Geschichte!
https://www.ghacks.net/2010/07/24/the-winsxs-folder-explained/
https://en.wikipedia.org/wiki/Side-by-side_assembly

Vereinfacht ausgedrückt, kann seit Vista jede Anwendung "ihre" Version einer Bibliothek mitbringen. Side-by-Side sorgt nun dafür, dass jede Applikation ihre Version nutzt (wenn sie es möchte) und ein Update andere Programme nicht beeinflusst.

[ ] Ich habe mir die Mühe gemacht und die als Quelle verlinkte Seite gelesen.


...im übrigen zitiert der ghacks-Artikel meine Quelle :)

Offensichtlich hast du etwas nicht ganz verstanden. Einfach noch einmal alles lesen.
 
Meine anmerkung bezog sich auf den ersten teil deine aussage, die so schlichtweg falsch ist. Ein Problem unter linux sind zum Beispiel abhängigkeiten und sobald man eine aktuellere version einer komponente installieren will, muss geprüft werden welche Programme sonst aktualisiert werden müssen.

Ein Problem von FRÜHEREN Windows versionen war ausserdem, dass es nur eine Version einer dll geben durfte und sobald sie geladen war alle progamme darauf zugegriffen haben. Das führe oft zum absturz oder zum seltsamen verhalten der Programme.

Winsxs beseitigt eben genau die beiden Probleme. Wird eine software installiert, kopiert Windows die bibliotheken in den komponentenspeicher, merkt sich zu welcher software die gehört und lädt bei start dieser Software die passende version. Zudem können Programme selbst angeben welche version sie wollen - eine spezielle, eine bestimmte versionsnummer oder die jeweils aktuelle.
 
Von Microsoft auf Deutsch übersetzt = Der erzwungene Beta Test auf Produktivmaschinen der Kunden läuft derzeit noch und weitere Beta-Tester auf freiwilliger Basis sind derzeit nicht erwünscht :evillol:

Also ich habe das Creators Update von Beginn an und habe keine Probleme.
 
Danke Euch für die Infos. Hatte immer gedacht, dass es an der Registry liegt, die dann nach Veränderungen beim Neustart neu geladen wird. Aber wenn die zwingenden Neustarts der aktuellen Architektur von Windows zu Grunde liegen (durch die File-Locks), dann wird sich daran nie etwas ändern. Ich sehe da in der Neustartnotwendigkeit bisher keinen Unterschied bei Windows 10 zu 8.1 oder 7, da ist nie etwas weniger geworden, obwohl es MS immer angedeutet hatte.
 
Hatte neulich von Problemen mit DSR und manuell im nVidia Treiber angelegten Auflösungen (z.B. 2880x1620 @ 77 Hz) berichtet. Ich konnte das Problem lösen. Man muss das jeweils gesetzte Setting übernehmen und dann den Rechner neu starten. Dann funktionieren DSR und custom Resolutions problemlos.

Vor dem Update hatte es ausgereicht das Spiel zu schließen, die Änderungen zu übernehmen und das Spiel neu zu starten.

Inzwischen habe ich einen "clean install", also win 10 64bit home edition per selbst erstellter .iso Boot DVD frisch aufgesetzt. Das lief problemlos nach ein paar google Recherchen und der Speed ist besser. Liegt aber vllt. daran, das alles frisch aufgesetzt ist ;)
 
Zuletzt bearbeitet:
Zurück
Oben