MS zerstört durch KB2687441 die Kompatibilität von MSCOMCTL.OCX

Tja, da hat MS mal wieder richtig Mist gebaut: Nach dem Sicherheitsupdate KB2687441 funktionierte so gut wie keine meiner (leider ziemlich zahlreichen) Access-Anwendungen mehr.

Nicht genug damit, dass ich einen Tag Lebenszeit wegen des Unsinns verschwenden musste – nein, in Wahrheit ist der Schaden viel größer, denn i. d. R. verstehen/wissen Kunden/Endanwender nicht, dass mein Programm bis vor dem Patchday anstandslos lief und der Wahnsinn mitnichten in meine Verantwortung fällt!

Im Gegenteil: jeder, der eines meiner Access-Programme ab heute installiert/ausprobiert und aufgrund des MS-Bugs nicht starten kann, wird MICH für unfähig erklären. Und da es eine ganze Menge Beispiele für die MS-Praxis gibt, nach der man – teilweise über Jahre – offensichtliche Bugs geflissentlich ignoriert, nützt es leider nicht, auf einen Fix zu hoffen und im Worst Case aus Kundensicht bis zum St. Nimmerleinstag den schwarzen Peter zu haben. In der Tat eine sehr, sehr nervtötende Situation für uns Entwickler!

Nun aber genug des Gejammers – zur Sache:

1. Änderung der TypeLib-Versionsnummer

In der neuen MSCOMCTL.OCX (6.1.98.34) hat man offensichtlich die Versionsnummer in der TypeLibrary von 2.0 auf 2.1 erhöht.

Ich habe mit VB6 mit der alten (6.1.98.33) und neuen OCX-Version je ein Testprojekt erstellt und dann mal in das VBP geschaut. Ergebnis:

6.1.98.33: Object={831FDD16-0C5C-11D2-A9FC-0000F8754DA1}#2.0#0; MSCOMCTL.OCX

6.1.98.34: Object={831FDD16-0C5C-11D2-A9FC-0000F8754DA1}#2.1#0; MSCOMCTL.OCX

Fragt sich zunächst einmal … warum in aller Welt hat man nur für ein Sicherheitsupdate die TypeLib-Versionsummer hochgesetzt? Ich verstehe es nicht! So etwas macht man meines Wissens eigentlich nur beim Einbau neuer Funktionen … nun, vielleicht kann mich jemand aufklären, der schlauer ist als ich?

Solange man in seinen Anwendungen LateBinding verwendet (was ich bei verteilten Programmen in jeden Fall tue), sollte dies allein kein Problem darstellen. Nach dem Update liefen jedoch auch diese nicht mehr:

2. Der wahre Schuldige

Vorweg: es geht hier um den folgenden Registryschlüssel:

HKEY_CLASSES_ROOT\TypeLib\{831FDD16-0C5C-11D2-A9FC-0000F8754DA1}

Auf einem meiner Rechner (XP) waren bereits einige der Updates installiert (u. a. war die neue MSCOMCTL.OCX  in der Version 6.1.98.34 bereits drauf), aber die Installation der Office 2007-Updates (KB2596615, KB2596754, KB2687441, KB2596856) war fehlgeschlagen. Auf diesem Rechner liefen alle Access-Anwendungen problemlos!

Auf diesem Rechner gab es im o. g. Schlüssel einen 2.0- und zusätzlich einen 2.1-Unterschlüssel – und beide waren vollständig, so wie es sich gehört (leider habe ich davon keinen Screenshot gemacht).

Daraufhin habe ich beschlossen, mit meinem virtuellen Rechner (Win7 Pro 32-Bit) weiterzuprobieren, der sich im Zustand vor sämtlichen Updates befand. Darauf installiert sind Access 2002, 2003, 2007 und eine 2010er Runtime.

Ein Blick in den o. g. Registry-Schlüssel zeigte dies:

Nach Durchführung sämtlicher Updates sah es so aus:

Die Updates haben den 2.1-Schlüssel neu erstellt und zusätzlich sämtliche Unterschlüssel des 2.0-Schlüssel gelöscht – nicht aber den 2.0-Schlüssel selbst! Eigentlich logisch, dass eine Anwendung, die mit der 2.0er-Version der MSCOMCTL.OCX kompiliert wurde, in einem solchen Szenario nicht funktionieren kann.

Ich habe daraufhin testweise eine der „Problem“-Access-Anwendungen installiert. Funktionierte natürlich nicht … sondern erst nach dem Löschen des leeren 2.0-Schlüssels!

Abschließend habe ich dann auf dem XP-Rechner, auf dem die Office 2007-Updates fehlten, diese nachinstalliert.

Ergebnis: der vorher intakte 2.0-Schlüssel wurde ebenfalls zerstört, indem alle Unterschlüssel, aber nicht der Schlüssel selbst gelöscht wurde.

Nun habe ich mir noch einmal die Updates im Detail angesehen:

Update Dateien(en) Version
KB2596615 mso.dll 12.0.6662.5000
KB2596754 Msconv97.dll 2006.1200.6662.5000
KB2687441 Mscomctl.ocx 6.01.9834
KB2596856 Msxml5.dll 5.20.1096.0

Demnach scheint also KB2687441 der Schuldige zu sein.

3. Was tun?

Auf die Schnelle könnte man es mit einer Reg-Datei lösen und den 2.0-Schlüssel einfach löschen:

Windows Registry Editor Version 5.00

[-HKEY_CLASSES_ROOT\TypeLib\{831FDD16-0C5C-11D2-A9FC-0000F8754DA1}\2.0]

Allerdings nicht gerade elegant, weil dabei nicht geprüft wird, ob der 2.1-Schlüssel vorhanden ist.

4. Edit 11.10.12: MS hat reagiert

Wie ich gerade lese, hat MS inzwischen auf die beschriebenen Probleme reagiert und folgende Artikel veröffentlicht:

für Office 2010: http://support.microsoft.com/kb/2597986

für Office2007: http://support.microsoft.com/kb/2687441

für Office 2003: http://support.microsoft.com/kb/2687323/de

52 Responses to MS zerstört durch KB2687441 die Kompatibilität von MSCOMCTL.OCX

  1. Bin auch gerade auf das Problem gestossen. Da kannich heute dann erstmal dabei gehen und ca. 10 Projekte, die z.T. seit 2 Jahren nicht geändert wurden, neu kompilieren (VB6). Bei mir half übrigens regsvr32 -u MSCOMCTL.OCX und regsvr32 MSCOMCTL.OCX als Administrator in der Konsole. Das ist eigentlich auch der Weg den MS hätte gehen müssen! Aber warum zu Geier erhöhen die für eine Security Update die Versionsnummer. So was ähnliches haben die mal mit den ADO Komponenten veranstaltet. Das war noch mieser.

  2. Lutz says:

    Wir haben auch massive Probleme mit diesem sch**** Update.

    Ich suche auch noch nach einem allgemeingültigem Weg, diesen Fehler zu fixen ohne Updates an alle Kunden verteilen zu müssen!

  3. Sergej Strelok says:

    der MS Support gibt grad folgenden Workaround raus http://blogs.technet.com/b/the_microsoft_excel_support_team_blog/archive/2012/08/15/quot-unspecified-automation-error-quot-after-applying-ms12-060.aspx ein echter Hotfix soll folgen. Oder einen Update für das Update.

    • intellipoint says:

      Oh cool, danke. Immerhin scheinen sie dann ja wenigstens auf das Problem aufmerksam geworden zu sein.

    • Sascha Trowitzsch says:

      Wäre übrigens noch zu erwähnen, dass es den gleichen mscomctl-Patch auch für Office 2010 gibt (KB2597986). Mit diesem hatte ich KEINE Probleme!
      Die Installationsroutine für den O2007-Patch schent nicht korrekt programmiert zu sein.

  4. Jochen says:

    Vielen Dank, Hat mir sehr weiter geholfen!!!

  5. MRe says:

    Vielen Dank für diesen Artikel, ich war gestern auch der Verzeiflung nahe. Schnell war klar, dass die Probleme mit einem Windowsupdate zusammenhängen, und ich konnte mir kurzfristig mit Systemrücksetzungen der betroffenen Windowssysteme behelfen, aber die Infos in diesem Artikel helfen wirklich weiter.
    Danke nochmal
    MRe

  6. FF says:

    Hallo Andreas
    Mir hat es auch 2 Tage gekostet. Ich habe die Mscomctl.ocx neu registiert dann ging es auf allen Rechnern wieder.
    So tief bin ich darum in die Materie nicht eingestiegen.

    Aber danke für den informativen Beitrag

    Frithjof

  7. Freddy says:

    Ich danke Dir vielmals!!!

  8. Freddy says:

    c:\windows\sysWOW64\regsvr32 -u mscomctl.ocx

    c:\windows\sysWOW64\regsvr32 mscomctl.ocx

    Mit Administratorrechten scheint auch zu helfen:
    http://answers.microsoft.com/en-us/windows/forum/windows_7-windows_update/security-update-for-mscomctlocx-kb2597986-ms12-060/6dadedda-7bfa-4569-91d8-a31ebcf6a08a?page=3

  9. FF says:

    Hallo nochmal ich
    hier der „böse“ Registryschlüssel nach der neuen Registrierung von Mscomctl.ocx

    Windows Registry Editor Version 5.00

    [HKEY_CLASSES_ROOT\TypeLib\{831FDD16-0C5C-11D2-A9FC-0000F8754DA1}]

    [HKEY_CLASSES_ROOT\TypeLib\{831FDD16-0C5C-11D2-A9FC-0000F8754DA1}\2.0]
    „PrimaryInteropAssemblyName“=“mscomctl, Version=10.0.4504.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35″

    [HKEY_CLASSES_ROOT\TypeLib\{831FDD16-0C5C-11D2-A9FC-0000F8754DA1}\2.1]
    @=“Microsoft Windows Common Controls 6.0 (SP6)“

    [HKEY_CLASSES_ROOT\TypeLib\{831FDD16-0C5C-11D2-A9FC-0000F8754DA1}\2.1]

    [HKEY_CLASSES_ROOT\TypeLib\{831FDD16-0C5C-11D2-A9FC-0000F8754DA1}\2.1\win32]
    @=“C:\\Windows\\SysWOW64\\MSCOMCTL.OCX“

    [HKEY_CLASSES_ROOT\TypeLib\{831FDD16-0C5C-11D2-A9FC-0000F8754DA1}\2.1\FLAGS]
    @=“2″

    [HKEY_CLASSES_ROOT\TypeLib\{831FDD16-0C5C-11D2-A9FC-0000F8754DA1}\2.1\HELPDIR]
    @=“C:\\Windows\\SysWOW64\\“

  10. mickdom says:

    Wir haben die Problematik auch. Dies scheint sich mit den versch. Office Versionen unterschiedlich bemerkbar zu machen. Bei uns waren in der Reg. (Windows 2003 TS und Office 2003) beide Einträge der Versionen 2.0 und 2.1 korrekt eingetragen. Lief trotzdem nicht. Haben dies aber mit Anwendung regsvr32 durch unregister und register auf mscomctl.ocx beheben können. Einzig Office 2007 klappt nicht! Eine Idee?

  11. Lutz says:

    Der Böse Schlüssel, ist der leere 2.0 Schlüssel, nachdem der 2.1 Schlüssel existiert!

    • Silversurfer says:

      Lutz, danke für Deinen Kommentar. Hatte bereits vor Tagen bei meinen zwei betroffenen Usern den Schlüssel umbenannt. Doch erst durch das Löschen des keys haben beide wieder Funktion. Hätte mich wahrscheinlich totgesucht. Vielen Dank!

  12. Sascha Trowitzsch says:

    Zu
    „Fragt sich zunächst einmal … warum in aller Welt hat man nur für ein Sicherheitsupdate die TypeLib-Versionsummer hochgesetzt? Ich verstehe es nicht! So etwas macht man meines Wissens eigentlich nur beim Einbau neuer Funktionen…“

    …Und das ist quasi passiert. Verschiedenen Controls wurde ein neues Interface spendiert – dem Listview etwa das IListview4, welches das bisherige IListview3 „überlädt“. Die neuen Interfaces enthalten indessen keinerlei neu Props/Methoden oder andere IDs/GUIDs. Folglich leitet MS offenbar die gleichnamigen Funktionsaufrufe in der VTable auf neu programmierte Routinen, die wohl die sicherheitsrelevanten Teile enthalten.

    Hätte man sicher auch anders und besser lösen können. Muss irgendwie mit Kompatibilität zusammenhängen. (…Die nun erst recht durchbrochen wurde.)

  13. mickdom says:

    Klar, sorry. Hatten intern ein Missverständnis. Haben da jetzt den 2.0 Schlüssel entfernt und funktioniert! Danke an all Eure hilfreichen Kommentare. 🙂

  14. Linne says:

    Haben auch Stress wegen diesem Patch….

    Wieso lässt der sich denn nicht über die Systemsteuerung deinstallieren? Dort steht nach der Installation „Das Update wurde entfernt“ und einen Entfernen-Button gibt es nicht. Einen Uninstall-Ordner gibt es auch nicht.

    Gibt es eine Möglichkeit diesen Patch zu deinstallieren?

    • intellipoint says:

      Ich würde nicht dazu raten, das neue Control zu deinstallieren. Das Patch hat ja grundsätzlich seine Berechtigung, wenn es ne Lücke stopft.

    • Sascha Trowitzsch says:

      Patch lässt sich nicht deinstallieren. Das Uninstallable-Flag ist auf TRUE gesetzt.
      (Für Deinstallation müsste der Winstaller die alte Version sichern, was er nicht tut.)

      • Linne says:

        Das habe ich schon befürchtet…

        Welche Patche lassen sich denn nicht deinstallieren und warum? Hängt das von der Kritikalität ab oder davon welche Konfigurationsänderungen ein Patch „macht“?

  15. Alfred M. says:

    Ich habe auch den Samstag Nachmittag und Sonntag Vormittag nach Lösungen gesucht. Das einzig wahre bisher: eine Systemwiederherstellung vom 14.08. am Morgen und das automatische Windows Update ausgeschaltet. Ich schalte es erst wieder an sobald Microsoft das rückgängig gemacht hat. Ich weiß allerdings nicht, ob die Anwendungen auf 64bit Maschinen nach diesem Update noch laufen.

    • intellipoint says:

      Das Problem scheint auf 32-bit und 64-bit Rechnern das gleiche zu sein. Ich glaube übrigens auch nicht, das MS irgendwas rückgängig macht. Auf ein Patch von denen warte ich jedenfalls nicht.

  16. rolo says:

    Artikel sehr hilfreich. Bei mir war es so, dass seit letztem Patchday der 2.1 Schlüssel weg war , nur noch ein 2.0 (mit Inhalt)….dadurch Fehler „Objektbibliothek nicht registriert“. Dass der Schlüüsel nicht zur Lib passt klam mir nicht in den Sinn – letzte Woche gings ja noch.
    De-registrieren, neu registrieren, geht wieder, 2.1er Schlüssel wieder da.
    Musste jetzt nur 2h vergeuden . 😦

  17. ptahsoft says:

    Einfach genial! ich habe gerade den ganzen Tag nach der Ursache gesucht.

    Perfekt beschrieben

  18. Joggingbrot says:

    Ich hab zwar die Reg bereinigt und auch neine De- und Neuregistierung der Mscomctl.ocx vorgenommen – jetzt werden meine Listviews ja immerhin schon mal wieder angezeigt – aber sobald ich mit der Maus drübergehe, kommt wie zuvor der ActiveX-MouseOver-Fehler.
    Verweise im Access sind auch alle gesetzt und gefunden, Reg wie gesagt um 2.0 bereinigt, 2.1 steht mit Unterpunkten drin.

    Vielleicht hat ja noch einer ne Idee.
    Danke für die Infos bisher – wirklich interessant

  19. Dennis says:

    Danke für den Hinweis. Problem ist durch das Löschen des 2.0 Schlüssels gelöst. Hoffentlich fixt Microsoft das Problem mit dem nächsten Update.

  20. Thomas says:

    @Joggingbrot

    Ich hatte das Mouseover-Problem bei einem Treeview und konnte es dadurch beheben, dass ich das Steuerelement gelöscht und neu eingefügt habe.
    Scheint aber wirklich nur vereinzelt Steuerelemente zu treffen. Es mag Zufall sein, aber das betroffene Formular war auch das, was ich „zum Testen“ während des Reparaturprozesses benutzt habe. Das gleiche Treeview in einer älteren Version war nicht betroffen.

  21. Joggingbrot says:

    @thomas
    ich bin bekleistert – funktioniert 🙂 Thx

  22. Mick says:

    Super, jetzt geht das auch bei mir wieder alles! Danke!

    • Dosen says:

      Hallo, ich habe die aktuelle mscomctl.ocx Version 6.1.98.34 von meinen Win7 Entwicklungsrechner genommen und auf den Client PC’s neuinstalliert. Und das Problem ist wieder weg.
      Hatte auf XP Clients die 6.1.98.33 und die machte dann die obengenannten Problem mit Access 2k3
      THX für diesen Blog! Sonst hätte ich wohl Tage gebraucht.

  23. CHris says:

    Hi,

    aktuell habe ich das Problem auf einem Rechner mit 2010, dass das treeview zwar angezeigt wird, der Aufruf aber nicht durchläuft. Sprich es wird zwar die nächste Ebene im Element angezeigt, aber die Daten werden nicht gezogen.
    Die Registry sieht auch normal aus, sprich kein leerer 2.0-Schlüssel, bzw. es ist erst gar kein 2.1 vorhanden.
    Any Ideas?

    CHris

  24. EI Systems says:

    Hi Chris, hatte genau das gleiche Problem (und in der Combobox zum Treeview erschienen nur die allgemeinen ActiveX Ereignisse Gotfocus, Lostfocus, Enter, Exit): regsvr c:\windows\syswow64\mscomctl.ocx reichte nicht – aber nach Aufruf als Admin schon. Danach bekam ich die oben beschriebenen MouseOver-Fehler (aber auch alle Ereignisse!), die sich durch Löschen und Neueinfügen des Treeviews beheben liessen. Schade daß ich diesen Hinweis erst jetzt gefunden habe – hatte aus lauter Verzweifelung schon auf die Hierarchische Ordnung verzichtet und durch flache Liste ersetzt… Nochmals herzlichsten Dank!!!

  25. Vladimír Duša says:

    Unregistrieren und wieder Registrieren „Als Administrator“ von c:\windows\syswow64\mscomctl.ocx hat bei uns geholfen – Win7 64bit.

    Ich habe eine Batch Datei mit folgendem Inhalt erstellt:
    @regsvr32 c:\windows\syswow64\mscomctl.ocx /u /s
    @regsvr32 c:\windows\syswow64\mscomctl.ocx /s
    @echo „Registration of Microsoft Windows Common Controls has been successfully repaired.“
    @pause

    Wenn diese datei „Als Administrator“ ausgeführt ist, wird das Problem mit mscomctl.ocx gelöst.

  26. Tixxi says:

    Hi,

    bei meinem XP-Rechner funktionieren nach der Neuregistrierung die Makros in Excel nur, wenn man als Admin eingeloggt ist und nicht, wenn man sich als normaler (Haupt-)Benutzer einloggt. Da kommt immer noch der Automatisierungsfehler…
    Hab den entsprechenden Schlüssel in der Registry gelöscht und die Neuregistrierung als Admin durchgeführt, wie schon mehrfach hier beschrieben.
    Hat jemand ne Lösung hierfür?

    Tixxi

  27. Lutz says:

    Kann es sein, daß es nach dem gestrigen Patchday wieder losgeht?

    Habe schon Rückmeldungen von eigentlich schon verarzteten Kunden.

    • intellipoint says:

      Bei mir jedenfalls gab es bis heute noch keine weiteren Probleme.

    • Micha says:

      Das kann ich bestätigen. Ich habe den regkey mit dem leeren 2.0 Schlüssel gelöscht und alles war gut. Nach dem installieren des Word2003 Sicherheitsupdates (kb2687483) ist der 2.0 Schlüssel wieder da und ebenfalls die Probleme. Was bleibt, ist den Schlüssel erneut zu löschen…grmpf. Da hat MS wieder ganze arbeit geleistet 😦

  28. WolfgangS says:

    Danke für den Tipp. Wir lassen einfach alles bei Version 2.0 (im vb6 Project file) , da eben diese lib bei XPSP2 mit dabei ist, was auch unsere (befohlene) Zielplattform ist.

    Zur Zeit wird eh‘ nach Windows7 umgestellt …

  29. Egon says:

    Also bei mir ist es so, dass das Problem immer wieder mal auftritt. Nach dem unregister und register funktioniert es wieder. Kann dann aber sein, dass ich das nach ein paar Tagen wieder machen muss… Woran kann das liegen? Hab das Update extra im WSUS abgelehnt…

  30. Marcel says:

    Vielen Dank für die gute Zusammenstellung aller relevanten Infos! Ist mittlerweile einer der ersten Treffer bei Google, wenn man nach „mscomctl.ocx“ sucht.

    Beste Grüße aus Hamburg

  31. Vielen Dank für diese Recherche und Problemlösung.

    Auch bei mir war das Problem, dass ein Sicherheitsupdate mir die MSCOMCTL.OCX in ein Automatisierungsfehler-Disaster verwandelt hat. Die Entfernung des (nicht ganz leeren) 2.0 Ordners brachte wieder Ruhe rein.

    Dieser Tip ist echt grandiios!

  32. Pingback: MS zerstört durch MS12-060; KB2687441;KB2597986 die Kompatibilität von MSCOMCTL.OCX » Persönliche Aufzeichnungen

  33. Vielen Dank! Das dieses Problem auftauchen kann, muss ich sogar noch 2014 bestätigen…
    Bei dem betroffenen 2008 R2 Terminal-Server war der 2.0 Schlüssel nicht leer und der 2.1 Schlüssel nicht vorhanden, aber durch Deinen Artikel konnte ich darauf schließen, dass es reicht 2.0 einfach auf 2.1 umzubenennen – und siehe da es hat sofort geklappt 🙂
    THX!

  34. Frank says:

    Auch von mir vielen Dank! … die Hinweise hier und die Installation von „KB 2726929 vom 11. Dezember 2012“ haben mir den „A**** gerettet“ (sorry). … unser komplettes ERP-System konnte ich nun portieren – und da hängen 110 Arbeitsplätze dran.

  35. Mike says:

    Habt ihr auch das Problem, dass es wirklich in regelmäßigen Abständen wieder auftaucht? An Arbeitsplätzen mit Office 2007 und Office 2013

    • intellipoint says:

      Ja. Ich habe aber inzwischen in allen Access-Anwendungen alle CommonControls-Steuerelemente durch die neue Version ausgetauscht. War zwar ne ganze Menge Arbeit (vielen Dank an MS ;-), aber seitdem habe ich das Problem nicht mehr.

      • Mike says:

        Hey, danke für deine schnelle Antwort 🙂
        Meinst du in deinen Access Anwendungen hat du den Verweis getauscht? Bei mir gibt es hier nur einen. Oder meinst du eine andere Stelle?
        Danke

      • intellipoint says:

        Nein, ich hab die entsprechenden Steuerelemente (z.B. TreeView) explizit rausgelöscht und neu eingefügt. Einen Verweis auf mscomctl.ocx hatte ich eh nicht drin (Late Binding).

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden /  Ändern )

Google Foto

Du kommentierst mit Deinem Google-Konto. Abmelden /  Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden /  Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden /  Ändern )

Verbinde mit %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.