Gesammeltes aus dem Leben eines "normalen" Programmierers… :-)
Ich habe vor einiger Zeit in dem Artikel Probleme bei Installation des Sicherheitsupdates KB947319, Fehler Code A95 von meinen Ärger mit dem Windows Update berichtet.
Ich war extrem überrascht welche Aufmerksamkeit dieser Artikel erregte. Das ging so weit, dass ich weitere Kommentare blocken musste und in meinem überfüllten Email-Postfach zu einem Standardtext greifen musste für Leute, die nach der Case Id fragten.
Endlich ist ein offizieller Fix für den KB947319 verfügbar ❗
Am 11.08.2009 wurde das KB947319 Sicherheitsupdate für Office 2003 Web Components und Office XP Web Components in Office 2003 herausgegeben.
Dieses Updates lies sich bei mir auf einigen meiner Rechner (alle Vista) nicht installieren. Ich erhielt immer die Fehlermeldung A95.
Im Updateverlauf steht folgendes:
Sicherheitsupdate für Microsoft Office Web Components (KB947319)
Installationsdatum: 13.08.2009 10:29
Installationsstatus: Fehlgeschlagen
Fehlerdetails: Code A95
Ich habe danach versucht den Hotfix direkt herunter zu laden und die office2003-KB947319-FullFile-DEU.exe auszuführen. In diesem Fall erhielt ich die Fehlermeldungen:
Fehler 2709: Ein internen Fehler ist aufgetreten.
(Global_PIA_OWC11 )
und
Sicherheitsupdate für Office Web Components 2003 (KB947319)
Das Update konnte nicht angewendet werden.
Das eigentümliche ist allerdings, dass Office 2003 auf diesen Rechner selbst nicht installiert ist.
Da dieses Problem konsequent auf einer einer ganzen Reihe von Rechner auftrat habe ich den MS-Support bemüht. Jetzt nach einigen Tagen sieht es so aus, dass das ganze an einer Installation der MS-Access 2003 Runtime liegt.
Auch die MS-Access 2003 Runtime wurde als Ziel für diesen Patch eingetragen obwohl diese gar nicht betroffen ist.
Ich zitiere einfach mal den MS-Support:
Das Update KB947319 besteht aus 2 MSPs, OWC10.MSP und OWC11.MSP. Beide haben unter anderem die Access Runtime 2003 als Target eingetragen. Allerdings hat die Access Runtime 2003 gar keine OWC11, sondern nur die OWC10, insofern scheitert OWC11.MSP mit der Fehlermeldung:
Error 2709. An internal error has occurred. (Global_PIA_OWC11 )Error 2709 heisst: „The specified Component name (‚[2]‘) not found in Component table“ was ja auch der Tatsache entspricht, denn die Komponente OWC11 ist ja tatsächlich nicht in Access Runtime 2003 enthalten.
Das Problem in diesem Fall ist, dass die Access Runtime 2003 in OWC11.MSP überhaupt als Target eingetragen ist. Das bedeutet für Sie zunächst einmal, dass trotz des Problems bei der Installation des Fehler im Moment kein Sicherheitsrisiko besteht, durch den Umstand, dass OWC11.MSP in der Access Runtime 2003 nicht installiert werden kann, da es keine OWC11 gibt, die man updaten könnte.
Es geht momentan noch darum, dass KB947319 von der Patch Detection weiterhin als applicable angezeigt wird, solange der Patch für die OWC11.MSP bezüglich der Access Runtime 2003 einen Fehler zurückliefert.
Wir sind aktuell dabei, einen Regression Hotfix für diesen Patch zu beantragen.
Aktuell habe ich dieses Sicherheitsupdate ausgeblendet. Bis die Regression durch ist.
Nachtrag 07.09.2009:
Ich bitte davon abzusehen weiter nach Informationen bei mir persönlich nachzufragen. Ich werde über die Veröffentlichung eines öffentlichen Fixes zu gegebener Zeit berichten.
Man kann sich ohne Probleme selbst an den Microsoft Support wenden und seine Probleme bzgl. des KB947319 schildern. Die Probleme sind hinlänglich bekannt und sofern die Indikatoren übereinstimmen sollte man auch einen provesorischen Fix vom Microsoft Support erhalten können.
Mit Datum vom 07.09.2009 sperre ich weitere Kommentare.
Nachtrag 26.10.2009
Endgültiger Fix für die Probleme bei Installation des Sicherheitsupdates KB947319, Fehler Code A95
Ich bin Tastatur Fan. Wenn ich es vermeiden kann benutze ich nicht die Maus. Aus diesem Grund möchte ich natürlich auch immer die Acceleratoren (unterstrichenen Buchstaben) in Menüs oder Dialogen sehen.
Leider ist seit Windows XP die Standardeinstellung so, dass man erst durch Drücken der ALT-Taste die Acceleratoren sichtbar macht.
Unter XP findet man das ganze unter
Leider hat ist diese Option unter Windows Vista nicht mehr dort zu finden.
Dank Windows Vista Suche nach „Tastenkombination“ führte mich das direkt zu:
Jeder kennt das, der schon mal an Supportfällen gearbeitet hat.
Der Kunde bekommt eine Fehlermeldung und meistens ist es eine simple MessageBox die dort angezeigt wird. Was wird gemacht? Der Kunde drückt Alt+Druck und schickt einen Screenshot.
Oder man will selber nach dem Text in Google suchen und tippt mühselig die Meldung ab.
Dabei geht es so einfach: Strg+C oder einfach Strg+Einfg drücken und schon wird der Text der Messagebox auf wundersameweise in die Zwischenablage kopiert:
--------------------------- Titel der MessageBox --------------------------- Text der MessageBox --------------------------- OK Abbrechen ---------------------------
Dies geht auf allen Windows Betriebssystemen!
Besonders interessant ist das auch der Windows Vista Task Dialog diese Funktionalität enthält, wie man z.B. mit dem Notepad unter Vista ausprobieren kann.
[Window Title] Editor
[Main Instruction] Möchten Sie die Änderungen an Unbenannt speichern?
[Speichern] [Nicht speichern] [Abbrechen]
Es gibt immer wieder Momente in denen einen die Win32 API in größtes Erstaunen versetzt.
Meistens ist dies allerdings in diesen Momenten nichts positives. Das zweite Erstaunen folgt, dann wenn man in der MSDN nachliest und das Verhalten als dokumentiert vorfindet. Meistens endet solch eine Kette dann in einem Kopfschütteln und dem Gedanken: Das darf doch gar nicht sein.
Genug der langen Vorworte:
cb.AddString(CString(MAKEINTRESOURCE(IDS_DATA1)));
cb.AddString(CString(MAKEINTRESOURCE(IDS_DATA2)));
cb.AddString(CString(MAKEINTRESOURCE(IDS_DATA3)));
cb.AddString(strSomeDynamicData);
cb.InsertString(0,_T(""));
Alles OK… Als letztes noch den Stil CBS_UPPERCASE dazu – weil hier eben nur Eingaben in Großbuchstaben erlaubt sein sollen und Sinn machen – und… Peng!
Das Programm schmiert ab. 😮
Was ged’n hier ab Alder ❓
In den tiefen des Aufrufs von cb.InsertString(0,_T(„“)); schmiert mein Programm ab. UAE
Nun aber doch großes Erstaunen, denn der selbe Code funktioniert in einem MBCS Programm.
Es liegt eindeutig an der Nutzung von CBS_UPPERCASE und Unicode.
Jetzt habe ich schon gedacht einen Bug in Vista und XP gefunden zu haben, denn auf beiden schmiert bersagter Code ab. Und wahrscheinlich ist es auch ein Bug! Aber das genauere Nachlesen der MSDN belehrt mich eines besseren. Dieses dämliche Verhalten ist dokumentiert, zumindest für CB_ADDSTRING (der Zusatz fehlt in der CB_INSERTSTRING Doku):
Comclt32.dll version 5.0 or later: If CBS_LOWERCASE or CBS_UPPERCASE is set, the Unicode version of CB_ADDSTRING alters the string. If using read-only global memory, this causes the application to fail. ❗
Unfassbar! Die Nachricht ist dabei selbst so beschrieben, wie es sich jeder vernünftige Entwickler auch denkt und vor allem erwartet, eben mit einem LPCTSTR:
lResult = SendMessage( // returns LRESULT in lResult
(HWND) hWndControl, // handle to destination control
(UINT) CB_ADDSTRING, // message ID
(WPARAM) wParam, // = 0; not used, must be zero
(LPARAM) lParam // = (LPARAM) (LPCTSTR) lParam;
);
Aber was nützt schon ein vernünftiger Gedanke eines Entwicklers wenn es um das irrwitzige Eigenleben der Win32 API geht.
Und denke nie einen Bug gefunden zu haben, bevor Du nicht jede Zeile der MSDN studiert hast 😉
Ich habe eine zweite SATA Festplatte in meinem Rechner (Windows XP SP2). Festplatten kann man ja auch direkt als neue Verzeichnisse bereitstellen. Schön, da eines meiner Verzeichnisse auf der ersten Festplatte am überquellen ist dachte ich mir:
Stelle einfach dies zweite Festplatte als neues Verzeichnis in meiner Verzeichnisstruktur zur Verfügung.
Gesagt getan und alles prima.
Bis ich heute auf die Idee kam ein wenig aufzuräumen:
Hier eine Datei gelöscht: OK. Dort eine Datei gelöscht: auch OK. Hier das Verzeichnis löschen: Peng „Zugriff wurde verweigert“! 😮
Was ist denn hier los ❓
Der Explorer hat mit meinem so eingemappten Laufwerk ein Problem. Er möchte die Dateien, die zu löschen sind, in den Papierkorb (Recycler Verzeichnis) verschieben. Das gelingt ihm offensichtlich mit Dateien (und die werden kopiert), allerdings gelingt ihm das nicht mit Verzeichnissen.
Direkt Löschen kann man diese Verzeichnisse indem man die Umschalt-Taste festhält m Explorer.
Das Löschen gelingt auch, wenn man die Festplatte über einen Laufwerksbuchstaben zusätzlich einmappt und dann über diese Verknüpfung die Verzeichnisse löscht.
Irgendwie nicht zu verstehen, dass hier der Explorer so kläglich versagt. 🙁
Aber auch dieses Verhalten ist dokumentiert, was ich nach einer Rückfrage bei meinen Mit-MVP Ralf Breuer auch erfuhr:
http://support.microsoft.com/kb/319368
Anmerkung: ❗ Eine Datei, die über das gemappte Verzeichnis C:\xyz gelöscht wird landet übrigens im Papierkorb auf der Platte C:, obwohl sie physikalisch auf einer anderen Platte liegt. Wirre Explorer Welt!