20
Exchange Windows-Hostprozess CPU 100 Prozent
Hallo zusammen,
wir haben bei einer Hand voll Exchange Server (Exchange 2016 und 2019) das Problem, dass diese sporadisch nicht mehr reagieren. Das Outlook meldet dann, dass die Verbindung unterbrochen wurde. Versucht man sich dann via RDP auf den Exchange Server aufzuwählen, dann klappt das, allerdings so langsam und träge, dass man teilweise 5-10 Minuten warten muss bis überhaupt etwas passiert. Hat man dann den Task-Manager nach 10 Minuten endlich mal geöffnet, fällt auf dass die CPU-Auslastung bei 99-100% hängt und davon meistens 70-80% der "Windows-Hostprozess (Rundll32) dies verursacht.
Als schnelle Lösung hilft oft einfach ein ausschalten der VM und anschließender Neustart. Dann ist das Problem direkt behoben. Alternativ kann man auch im Task-Manager den Task einfach killen und es geht auch innerhalb von 1 Minute wieder alles wie gehabt. Das "Phänomen" ist, dass wenn man den Server einfach mal 1-2-3 Stunden in Ruhe lässt es wie von Zauberhand auch wieder geht und die CPU Last wieder normal ist.
Oft tritt es in den Morgenstunden (zwischen 8 und 10) ein, manchmal aber auch nachmittags. Eine ganz feste Uhrzeit gibt es nicht. Zuerst hatte ich einen geplanten Virenscan in Verdacht, dies ist aber bei keinem der Server der Fall.
Hat jemand ein Ähnliches Phänomen schonmal gehabt und eine Lösung gefunden? Gibt es eine Möglichkeit herauszufinden was der "Windows-Hostprozess (Rundll32)" genau tut zu dem Zeitpunkt? Und wieso es keinerlei Einschränkungen gibt, wenn der Task einfach gekillt wird?
Gibt es sonstiges Lösungsansätze oder Ideen, wie man das Problem genauer eingrenzen könnte? Es gibt Tage da passiert das gar nicht, dann gibt es Tage da passiert es wirklich an 3-4 Tagen in Folge täglich.
Hier ein Screenshot vom Task-Manager (der nach ca. 10 Minuten geöffnet wurde, weil der Server so lahm war).
Für Tipps und Ideen bin ich sehr dankbar!
LG Dennis
wir haben bei einer Hand voll Exchange Server (Exchange 2016 und 2019) das Problem, dass diese sporadisch nicht mehr reagieren. Das Outlook meldet dann, dass die Verbindung unterbrochen wurde. Versucht man sich dann via RDP auf den Exchange Server aufzuwählen, dann klappt das, allerdings so langsam und träge, dass man teilweise 5-10 Minuten warten muss bis überhaupt etwas passiert. Hat man dann den Task-Manager nach 10 Minuten endlich mal geöffnet, fällt auf dass die CPU-Auslastung bei 99-100% hängt und davon meistens 70-80% der "Windows-Hostprozess (Rundll32) dies verursacht.
Als schnelle Lösung hilft oft einfach ein ausschalten der VM und anschließender Neustart. Dann ist das Problem direkt behoben. Alternativ kann man auch im Task-Manager den Task einfach killen und es geht auch innerhalb von 1 Minute wieder alles wie gehabt. Das "Phänomen" ist, dass wenn man den Server einfach mal 1-2-3 Stunden in Ruhe lässt es wie von Zauberhand auch wieder geht und die CPU Last wieder normal ist.
Oft tritt es in den Morgenstunden (zwischen 8 und 10) ein, manchmal aber auch nachmittags. Eine ganz feste Uhrzeit gibt es nicht. Zuerst hatte ich einen geplanten Virenscan in Verdacht, dies ist aber bei keinem der Server der Fall.
Hat jemand ein Ähnliches Phänomen schonmal gehabt und eine Lösung gefunden? Gibt es eine Möglichkeit herauszufinden was der "Windows-Hostprozess (Rundll32)" genau tut zu dem Zeitpunkt? Und wieso es keinerlei Einschränkungen gibt, wenn der Task einfach gekillt wird?
Gibt es sonstiges Lösungsansätze oder Ideen, wie man das Problem genauer eingrenzen könnte? Es gibt Tage da passiert das gar nicht, dann gibt es Tage da passiert es wirklich an 3-4 Tagen in Folge täglich.
Hier ein Screenshot vom Task-Manager (der nach ca. 10 Minuten geöffnet wurde, weil der Server so lahm war).
Für Tipps und Ideen bin ich sehr dankbar!
LG Dennis
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 1125849323
Url: https://administrator.de/forum/exchange-windows-hostprozess-cpu-100-prozent-1125849323.html
Ausgedruckt am: 26.12.2024 um 12:12 Uhr
20 Kommentare
Neuester Kommentar
Sieht nach "Speicherdruck" aus, wenn Du mich fragst.
Der Prozess versucht seine Warteschlange abzuarbeiten, kann das nicht und die schaukelt sich dann über und über auf.
Dann hat er natürlich, sobald er wieder loslegen könnte, ziemlich viel zu tun.
Der ProzessExplorer kann Dir ggfs. genauer aufschlüsseln, welcher Unterprozess unter rundll das Problem ist.
Gruß
bdmvg
Der Prozess versucht seine Warteschlange abzuarbeiten, kann das nicht und die schaukelt sich dann über und über auf.
Dann hat er natürlich, sobald er wieder loslegen könnte, ziemlich viel zu tun.
Der ProzessExplorer kann Dir ggfs. genauer aufschlüsseln, welcher Unterprozess unter rundll das Problem ist.
Gruß
bdmvg
Hallo Dennis,
ist zwar schon eine Weile her, dass ich hatte ähnliche Probleme bei einigen System hatte. (Bei mir waren es Exchange mehrere 2010 und ein 2016. Letzlich stellte es sich herraus, dass verschiedene Prozesse die hohe Auslastung brachten. u.a. die Store.exe. Ich hatte unterschiedliche Werte, mal war es RAM, dann mal cpu, mal war es die store.exe mal andere Prozesse.
Zwischenzeitlich ist man dort aber auf Tobit oder MS-Echange-Cloud umgestiegen. Somit weiß ich nicht obs Dir hilft. Mir hat es in allen Fällen geholfen, dass gleiche Verhalten hatte ich auch. Vielleicht klappt es. Ein Ansatz ist es allemal.
Hier der Link:
https://www.sysadminslife.com/windows/exchange-storeexe-hohe-ram-auslast ...
Viel Erfolg.
Werner
ist zwar schon eine Weile her, dass ich hatte ähnliche Probleme bei einigen System hatte. (Bei mir waren es Exchange mehrere 2010 und ein 2016. Letzlich stellte es sich herraus, dass verschiedene Prozesse die hohe Auslastung brachten. u.a. die Store.exe. Ich hatte unterschiedliche Werte, mal war es RAM, dann mal cpu, mal war es die store.exe mal andere Prozesse.
Zwischenzeitlich ist man dort aber auf Tobit oder MS-Echange-Cloud umgestiegen. Somit weiß ich nicht obs Dir hilft. Mir hat es in allen Fällen geholfen, dass gleiche Verhalten hatte ich auch. Vielleicht klappt es. Ein Ansatz ist es allemal.
Hier der Link:
https://www.sysadminslife.com/windows/exchange-storeexe-hohe-ram-auslast ...
Viel Erfolg.
Werner
Hallo Werner,
das hatten wir früher bei Exchange 2010 (und vor allem den SBS2011 Varianten) tatsächlich auch häufig mit dem RAM. Bei den Probleme jetzt ist es aber tatsächlich IMMER die CPU Last die so hoch ist und die RAM-Auslastung ist nachweislich per Monitoring eigentlich nie üb 60%, meistens sogar stabil bei ca. 50%. Daher würde ich das tatsächlich erstmal ausschließen.
Ich habe jetzt mal den ProcessExplorer am laufen und warte quasi auf den nächsten "Crash" um dann mal etwas genauer zu schauen, was die hohe Auslastung dort verursacht. Es tritt teilweise bspw. auch bei Exchange-Servern auf, wo vielleicht 50 eMails am Tag nur ankommen, daher würde ich es auch nicht auf eine zu volle Warteschlange schieben wollen. Aber man weiß ja nie!
LG Dennis
das hatten wir früher bei Exchange 2010 (und vor allem den SBS2011 Varianten) tatsächlich auch häufig mit dem RAM. Bei den Probleme jetzt ist es aber tatsächlich IMMER die CPU Last die so hoch ist und die RAM-Auslastung ist nachweislich per Monitoring eigentlich nie üb 60%, meistens sogar stabil bei ca. 50%. Daher würde ich das tatsächlich erstmal ausschließen.
Ich habe jetzt mal den ProcessExplorer am laufen und warte quasi auf den nächsten "Crash" um dann mal etwas genauer zu schauen, was die hohe Auslastung dort verursacht. Es tritt teilweise bspw. auch bei Exchange-Servern auf, wo vielleicht 50 eMails am Tag nur ankommen, daher würde ich es auch nicht auf eine zu volle Warteschlange schieben wollen. Aber man weiß ja nie!
LG Dennis
Moin,
wie viele Prozessoren, Cores haben die Exchange Server?
wie viel Arbeitsspeicher haben die Exchange Server?
Gruß,
Dani
wie viele Prozessoren, Cores haben die Exchange Server?
wie viel Arbeitsspeicher haben die Exchange Server?
Gruß,
Dani
Zitat von @Dani:
Moin,
wie viele Prozessoren, Cores haben die Exchange Server?
wie viel Arbeitsspeicher haben die Exchange Server?
Gruß,
Dani
Moin,
wie viele Prozessoren, Cores haben die Exchange Server?
wie viel Arbeitsspeicher haben die Exchange Server?
Gruß,
Dani
Hey!
Das ist tatsächlich unterschiedlich.
Der kleinste hat 32GB RAM und 4 vCPU (1Socket - 4 Kerne).
Der größte mit dem Problem hat 128GB RAM und 8 vCPU (2Socket - 4 Kerne).
Problem ist beim großen tatsächlich heute Morgen wieder aufgetreten. Im Process Explorer war leider auch nur ersichtlich, dass es der Windows-Hostprozess (Rundll32) ist, keine näheren Infos. Auch hier wieder ein einfacher Task beenden und es ging wieder ruck zuck.
LG Dennis
Moin Dennis,
Weil je nachdem sind die Server deutlich zu klein dimensoniert. Ich lege dir das Tool Exchange Server 2019 Capacity Calculator ans Herz.
Gruß,
Dani
Der kleinste hat 32GB RAM und 4 vCPU (1Socket - 4 Kerne).
Der größte mit dem Problem hat 128GB RAM und 8 vCPU (2Socket - 4 Kerne).
Wie viel Postfächer und wie groß sind die Datenbanken?Der größte mit dem Problem hat 128GB RAM und 8 vCPU (2Socket - 4 Kerne).
Weil je nachdem sind die Server deutlich zu klein dimensoniert. Ich lege dir das Tool Exchange Server 2019 Capacity Calculator ans Herz.
Gruß,
Dani
Zitat von @Dani:
Moin Dennis,
Weil je nachdem sind die Server deutlich zu klein dimensoniert. Ich lege dir das Tool Exchange Server 2019 Capacity Calculator ans Herz.
Gruß,
Dani
Moin Dennis,
Der kleinste hat 32GB RAM und 4 vCPU (1Socket - 4 Kerne).
Der größte mit dem Problem hat 128GB RAM und 8 vCPU (2Socket - 4 Kerne).
Wie viel Postfächer und wie groß sind die Datenbanken?Der größte mit dem Problem hat 128GB RAM und 8 vCPU (2Socket - 4 Kerne).
Weil je nachdem sind die Server deutlich zu klein dimensoniert. Ich lege dir das Tool Exchange Server 2019 Capacity Calculator ans Herz.
Gruß,
Dani
Beim kleinsten Exchange sind es 4 Postfächer beim "großen" sind es ca. 20 Postfächer.
Wir haben ja auch Kunden mit gleichen Spezifikationen (RAM, CPU, Anzahl Postfächer) bei denen das Problem noch nie aufgetreten ist. Deswegen verstehe ich es ja nicht wirklich.
Moin,
Gruß,
Dani
Beim kleinsten Exchange sind es 4 Postfächer beim "großen" sind es ca. 20 Postfächer.
okay, das passt eigentlich.Als schnelle Lösung hilft oft einfach ein ausschalten der VM und anschließender Neustart.
Nach Aus/Einschalten noch ein Neustart? Hmm... was kommt für eine Hypervisor zum Einsatz?Gruß,
Dani
Nach Aus/Einschalten noch ein Neustart? Hmm... was kommt für eine Hypervisor zum Einsatz?
Damit meinte ich eigentlich VM "hart" ausschalten und anschließend normal starten. Hypervisor sind überall VMware ESXi 6.
Moin,
Gruß,
Dani
Hypervisor sind überall VMware ESXi 6.
6.0, 6.5. 6.7? Patchstand?Gruß,
Dani
Hypervisor sind überall VMware ESXi 6.
6.0, 6.5. 6.7? Patchstand?Hälfte 6.5 und Hälfte 6.7, alle auf aktuellem Patch-Level für die Version
Zitat von @Dennis93:
Im Process Explorer war leider auch nur ersichtlich, dass es der Windows-Hostprozess (Rundll32) ist, keine näheren Infos.
Klick dort mal doppelt auf den Prozess, dann auf den Reiter Threads, und dort dann doppelt auf den Eintrag der am meisten CPU beansprucht, dort steht dann detailliert welche Funktionen/DLL-Aufrufe sich aktuell im Stack des Threads befinden.Im Process Explorer war leider auch nur ersichtlich, dass es der Windows-Hostprozess (Rundll32) ist, keine näheren Infos.
Bsp.
Hey, das habe ich jetzt aktuell mal getan, leider kann ich den Eintrag unter Threads nicht öffnen, erhalte dort eine Fehlermeldung.
Zitat von @Dennis93:
Hey, das habe ich jetzt aktuell mal getan, leider kann ich den Eintrag unter Threads nicht öffnen, erhalte dort eine Fehlermeldung.
Starte den ProcessExplorer mal mit System-Rechten (via psexec -i -s)Hey, das habe ich jetzt aktuell mal getan, leider kann ich den Eintrag unter Threads nicht öffnen, erhalte dort eine Fehlermeldung.
Hallo zusammen,
lange Verzögerung später, aber mittlerweile sind wir der Sache etwas mehr auf den Grund gegangen und haben herausgefunden, dass es sich wohl (trotz aktuellstem Patch-Level!) um Malware handelt!
Und zwar um eine Art Cryptominer, der CPU-Mining betreibt. Herausgefunden habe ich das dann letztendlich über unser Panda Adaptive Defense 360!
Der erkennt die Datei nämlich als Malware, schafft es aber wohl nicht sie zu "verbieten" oder die Ursache zu löschen.
Folgendes fällt auf:
CPU-Auslastung geht über Zeit immer höher, bis irgendwann beim Maximum. Aufgerufen wird die Rundll32.exe mit einem bestimmten Parameter über eine Datei "Star.exe" im TEMP Verzeichnis (die aber gar nicht da ist, wenn man sie sucht).
Es handelt sich um "pool <DOT> supportxmr <DOT> com" als Quelle / CPU-Mining-Software. (Siehe Screenshots).
Um erstmal kurzfristige Abhilfe zu schaffen, habe ich auf der Firewall sämtlichen Traffic von und zu der besagten URL blockiert! Das hilft vorübergehend zumindest etwas. Der Prozess wird zwar leider weiterhin gestartet, jedoch geht die CPU Last nicht so hoch, vermutlich weil er keine Verbindung aufbauen kann. Eine wirkliche Lösung des Haupt-Problems ist dies jedoch dennoch nicht. Vielleicht gibt es hier ja irgendwelche Tipps / Ideen? Ich habe zu der besagten Malware tatsächlich bei Google einige Einträge gefunden, jedoch bislang keine wirkliche Lösung. Was mich wundert ist, dass teilweise ältere Systeme (Exchange 2016 auf nicht aktuellstem Patch-Level) die Probleme nicht haben, obwohl auch mit 443 ins Internet geöffnet. Die Systeme, die das Problem aufweisen sind eigentlich alle (mittlerweile) auf aktuellstem CU und Sicherheitsupdate (CU21 mit Juli21SU!) Viele schlagen vor den Microsoft Safety Scanner MSERT laufen zu lassen. Dieser findet auch bei jedem Durchlauf 4-6 Bedrohungen und bereinigt sie angeblich. Beim Neustart des Servers und erneutem Suchlauf findet er diese jedoch immer und immer wieder.
Anbei die Screenshots:
LG Dennis
lange Verzögerung später, aber mittlerweile sind wir der Sache etwas mehr auf den Grund gegangen und haben herausgefunden, dass es sich wohl (trotz aktuellstem Patch-Level!) um Malware handelt!
Und zwar um eine Art Cryptominer, der CPU-Mining betreibt. Herausgefunden habe ich das dann letztendlich über unser Panda Adaptive Defense 360!
Der erkennt die Datei nämlich als Malware, schafft es aber wohl nicht sie zu "verbieten" oder die Ursache zu löschen.
Folgendes fällt auf:
CPU-Auslastung geht über Zeit immer höher, bis irgendwann beim Maximum. Aufgerufen wird die Rundll32.exe mit einem bestimmten Parameter über eine Datei "Star.exe" im TEMP Verzeichnis (die aber gar nicht da ist, wenn man sie sucht).
Es handelt sich um "pool <DOT> supportxmr <DOT> com" als Quelle / CPU-Mining-Software. (Siehe Screenshots).
Um erstmal kurzfristige Abhilfe zu schaffen, habe ich auf der Firewall sämtlichen Traffic von und zu der besagten URL blockiert! Das hilft vorübergehend zumindest etwas. Der Prozess wird zwar leider weiterhin gestartet, jedoch geht die CPU Last nicht so hoch, vermutlich weil er keine Verbindung aufbauen kann. Eine wirkliche Lösung des Haupt-Problems ist dies jedoch dennoch nicht. Vielleicht gibt es hier ja irgendwelche Tipps / Ideen? Ich habe zu der besagten Malware tatsächlich bei Google einige Einträge gefunden, jedoch bislang keine wirkliche Lösung. Was mich wundert ist, dass teilweise ältere Systeme (Exchange 2016 auf nicht aktuellstem Patch-Level) die Probleme nicht haben, obwohl auch mit 443 ins Internet geöffnet. Die Systeme, die das Problem aufweisen sind eigentlich alle (mittlerweile) auf aktuellstem CU und Sicherheitsupdate (CU21 mit Juli21SU!) Viele schlagen vor den Microsoft Safety Scanner MSERT laufen zu lassen. Dieser findet auch bei jedem Durchlauf 4-6 Bedrohungen und bereinigt sie angeblich. Beim Neustart des Servers und erneutem Suchlauf findet er diese jedoch immer und immer wieder.
Anbei die Screenshots:
LG Dennis
Ein so befallenes System ist potentiell immer eine Gefahr, denn du weist nicht was sonst noch was auf dem System gelandet ist und ob auch weiterhin Daten abfließen. Deswegen clean neu aufsetzen ist hier die einzig richtige Wahl, wenn du nicht noch weitere böse Überraschungen erleben willst!
Zitat von @149062:
Ein befallenes System ist protentiell immer eine Gefahr, denn du weist nicht was sonst noch was auf dem System gelandet ist und ob auch Daten abfließen. Deswegen neu aufsetzen ist hier die einzig richtige Wahl!
Ein befallenes System ist protentiell immer eine Gefahr, denn du weist nicht was sonst noch was auf dem System gelandet ist und ob auch Daten abfließen. Deswegen neu aufsetzen ist hier die einzig richtige Wahl!
Ja, sehe ich eigentlich auch so! Jetzt kommt mein großes ABER.
Der besagte Server von den Screenshots ist im Juli mit CU20 frisch neu installiert worden in einem neuen Netzwerk mit komplett neuer AD. Und trotzdem wurde er im Anschluss befallen. :o(
Zitat von @Dennis93:
Der besagte Server von den Screenshots ist im Juli mit CU20 frisch neu installiert worden in einem neuen Netzwerk mit komplett neuer AD. Und trotzdem wurde er im Anschluss befallen. :o(
Dann gehört da wohl mal eine Application Firewall oder reverse proxy davor gesetzt. Das Teil ist halt löchrig wie ein schweizer Käse.Der besagte Server von den Screenshots ist im Juli mit CU20 frisch neu installiert worden in einem neuen Netzwerk mit komplett neuer AD. Und trotzdem wurde er im Anschluss befallen. :o(
@149062
Gruß,
Dani
reverse proxy davor gesetzt. Das Teil ist halt löchrig wie ein schweizer Käse.
Letzteres stopft die Löcher aber nicht. Denn der Reverse Proxy leitet die Anfragen 1:1 erst einmal weiter.Gruß,
Dani
Zitat von @Dani:
@149062
Schon klar, da muss man dem Proxy schon mehr erzählen was er weiterleiten darf.@149062
reverse proxy davor gesetzt. Das Teil ist halt löchrig wie ein schweizer Käse.
Letzteres stopft die Löcher aber nicht. Denn der Reverse Proxy leitet die Anfragen 1:1 erst einmal weiter.Vor Zero Days kann ein Proxy ja auch niemals schützen denke das sollte dem TO ja klar sein.
