3
Hohe Serverauslastung durch srv2.sys+0x27400 nach Installation von Dezember-Updates auf Win7-Clients
Hallo!
Wir haben u.a. einen SMB-Fileserver (Windows 2008 R2), der auf einem ESX-Host läuft. Nachdem wir am Abend des 27. Dezember auf etwa 30 bis 40 Windows-7-Clients die Dezember-Updates(*) über WSUS installiert haben, stieg die Last auf diesem Server zu unseren Geschäftszeiten rapide an (siehe Grafik), ist aber auch außerhalb der Geschäftszeiten höher als normal, sofern nicht wie vorgestern nachts ein Neustart durchgeführt wurde. Unsere Nutzer schalten die Rechner aus, wenn sie nicht arbeiten. An einem Arbeitsplatz arbeitet genau ein Nutzer. Auf dem betroffenen Server selbst wurden im Dezember keine Updates installiert. Etwa zum gleichen Zeitpunkt wie die Windows-Updates wurde auch ein neuer McAfee-Client an die Clients ausgerollt, den wir leider nicht komplett ausschließen können, aber dessen Update war bereits mittags.
Die hohe CPU-Last kommt durch Threads namens srv2.sys+0x27400 im System-Prozess. Microsoft nennt in diesem Zusammenhang Probleme mit der Zugriffsbasierten Auflistung (ABE) als Grund, allerdings ist ABE auf allen Freigaben dieses Servers deaktiviert und man sieht dementsprechend tatsächlich Ordner, die man nicht öffnen kann. Wir haben den in dem Zusammenhang erwähnten Patch KB2920591 trotzdem auf dem Server installiert und den genannten Registry-Eintrag ABELevel auf 2 gesetzt, was erwartungsgemäß keine Änderung brachte.
Einige Nutzer klagen seither auch über Probleme mit MS-Access-Anwendungen: Sind bereits Access-Anwendungen gestartet und hat man damit einige Zeit (ca. 10 bis 30 Minuten) gearbeitet, benötigt das Starten weiterer Access-Anwendungen viele Minuten. In dieser Zeit sieht man nur einen neuen Prozess im Task-Manager. Haben diejenigen Nutzer, die die größten Probleme mit Access haben, Feierabend, sinkt die CPU-Last des Servers erheblich. Es haben aber bei weitem nicht alle Nutzer Probleme mit Access, nur etwa 10 bis 15%. Eine gute Handvoll Nutzer, die keine Probleme haben, sind auch samstags in der Firma gewesen, wo die CPU-Last vergleichsweise gering blieb. Stark betroffene Rechner sind x86- und x64-Plattformen unterschiedlicher Hersteller (Zotac ZBOX und Intel NUC). Access und Access-Dateien befinden sich lokal auf den Rechnern, als Datenbankserver fungieren mehrere SQL Server in Version 2008 R2 und 2014.
Sind euch ähnliche Probleme durch die Dezember-Patches, Dinge zum Testen oder vielleicht Lösungen bekannt? Wir werden die Updates sonst wohl erst einmal deinstallieren bzw. die stark betroffenen Rechner austauschen, um Untersuchungen mit Wireshark anzustellen, warum Access so langsam startet.
Vielen Dank.
(*) Mit Dezember-Updates meine ich die Updates mit Dezember 2018 im Namen, also die vom Patch Tuesday (.NET-Rollup KB4471987, .NET-Sicherheitsupdate KB4471981, MRT KB890830, Sicherheitsupdate KB4471328, Rollup KB4471318, kumulative IE11-Update KB4470199) und das einsame zusätzliche kumulative IE11-Update vom 19.12. (KB4483187). Alle "wichtigen" Updates, die vor Dezember 2018 veröffentlicht wurden, waren bereits installiert.
Wir haben u.a. einen SMB-Fileserver (Windows 2008 R2), der auf einem ESX-Host läuft. Nachdem wir am Abend des 27. Dezember auf etwa 30 bis 40 Windows-7-Clients die Dezember-Updates(*) über WSUS installiert haben, stieg die Last auf diesem Server zu unseren Geschäftszeiten rapide an (siehe Grafik), ist aber auch außerhalb der Geschäftszeiten höher als normal, sofern nicht wie vorgestern nachts ein Neustart durchgeführt wurde. Unsere Nutzer schalten die Rechner aus, wenn sie nicht arbeiten. An einem Arbeitsplatz arbeitet genau ein Nutzer. Auf dem betroffenen Server selbst wurden im Dezember keine Updates installiert. Etwa zum gleichen Zeitpunkt wie die Windows-Updates wurde auch ein neuer McAfee-Client an die Clients ausgerollt, den wir leider nicht komplett ausschließen können, aber dessen Update war bereits mittags.
Die hohe CPU-Last kommt durch Threads namens srv2.sys+0x27400 im System-Prozess. Microsoft nennt in diesem Zusammenhang Probleme mit der Zugriffsbasierten Auflistung (ABE) als Grund, allerdings ist ABE auf allen Freigaben dieses Servers deaktiviert und man sieht dementsprechend tatsächlich Ordner, die man nicht öffnen kann. Wir haben den in dem Zusammenhang erwähnten Patch KB2920591 trotzdem auf dem Server installiert und den genannten Registry-Eintrag ABELevel auf 2 gesetzt, was erwartungsgemäß keine Änderung brachte.
Einige Nutzer klagen seither auch über Probleme mit MS-Access-Anwendungen: Sind bereits Access-Anwendungen gestartet und hat man damit einige Zeit (ca. 10 bis 30 Minuten) gearbeitet, benötigt das Starten weiterer Access-Anwendungen viele Minuten. In dieser Zeit sieht man nur einen neuen Prozess im Task-Manager. Haben diejenigen Nutzer, die die größten Probleme mit Access haben, Feierabend, sinkt die CPU-Last des Servers erheblich. Es haben aber bei weitem nicht alle Nutzer Probleme mit Access, nur etwa 10 bis 15%. Eine gute Handvoll Nutzer, die keine Probleme haben, sind auch samstags in der Firma gewesen, wo die CPU-Last vergleichsweise gering blieb. Stark betroffene Rechner sind x86- und x64-Plattformen unterschiedlicher Hersteller (Zotac ZBOX und Intel NUC). Access und Access-Dateien befinden sich lokal auf den Rechnern, als Datenbankserver fungieren mehrere SQL Server in Version 2008 R2 und 2014.
Sind euch ähnliche Probleme durch die Dezember-Patches, Dinge zum Testen oder vielleicht Lösungen bekannt? Wir werden die Updates sonst wohl erst einmal deinstallieren bzw. die stark betroffenen Rechner austauschen, um Untersuchungen mit Wireshark anzustellen, warum Access so langsam startet.
Vielen Dank.
(*) Mit Dezember-Updates meine ich die Updates mit Dezember 2018 im Namen, also die vom Patch Tuesday (.NET-Rollup KB4471987, .NET-Sicherheitsupdate KB4471981, MRT KB890830, Sicherheitsupdate KB4471328, Rollup KB4471318, kumulative IE11-Update KB4470199) und das einsame zusätzliche kumulative IE11-Update vom 19.12. (KB4483187). Alle "wichtigen" Updates, die vor Dezember 2018 veröffentlicht wurden, waren bereits installiert.
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 397940
Url: https://administrator.de/contentid/397940
Printed on: April 19, 2024 at 16:04 o'clock
3 Comments
Latest comment
Danke für die Antwort. Wenn alle Informationen in dem Thread korrekt sind, haben wir ein anderes Problem:
Vielleicht noch eine interessante Information: Nachdem am Abend ein Switch getauscht wurde, an den der Server angeschlossen war, sank die Last des Servers wieder auf 0%, obwohl sie bis dahin – wie in der Nacht zuvor – insbesondere auf Kern 1 höher war und obwohl ein Nutzer mit Problemen sich nicht abgemeldet oder den PC heruntergefahren hat.
- Wir verwenden ausschließlich Access 2007 und nutzen keine MDBs (nur SQL Server und teilweise lokale Tabellen in der ACCDB).
- Die Probleme treten nicht erst durch Januar-Updates sondern schon im Dezember auf.
- Im verlinkten Thread ist davon die Rede, dass ein "ungültiges Dateiformat" gemeldet wird. Bei uns kommt, wenn überhaupt, irgendwann eine Meldung dass DDE nicht reagiere.
- Das im Thread erwähnte Problem scheint zuverlässig auf allen PCs mit dem Update aufzutreten, bei uns beschränkt es sich auf einige PCs/Nutzer.
Vielleicht noch eine interessante Information: Nachdem am Abend ein Switch getauscht wurde, an den der Server angeschlossen war, sank die Last des Servers wieder auf 0%, obwohl sie bis dahin – wie in der Nacht zuvor – insbesondere auf Kern 1 höher war und obwohl ein Nutzer mit Problemen sich nicht abgemeldet oder den PC heruntergefahren hat.
Wie Wireshark zu Tage förderte, lag das Problem daran, dass die Datei %APPDATA%\Microsoft\IMJP10\imjp10u.dic (und der Ordner) bei den betroffenen Nutzern fehlte. Dabei müsste es sich um das IME-Wörterbuch von Office 2007 handeln. Der Profilordner ist bei uns zu einem Netzwerkpfad gemappt.
Wieso das Problem zeitlich mit der Installation der Dezember-Updates plötzlich auftrat, ist uns nicht bekannt, weil auch Rechner, auf denen alle besagten Updates deinstalliert wurden, trotzdem auf diese fehlende Datei zugriffen.
Durch Erstellen der Datei sank die CPU-Last augenblicklich und die alle aufgestauten Access-Anwendungen öffneten sich sofort und ohne Neustart des Rechners oder von Access.
Wieso das Problem zeitlich mit der Installation der Dezember-Updates plötzlich auftrat, ist uns nicht bekannt, weil auch Rechner, auf denen alle besagten Updates deinstalliert wurden, trotzdem auf diese fehlende Datei zugriffen.
Durch Erstellen der Datei sank die CPU-Last augenblicklich und die alle aufgestauten Access-Anwendungen öffneten sich sofort und ohne Neustart des Rechners oder von Access.
