Hi …
ich kann Dich also nicht davon abhalten, Deine Zeit zu inverstieren? Nun gut, dann arbeiten wir doch zusammen: Du hast Zeit und die betroffene Maschine, ich habe das Know-How wie man sowas angehen kann.
Ich muss Dich allerdings kurz vorwarnen: vor einiger Zeit habe ich solche Troubleshooting-Aktionen im Zusammenhang mit Windows Updates und anderem regelmäßig machen müssen, weil ich für Softwareverteilung und automatische Installationen zuständig war. irgendwann war ich es - wie die meisten anderen auch - einfach nur noch leid, jedem Fehler (und es gab immer Dutzende davon) nachzulaufen um dann - schon wieder - herauszufinden, dass irgendein Microsoftie irgendein Stück Debug-Code vergessen hat auszuklinken, oder dass man es irgendwie eilig hatte und das Update mit bestimmten Windows Versionen nicht klar kommt (das MUI Problem) oder etwas nicht läuft wenn nicht vorher noch x andere Komponenten nachgeschoben werden, z.B. eine bestimmte .net Framework Version, oder eine vb RUntime oder eine c Runtime Library Version, obwohl der Patch weder die eine noch die andere patcht. Es hat sich auch gezeigt, dass Maschinen, die man abseits von den Windows Defaulteinstellungen konfiguriert, also z.B. bestimmte Features installiert oder deinstalliert, anfälliger sind. Und dass ein Fehlercode wie cxxxxxxx von x Komponenten produziert und jedes Mal etwas anderes bedeuten kann, weil es bei Microsoft wohl keine globale Fehlercodeverwaltung gibt, die jedem Code genau eine eindeutioge Quelle und Ursache zuweist. Ganz abgesehen davon dass durch das moderne Konzept der „strukturierten Fehler(nicht) Behandlung“ Fehler aus einer Komponente, wenn der Programmierer sie nicht behandelt, sowieso den Call Stack aufwärts „durchfallen“ können bis sie schließlich in einer ganz anderen Komponente, die überhaupt nichts dafür kann, einschlagen.
Egal. Ich bin also etwas aus der Übung, aber soweit ich weiß, hat Microsoft die Updates nach wie vor auf dem Windows Installier aufgebaut. Sollte das nicht zutreffen, kannst Du hier aufhören zu lesen.
Aber wir wollen nicht jammern, sondern arbeiten.
Erst einmal: Du hast das Update als File heruntergeladen, und ggf. con seinem „Wrapper“ befreit (irgendeine .exe), am Ende liegt es als .msi Datei vor, richtig?
Dann folgst Du diesen Anweisungen:
https://support.microsoft.com/kb/223300/de?wa=wsigni…
und schaltest die detaillierte Protokollierung für msi Installer ein. Zusätzlich startest Du den Process Monitor (Sysinternals Tool) und trainierst ihn, den Windows Installer (msiexec) zu monitoren. Weitere Hinweise gewinnst Du über das ORCA Tool, damit kannst Du die Tabellen des MSI auseinandernehmen und den groben Installationsablauf herausfinden, sowie den Variablennamen eine Bedeutung zuordnen.
Dann schaltest Du noch - nur um zwei häufige Fehlerquellen auszuschalten - den Virenscanner aus und startest das MSI im administrativen Kontext.
Dann lässt Du das Ding laufen bis es abbricht. Bricht es nicht ab, wars der Virenscanner (extrem selten, das war in den Anfangstagen des WIndows Installers aber eine häufige Ursache), oder die UAC hat es (wieder mal, aber das wird immer seltener) verabsäumt, administrative Rechte anzufordern, Problem gelöst.
Es kommt auch gar nicht so selten vor, dass der Patch gar nicht an den Windows Installer übergeben wird, doer dass er von diesem sofort abgelehnt wird, etwa wegen einer fehlerhaften Signatur, weil der Patch nach Ansicht des Installers an der falschen Stelle gespeichert ist, oder weil er noch ein Sperrflag „downgeloadet, also potenziell unsicher“ trägt (kann man mit dem Windows Explorer entfernen).
Nehmen wir an, das Problem bleibt, der Installer läuft los, und es gibt logs.
Du bekommst dann ein Process Monitor log von beachtlicher Länge, und ein msi log von nicht weniger beachtlicher Länge (Zeilenzahlen idR fünfstellig). Und dann geht die Sucherei los. Am Besten arbeitet man sich von hinten nach vorne - weil es im Wesen von Fehlerbehandlunsgroutinen liegt, den Programmlauf ziemlich geradlinig zu beenden. Man schaut dann nach Auffälligkeiten. Wenn man eine Maschine hat wo etwas läuft, lässt man auch da ein log mitlaufen und vergleicht die Logs mit einem geeigenten Tool wie Windiff. Auf jeden Fehler loszugehen ist allerdings ein Trugschluss, oft sind Fehler durchaus gewollt, eine nicht gefundene Datei kann z.B. aus einem Check herrühren um festzustellen, ob irgendwas existiert, und dass es nicht existiert kann der Normalfall sein. Es ist also ein wenig wie ein Krimi: man bekommt Hinweise, manche sind irreführend, manche sind ein wenig nützlich, aber irgendwo findet sich der entscheidende Hinweis auf den Grund des Abbruchs. Etwas fehlt was „normalerweise“ bei Microsoft da wäre, etwas istd a was nicht da sein dürfte, oder irgendwas sitzt mit seinem Hintern auf einer Ressource drauf die der Patch auch belegen möchte, dann muss man irgendeinen Dienst deaktivieren, und „schon“ läufts.
Tja, und dann setzt Du das ganze Puzzle zusammen, und findest heraus, dass dem Patch irgendwas fehlt, oder dass er etwas findet was er nicht mag, oder dass er bei MIcrosoft falsch gepackt wurde (falsche Sprachversion, falsches 32/64 Bit Flag) oder dass er einen anderen Patch installiert finden möchte, oder dass er einen anderen Patch (klammheimlich) deinstallieren möchte, und dann wird Dir plötzlich klar, warum es auf Deiner Maschine grad nicht klappen konnte, und warum Leute die ihre Maschinen grad neu aufgesetzt haben oder die in USA zu Hause sind mit dem Patch keine Probleme haben.
Und das Ganze machst Du einige Male, bist jedes Mal stolz wenn Du es herausgefunen hast, aber die Begeisterung kühlt zunehmend ab im gleichen Maß, wie nach dem Patch bald wieder einer kommt der zickt, und wie Dich Dein Boss fragt, warum Du 3 Tage brauchst um einen simplen Patch zu verteilen, wenn sein 11-jähriger Sohn ihm sagt, dass der auf seiner Windows Maschine zu Hause problemlos installiert wurde, woraus er messerscharf folgert dass entweder Deine Windows Installationen Mist sind, oder ein 11-jähriger mehr von IT versteht wie Du.
Danach beschließt Du, erst mal den Fehler totzuschweigen oder wegzuplappern und abzuwarten, ob er sich nicht von selbst erledigt, und in (gefühlten) 90% der Fälle passiert einige Updates später genau das.
Schön dass ich mal darüber reden durfte, und jetzt bin ich gespannt, was Deine Bemühungen mit Tools und Logs ergeben.
Gruss Armin.
