Wer Probleme mit abstürzenden Programmen bekommt, bei denen Aclayers.dll mit genannt wird, der hat es mit Problemen des Application Compatibility Toolkit (ACT) von Windows zu tun.
Einleitung
Bereits bei Windows 2000 findet man das Verzeichnis C:\WINNT\APPPATCH welches die Aclayers.dll beinhaltet. Unter Windows XP ist diese natürlich nach C:\WINDOWS\APPPATCH gewandert. Auch Unter Windows 8 findet man dort die AcLayers.DLL noch. In Verbindung mit Aclayers.dll werden immer wieder msimain.sdb, drvmain.sdb, pcamain.sdb und sysmain.sdb genannt. Dies sind die einzelnen Datenbanken, welche die Kompatibilitätseinstellungen bzw. Meldungen für Programme und Treiber enthalten.
Dass ein Programm im Kompatibilitätsmodus ausgeführt wird, kann man immer im sehr schön im ProcessExplorer von Sysinternals erkennen, indem man sich bei der Lower Pane View die DLLs die der einzelne Prozess geladen hat anzeigen lässt. Dort taucht dann immer Aclayers.DLL auf.
Wenn man Programme mittels ProcMon.EXE beobachtet bzw. aufruft, findet sich hier immer der Aufruf von C:\WINDOWS\SYSTEM32\APPHELP.DLL. AppHelp.DLL ist die API für die Kompatibilitätsanfragen. Windows steuert je nachdem was in den Kompatibilitätsdatenbanken hinterlegt ist, welche Umgebung die Anwendung vorgesetzt bekommt oder ob evtl. auch eine Meldung angezeigt wird oder gar der Start blockiert wird.
Eine gute Erklärung, was genau passiert, wenn ein Programm im Kompatibilitätsmodus ausgeführt wird, ist hier zu lesen: http://technet.microsoft.com/en-us/windows/jj863250.aspx. Dabei wird von Shims gesprochen worüber der eigentlichen Anwendung eine ältere Umgebung vorgegaukelt wird.
Komplette Erklärung der Möglichkeiten unter Windows XP: http://technet.microsoft.com/en-us/library/bb457032.aspx, unter dem Titel “Windows XP Application Compatibility Technologies”. Hier die aktuelle Fassung für Windows 8: http://technet.microsoft.com/en-us/library/hh825181.aspx.
Shim Database (.SDB) dumpen: http://blog.kalmbach-software.de/2010/02/22/the-shim-database/. Hier noch der Link zur API-Beschreibung für die Zugriff auf die .sdb-Dateien. http://msdn.microsoft.com/library/bb432182.aspx. Hier noch ein Utility zum Auslesen der SDB-Datenbanken: http://blogs.msdn.com/b/heaths/archive/2007/11/02/sdb2xml.aspx.
Übrigens ist die ganze Geschichte auch dafür verantwortlich, wenn ein Update von Windows7 auf Windows 8 nicht möglich ist, weil z. B. Programm XY installiert ist. Man kann davon ausgehen, dass in einer .SDB dann die betreffende Software erfasst ist und der Upgrade -Assistent genau dies prüft.
Ein guter Blog mit vielen Infos zum Thema: http://blogs.msdn.com/b/cjacks/.
Konkrete Problemlösung
Jetzt aber nochmal zurück zum Anfang. Bei einem Kunden kam es beim Aufruf eines Programms ständig zu Schutzverletzungen wegen AcLayers.DLL. Die Software welche bei der Schutzverletzung genannt wurde, war ein VB6 Programm, welches vor einem Update tadellos auf dem besagten Rechner lief. Bei der Recherche, was genau in dem Programm geändert wurde, stellte sich heraus, dass eine neuere Version von MSXML benutzt wurde. Diese neuere Version war anscheinend von AcLayers.DLL geblockt worden, blöderweise durch die Schutzverletzung. Warum, war erst nicht klar. Aber nach einigem Suchen stellte sich heraus, dass die Anwendung, welche die VB6-Anwendung aufrief, auf Kompatibilität zu Windows 95 eingestellt war. Damit wurde die Anwendung von MSXML verhindert, welches mindestens Windows 2000 benötigte. Ergo die Schutzverletzung mit AcLayers.DLL!
19 Januar 2013 um 14:39 |
Bei den Microsoft Updates werden die SDB-Dateien regelmäßig upgedatet: http://support.microsoft.com/kb/2774225 für Win 8 und für ältere Systeme: http://support.microsoft.com/kb/2492386/
5 Februar 2013 um 15:51 |
Make certain you are not using nLite to remove anything related to Application Compatibility. The necessary files for KB955759 are aclayers.dll and sysmain.sdb.