WinXP zu WSUS - Nach Anmeldung SVCHOST.EXE 100% CPU Last

[Plugstar 10]

Hallo zusammen,

 

Vorfeldbeschreibung:

 

Unsere Clients (XP, SP2), die Teil einer nicht AD-Domäne sind, sind mit unserem WSUS verbunden. Via Gruppenrichtlinieneditor habe ich das WSUS-spezifische ADM-Template ausgefüllt. Danach habe ich aus der Registry die Informationen herausgefiltert. Jeder XP-Rechner in unserer Domäne hat diesen Registry-Extrakt via psexec (pstools) eingespielt bekommen. Dadurch hat jeder Client die gleichen Einstellungen, welcher Server, für ihn die Updates bereithält, wie und wann diese zu installieren sind etc.

 

Meldet sich nun ein User an der Domäne an, kommt es sehr häufig vor, dass kurz nach der Anmeldung einer der svchost.exe Prozesse sich bis zu 99% der verfügbaren CPU-Power einverleibt. Über "Tasklist/svc | more" und der PID aus dem Taskmanager kann man den übereifrigen svchost-Prozess sehr schnell ausfindig machen. Dabei werden folgende Dienste ausgeführt.

 

• 
  - AudioSrv
  - BITS
  - Browser
  - CryptSvc
  - DHCP
  - dmserver
  - ERSvc
  - EventSystem
  - helpsvc
  - lanmanserver
  - lanmanworkstation
  - Netman
  - Nla
  - Schedule
  - seclogon
  - SENS
  - SharedAccess
  - ShelllHWDetection
  - srservice
  - Themes
  - TrkWks
  - W32Time
  - winmgmt
  - wuauserv
  - WZCSVG
  

 

Durch verschiedene Testläufe bei denen ich die Dienst durchgetestet hab, viel mir auf, dass wohl der wuauserv - Prozeß hier für den rasanten Anstieg des CPU-Hungers von svchost.exe sorgt.

 

Auf der Suche nach einer Lösung im Internet bin ich auf eine heisse Spur gestoßen:

[eXOs 10]

Hi,

 

da gabs letztens was zu, ob es gelöst wurde weiß ich nicht aber schau mal hier:

 

http://www.mcseboard.de/windows-forum-ms-backoffice-31/wsus-bringt-clients-100-auslastung-108016.html?highlight=WSUS+100

[Plugstar 10]

Hui, danke für deinen Post, ich war gerade dabei, die Fortsetzung zu schreiben ;)

 

von svchost.exe 100% CPU nach Anmeldung [Archive] - enteo Forum

Hallo Virgilio,

 

hatte bei einem Kunden diese Woche das gleiche Problem und zumindest einen

Ansatz gefunden, das Problem zu entschärfen (kannst ja mal schauen, ob das

bei euch auch so zutrifft):

 

Also zur Zeit ist es wohl so, dass jedesmal, wenn man Patches installiert

über "Neues Projekt für Microsoft-Patches" und es auf dem MS-Server eine

neue WSUSSCAN.CAB gibt (also einmal im Monat nach dem MS-Patchday), diese

(richtigerweise) runtergeladen und im Datenbank-Verzeichnis als

"PATCH_<8-stellige Hexzahl>.SEC" abgelegt wird. Die alten Versionen des

Files bleiben dabei aber in dem Verzeichnis erhalten - und das scheint das

Problem zu sein.

 

Jetzt isses so, dass dann auch alle die alten SEC-Dateien mit auf den Client

runterkopiert und auch beim Anmelden auch geparst werden. Kannst du daran

sehen, dass er im Taskmanager genausoviele Instanzen von WUPROXY.EXE

aufmacht wie es SEC-Files gibt. Je mehr SEC-Files, desto länger dauert es

logischerweise bis das durch ist und beim Kunden waren es auch ca. 5 Minuten

bei 100% Prozessorlast.

 

Was haben wir gemacht:

1. Löschen aller alten "PATCH_########.SEC" im Datenbank-Verzeichnis auf dem

Server und nur die neueste behalten. Da es sich dabei um eine umbenannte

Kopie der WSUSSCAN.CAB handelt, sollte die alles beinhalten was die Clients

brauchen

2. In der NID-Datei wird in einem Flag diese 8-stellige Nummer auch

refernziert. Ich bin dann noch zusätzlich mit nem Texteditor hin und habe

per Suchen/Ersetzen die Nummern, die auf die alten SECs verwiesen haben

ersetzt mit der Nummer der aktuellsten SEC-Datei und das File gespeichert.

3. Dann noch im Manager die DB einmal geöffnet, ein Dummy-Projekt angelegt

und wieder gelöscht und dann gespeichert, sodass die Checksummen-Datei usw.

vom Manager neu geschrieben wird und alles aktuell ist

 

Das war's. Tests auf den Clients haben ergeben, dass die Parsing-Zeit von 5

Minuten runter ist auf ca. 30 Sekunden und man dabei auch was anderes machen

kann, also ne Applikation starten oder im Explorer navigieren (hat zwar in

diesen 30 Sek. immer noch 100% Last, aber das ist wohl normal). Negative

Auswirkungen konnten wir keine feststellen.

 

Ich hoffe, damit könnt ihr eure Umgebung ein bißchen tunen und "die Oberen"

haben wieder mehr Spaß mit enteo...

 

Viele Grüße und schönes Wochenende

Frank

 

von svchost.exe 100% CPU nach Anmeldung [Archive] - enteo Forum

Kleiner Nachtrag:

- ich glaube, es waren doch nicht nur 30 Sekunden, sondern eher 90 Sekunden,

die er dann parst (aber immerhin deutlich schneller und wie gesagt, man

konnte parallel arbeiten)

- ob die SEC-Files auch (per NI-Script oder wie auch immer) auch auf dem

Client gelöscht werden müssen (liegen dort wohl unter %NIDIR%\WSUSCACHE)

oder ob das automatisch geht, da bin ich mir nicht wirklich sicher. Hier

hilft vermutlich ausprobieren ;-)

- ob das so supported ist (auch halt das manuelle Editieren der NID etc.),

da solltest du ggfs. beim enteo-Support anfragen. Mir wurde das Löschen der

alten PATCH_########.SEC als Workaround genannt. Das alleine reicht aber

nicht aus, weil die alten Versionen in der NID immer noch refernziert sind

und daher immer noch mehrere WUPROXY-Prozesse auftauchen (die zwar sehr

schnell verschwinden, weil er vermutl. die SECs nicht mehr findet, das aber

natürlich trotzdem Ressourcen kostet)

 

Gruß Frank

 

Leider komm ich mit dieser Beschreibung nicht weiter.

Ich finde weder die "PATCH_*.SEC", noch andere "*.sec" Dateien noch den Pfad "WSUSCACHE"

 

Kennt jemand eine Möglichkeit, diesen Fehler zu umgehen, oder am besten, um ihn ganz abzuschalten?

 

 

 

Danke für Eure Mühen