10
System-Prozess erzeugt hohe CPU-Last
Hallo zusammen,
ich habe ein Problem und bin mit meinem Latein am Ende. Vielleicht hat hier noch jemand eine Idee. Meine Suche im Netz hat nach gut 100 Seiten mit immer den ähnlichen Ansätzen keine Lösung ergeben.
Folgender Sachverhalt: vmware Umgebung, Inplace-Upgrade eines W2k12R2 zu Server 2025. Der W2k12R2 wurde vor dem Upgrade gut von mir versorgt und so gut wie möglich vorbereitet. Das Upgrade selbst lief zügig durch und war in dem Sinne auch erfolgreich. Die VM läuft stabil und übernimmt ihre Aufgabe; ABER... seit dem Upgrade laufen die 4 Kerne der virt. CPU auf 77% (ziemlich konstant) und hin und wieder auf 100% Auslastung. Das ist leider nicht so schön, weil der Server eigentlich nicht mehr ist als ein Lizenz-Server der hin und wieder mal eine Lizenz ausgibt für ein Taschen-Rechner System von TI.
Also an sich hat die VM 99% des Tages nix zu tun.
Was ich bereits versucht habe:
- Reboot (mehrfach)
- Dem System Zeit geben (1 Woche ist bereits ins Land gegangen)
- Windows-Updates aktuell
- Änderung der virtuellen Hardware -> 4 zu 8 Kernen und wieder auf 4
- sfc /scannow
- dism /online /cleanup-image /restorehealth
- Aufgabenplanung überprüft
- vmware-Tools neu installiert
- Kompatibilität an der vm angepasst (vcenter)
- procdump auf den System-Dienst angewendet, leider nicht supported
- handle (sysinternals) angewendet, leider wieder keine weiteren Erkenntnisse zum System-Prozess
- mit dem Process-Explorer nach Details gesucht:
- 3 Prozesse verursachen fast die gesamten 70% Last: ntoskrnl.exe!RTlNumberOfSetBitsEx+0x680
Vielen Dank schon mal vorab für alle Ideen und Hinweise.
Kommt gut ins Wochenende.
Viele Grüße,
noaiming
ich habe ein Problem und bin mit meinem Latein am Ende. Vielleicht hat hier noch jemand eine Idee. Meine Suche im Netz hat nach gut 100 Seiten mit immer den ähnlichen Ansätzen keine Lösung ergeben.
Folgender Sachverhalt: vmware Umgebung, Inplace-Upgrade eines W2k12R2 zu Server 2025. Der W2k12R2 wurde vor dem Upgrade gut von mir versorgt und so gut wie möglich vorbereitet. Das Upgrade selbst lief zügig durch und war in dem Sinne auch erfolgreich. Die VM läuft stabil und übernimmt ihre Aufgabe; ABER... seit dem Upgrade laufen die 4 Kerne der virt. CPU auf 77% (ziemlich konstant) und hin und wieder auf 100% Auslastung. Das ist leider nicht so schön, weil der Server eigentlich nicht mehr ist als ein Lizenz-Server der hin und wieder mal eine Lizenz ausgibt für ein Taschen-Rechner System von TI.
Also an sich hat die VM 99% des Tages nix zu tun.
Was ich bereits versucht habe:
- Reboot (mehrfach)
- Dem System Zeit geben (1 Woche ist bereits ins Land gegangen)
- Windows-Updates aktuell
- Änderung der virtuellen Hardware -> 4 zu 8 Kernen und wieder auf 4
- sfc /scannow
- dism /online /cleanup-image /restorehealth
- Aufgabenplanung überprüft
- vmware-Tools neu installiert
- Kompatibilität an der vm angepasst (vcenter)
- procdump auf den System-Dienst angewendet, leider nicht supported
- handle (sysinternals) angewendet, leider wieder keine weiteren Erkenntnisse zum System-Prozess
- mit dem Process-Explorer nach Details gesucht:
- 3 Prozesse verursachen fast die gesamten 70% Last: ntoskrnl.exe!RTlNumberOfSetBitsEx+0x680
Vielen Dank schon mal vorab für alle Ideen und Hinweise.
Kommt gut ins Wochenende.
Viele Grüße,
noaiming
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 671674
Url: https://administrator.de/forum/system-prozess-erzeugt-hohe-cpu-last-671674.html
Ausgedruckt am: 28.02.2025 um 11:02 Uhr
10 Kommentare
Neuester Kommentar
Moin,
habe mal nur recht sporadisch die Enten befragt. Vieles deutet auf ein Treiberproblem hin. Ist da alles in Butter?
VG
habe mal nur recht sporadisch die Enten befragt. Vieles deutet auf ein Treiberproblem hin. Ist da alles in Butter?
VG
Wie kann ich das ausräumen? Gibt es eine Verbindung von ntoskrnl.exe!RTlNumberOfSetBitsEx+0x680 zu einem Treiber?
An sich könnte das ja gut sein, von 2012R2 zu 2025 ist ja auch ein erheblicher Sprung. Im Geräte-Manager ist an sich alles i.O., bis auf:
Da behauptet das System aber, das die besten Treiber bereits installiert sind.
An sich könnte das ja gut sein, von 2012R2 zu 2025 ist ja auch ein erheblicher Sprung. Im Geräte-Manager ist an sich alles i.O., bis auf:
Da behauptet das System aber, das die besten Treiber bereits installiert sind.
Hast du die aktuelle Version der VMware Tools in der VM installiert? Die wird vermutlicht alle nötigen Treiber liefern
Und welche VmWare hast Du als Unterbau? Eventuell sind die alten Treiber von VmWare nicht brauchbar.
Zitat von @NoAiming:
Wie kann ich das ausräumen? Gibt es eine Verbindung von ntoskrnl.exe!RTlNumberOfSetBitsEx+0x680 zu einem Treiber?
An sich könnte das ja gut sein, von 2012R2 zu 2025 ist ja auch ein erheblicher Sprung. Im Geräte-Manager ist an sich alles i.O., bis auf:
Da behauptet das System aber, das die besten Treiber bereits installiert sind.
Wie kann ich das ausräumen? Gibt es eine Verbindung von ntoskrnl.exe!RTlNumberOfSetBitsEx+0x680 zu einem Treiber?
An sich könnte das ja gut sein, von 2012R2 zu 2025 ist ja auch ein erheblicher Sprung. Im Geräte-Manager ist an sich alles i.O., bis auf:
Da behauptet das System aber, das die besten Treiber bereits installiert sind.
Aktuelle VMware Tools installieren, wie die Kollegen schon schrieben. (ggf. die Alten vorab deinstallieren)
Gruß
Moin, wie oben bereits aufgelistet, vmware-Tools sind deinstalliert und neu installiert worden. Der ESXi ist auf Stand VMware ESXi, 8.0.2, 23825572
Kann es sein, dass 2025 noch zu frisch ist? Leider kann ich die Hosts nicht mal eben so wegen dieses recht unwichtigen Servers updaten.
Kann es sein, dass 2025 noch zu frisch ist? Leider kann ich die Hosts nicht mal eben so wegen dieses recht unwichtigen Servers updaten.
Versuche folgendes mal (die 3 VMware VMCI Hosts Devices löschen) und neu von Windows suchen lassen.
Ggf. findet sich Windows dann wieder zurecht.
Idee kommt von:
community.broadcom.com/vmware-cloud-foundation/discussion/vmware-tools-re-install-or-upgrade-creates-duplicate-vmci-host-driver-in-windows-2016-server
Gruß
Ggf. findet sich Windows dann wieder zurecht.
Idee kommt von:
community.broadcom.com/vmware-cloud-foundation/discussion/vmware-tools-re-install-or-upgrade-creates-duplicate-vmci-host-driver-in-windows-2016-server
Right-click on each duplicate entry and select Uninstall Device. Select the checkbox that says "Delete the driver software for this device" and click Uninstall.
Repeat this process for all duplicate VMCI Host devices.
Once you have uninstalled all duplicate VMCI Host devices, right-click on the System Devices category and select Scan for hardware changes.
This will trigger Windows to search for and reinstall the missing driver.
Reboot the server to ensure that the changes take effect.Gruß
Kann es sein, dass 2025 noch zu frisch ist
Ich stelle mir eher die Frage, wieso Du das nicht im Labor nachgestellt hast und es dort initial erstmal probiert hast, anstatt mit der Karre gleich live zu gehen bei so einem riesen Schritt.
Eine Testumgebung gibt es leider nicht; wäre auch eher mein Wunsch gewesen, aber vom Vorgesetzten kam die Anweisung "gib Gas, Feuer frei." 
Moin,
sofern es nicht das Treiberproblem ist:
wenn ich das richtig verstehe, läuft ja alles. Dann die VM weiter laufen lassen und daneben den Server als VM frisch neu aufsetzen und Lizenzserver umziehen.
Gruß
DivideByZero
sofern es nicht das Treiberproblem ist:
wenn ich das richtig verstehe, läuft ja alles. Dann die VM weiter laufen lassen und daneben den Server als VM frisch neu aufsetzen und Lizenzserver umziehen.
Gruß
DivideByZero
aber vom Vorgesetzten
Lass mich raten, der Mensch hat keine Ahnung von IT?Oh man. Naja, dann muss der Vorgesetzte damit nun leben, dass es aktuell nicht rund läuft ohne Teststellung.
Irgendwie schade, dass es funktioniert hat. Manchmal müssen "Entscheider" Dreck fressen um zu wissen, wie es schmeckt. (nicht Dir gegenüber böse gemeint!) So'n Vollausfall vom Lizenzsrv weils Upgrade nicht durchlief, wäre vielleicht eine Lehre gewesen.
gib Gas, Feuer frei.
Klassiker... Dann die VM weiter laufen lassen und daneben den Server als VM frisch neu aufsetzen und Lizenzserver umziehen.
+1Gruß
