Verbesserungspotential: Windows Update

Eigentlich ist Windows Update ja eine der wichtigsten Funktionen unter Windows, soll diese doch dafür sorgen, dass das System auf dem neuesten Stand ist. Verlässt sich der Anwender auf Windows Update, ist er im wahrsten Sinne des Wortes "verlassen". Heute habe ich eine unangenehme Begegnung/Überraschung der dritten Art mit Windows Update gehabt und Bauklötze gestaunt.

Die Internetforen sind ja voll von Anwendern, die sich mit diversen Windows Update-Fehlern konfrontiert sehen. Meist ist es dann so, dass Windows Update versucht etwas zu installieren, diesen Vorgang nicht ausführen kann und dem Anwender eine Fehlernummer an den Kopf wirft. Gut, dann kann der Anwender ja noch reagieren und sich hilfesuchend an Foren wenden, oder (wie in meinem Magnum Windows 7 Home Premium Tricks-Titel, Seite 81 ff. "Ein Update bricht mit einem Fehler ab" empfohlen, bestimmte Ursachen als unzutreffend verifizieren und dann ) unter http://support.microsoft.com/ph/6527 auf Ursachenforschung gehen.

Da haben sie mich kalt erwischt, die Lümmel aus Redmond!

Ist das oben skizzierte Szenario unerfreulich, weil sich der Anwender mit einer unangenehmen Fehlermeldung konfrontiert sieht und in Panik ausbricht, gibt es aber eine Steigerung. Irgendwie war es mir entgangen, dass Windows 7 Home Premium mich die letzten Tage nicht mehr mit Updates belästigte. Ich hab mich nicht drum gekümmert, weil ich glaubte, das automatische Update eingeschaltet zu haben (meist ist es auf meinen Systemen auf Benachrichtigung gestellt, damit ich entsprechende Infos erhalte).

Um so mehr fiel mir heute morgen die Kinnlade runter, als ich (beim Schreiben dieses Blogbeitrags einen Blick in die Ereignisverwaltung warf, um etwas zu überprüfen. Mich traf da fast der Schlag, als plötzlich zig Fehlereinträge unter Anwendung auftauchten, die mir meldeten, dass wuaueng.dll ein Problem habe, auf den ClientDataStore des SUS20-Systems zuzugreifen. Ich habe hier einmal den entsprechenden Auszug aus der Ereignisbehandlung aufgeführt.

Noch geschockter war ich, dass mir auch gleich der Grund genannt wurde: Die betreffenden Funktionen des Update-Clients hatten Probleme, die edb.log unter %windir%\SoftwareDistribution\DataStore\ Logs\ zu lesen. Also warf die Funktion das Handtuch.

Nachdem ich dann Windows Update aufrufen wollte, dauerte es bereits eine Ewigkeit, bis die betreffende Seite auftauchte – und in der Ereignisverwaltung tauchten Warnungen über Zeitüberschreibungen beim Zugriff auf ein Element mit der ClassID {xxxxx} auf. Irgendwann hatte sich Windows Update berappelt und kam mit der betreffenden Seite. Die Schaltfläche zum Starten der Updates war aber bereits merkwürdigerweise mit einem roten Kreis versehen. Als ich dann auf die Schaltfläche klickte, wurde ich mit einem netten Dialogfeld begrüßt.

Na prima. Da wird der Anwender, der nix von meiner obigen Entdeckung in der Ereignisverwaltung weiß, astrein in die Falle gelockt. Ein Neustart dürfte die beschädigte log-Datei nicht reparieren.

Der zweite Schlag traf mich, als ich mich auf die Suche im Ordner %windir%\SoftwareDistribution\DataStore\Logs\ machte. Die dort befindliche edb.log war vom 13. Januar 2010 und damit gut einen Monat nicht mehr im Eingriff.

Was hab ich gemacht? Einfach die edb.log in edb.log.kaputt umbenannt, das System gebootet und dann Windows Update erneut aufgerufen. Und plötzlich meldete Windows 7, dass gefühlte 30 kritische Updates vorlägen und ich die doch bitte schön dringend installieren möge.

Liebe Entwickler in Redmond: Ja geht's denn noch? Ich kann ja verstehen, dass ihr nicht für alle Situationen des Lebens eine Fehlerbehandlung einflicken könnt. Aber wenn ein Modul nicht auf eine Logdatei zugreifen kann, weil diese beschädigt ist – und dies eine so kritische Funktion wie Windows Update lahm legt – da wäre das mindeste, dass dem Anwender im Klartext gesagt wird "ich kann auf die Logdatei yxz nicht zugreifen, weil kaputt". Und wenn euch der Anwender am Herzen liegt, hätte ein Dialogfeld erscheinen können, in dem man liest "Lieber Anwender, magst Du, dass ich die Logdatei repariere oder lösche". Eine Ja/Nein-Schaltflächenkombination hätte dann das Problem auch für Otto-Normaluser lösen können. Ja ich weiß, bei einem Dienst ist das nicht so vorgesehen – aber Windows Update könnte beim Aufruf da wohl was zu sagen.

Aber nein, da wird klammheimlich was in der Ereignisbehandlung eingetragen. Und nur wer pertinent genug ist und da mal nachschaut (mache ich höchst selten), kommt dann auf den Trichter. Es ist zwar schon ein paar Tage her (genauer gesagt, war's im vorherigen Jahrtausend), dass ich eine Entwicklermannschaft geleitet habe. Wenn mir so etwas von einem meiner Entwickler auf den Tisch gekommen wäre, hätte ich ihm das um die Ohren gehauen, dass es nur so summt. Also lieber Steven Sinofsky, krall dir nochmals deine Jungs und beginnt drüber nachzudenken, ob man das beim SP1 nicht vielleicht etwas cleverer lösen könnte.

Aber sind nur "just my 2 cents".

Nachtrag: Zwischenzeitlich bin ich auf den in [2] verlinkten Beitrag in der Microsoft Knowledgebase gestoßen. Dort gibt es einen Sack voll an Tipps, um Probleme mit Windows Update zu beheben.

Links
[1] Windows Update-Fehlerseite
[2] Updates und Programm nicht installierbar (MS KB)