[English]Nutzer von Microsoft Outlook Classic werden seit Monaten durch CPU-Lastspitzen beim Tippen von Texten geplagt. Nun hat Microsoft dieses Problem beim Office 365 (ab Version 2406, Build 17726.20126) eingestanden.
Anzeige
Nutzer von Microsofts Outlook Classic sind Kummer durch Bugs gewöhnt. Unter anderem gibt es immer wieder den Effekt, dass das Programm beim Tippen recht langsam wird und zäh reagiert. Blog-Leser Viebrix hat in einem Kommentar im Diskussionsbereich auf den Sachverhalt hingewiesen und schrieb: "Das langsame Verhalten von Outlook [classic]beim Tippen (das ich vor einiger Zeit hier erwähnt habe und im Spaß mit einer mitlesenden/ lernenden KI in Verbindung brachte) ist nun endlich auch Microsoft aufgefallen. Das Problem taucht in der Classic Variante in den neueren Versionen auf."
Microsoft bestätigt CPU-Lastspitzen
Microsoft hat zum 14. April 2025 den Supportbeitrag CPU spikes when typing in classic Outlook for Windows dazu veröffentlicht, in dem ein Problem mit der klassischen Version von Outlook 365 bestätigt wird.
Unter dem Titel "CPU-Spitzen beim Tippen in klassischem Outlook für Windows" beschreibt Microsoft das Problem. Beim Schreiben einer einfachen E-Mail in der klassischem Version von Outlook für Windows kann es vorkommen, dass die CPU-Last zu bestimmten Zeiten um 30 bis 50 % ansteigt und den Stromverbrauch erhöht. Benutzer können diesen Effekt beobachten, indem sie parallel den Task-Manager öffnen und die CPU-Auslastung beim Tippen beobachten.
Laut Microsoft kann dieses Problem nach dem Update auf Version 2406 Build 17726.20126 und höher im Current Channel, Monthly Enterprise Channel oder den Insider Channels auftreten. Das Outlook-Team untersucht derzeit dieses Problem, denn eine Ursache ist wohl noch unbekannt.
Anzeige
Was schafft Abhilfe?
So aus dem hohlen Bauch heraus hätte ich "mit Thunderbird wäre das nicht passiert" gelästert, und auch die in den Office-Paketen mit Perpetual-Lizenz (Office 2019, 2021, 2024) sollte der Effekt nicht auftreten. Nur die kaputt gefrickelten Office 365-Builds im Current oder Monthly-Channel weisen den Fehler auf.
Microsoft empfiehlt offiziell zum halbjährlichen Channel zu wechseln, wo das Problem nicht beobachtet wurde. Ist halt eine beliebte Strategie im Microsoft Universum, auf eine Software-Version zu wechseln, wo ein Bug noch nicht beobachtet wurde.
Fix wie Microsoft nun mal ist, beschreibt man im Support-Beitrag auch folgenden Methoden, um zum halbjährlichen Kanal zu wechseln. Die Alternative, die Viebrix in seinem Kommentar vorschlug, ist ein Downgrade von Office 365 auf einen Build vor Version 2406 Build 17726.20126. Frage: Ist jemand von diesem Problem betroffen?
Nachfolge-Beitrag: Outlook 365: CPU-Lastspitzen werden "demnächst" korrigiert
Anzeige
*******************************
Nutzer von Microsofts Outlook Classic sind Kummer durch Bugs gewöhnt.
*******************************
Also ich hab bisher mit Outlook Classic (die OnPrem Versionen) keine Probleme gehabt!
Liefen bisher einwandfrei und auch aktuell das Outlook aus dem Office Professional 2024 Plus LTSC läuft fehlerfrei.
Sieht mir bei den Ganzen Meldungen doch eher so aus, das da nur die Cloud Office, also 365 Versionen nen Bugfestival sind!
Cloud das allgöttliche Heilmittel… Not! Neverever kommt mir Cloudgedöhns auf mein Rig und damit fahre ich bisher ganz gut! OnPrem 4tw.
Das ist doch der Grund die Cloud Variante zunehmen:
Wenn es nicht funktioniert kann man auf andere zeigen.
Ich habe allerdings gelernt, dass dann drei Finger auf einen selbst bzeigen…
Haben wir schon vor einigen Wochen beobachtet.
Aufgefallen ist das, weil unsere Terminalserver-Umgebung mit O365 eine deutlich höhere durchschnittliche CPU-Auslastung hat als unsere anderen Umgebung (Outlook 2016/2019)
Man muss auch sagen, dass "tippen" in dem Fall schon übertrieben ist. Es reicht die bloße Eingabe eines einzigen Zeichens und die CPU-Last macht einen Sprung nach oben.
Genau das gleiche habe ich mit NewOutlook aber auch.
Version 1.2025.404.500 mit WebViee2 135.0.3179.73
Das neue Mail-Fenster ist offen. Outlook hat irgendwas zwischen 0 und 2% CPU-Last.
Reinklicken in die Mail, CPU steigt auf 10-15%, sinkt dann aber wieder.
Während des Tippens steigt sie und bleibt bis zum Ende des Tippens auf 15%.
Interessanter Artikel, vielen Dank.
ist schon mehr als kurios, das im Zeitalter von Gigahertz-Multicore-CPUs, und GB-RAM und IOPS >100.000 bei NVMe-SSDs es ein etabliertes Unternehmen wie MS es schafft, eine Anwendung (hier Outlook) so kaputt zu patchen, das die CPU-Last so in die Höhe schnellt .. :-( … und dann nicht mal die Ursachen finden (wollen/können?).
Vielleicht mal den CoPilot fragen? Ach nee … der braucht noch mehr CPU-Rechenleistung und diese zieht ja leider Outlook ab und steht dem CoPilot nicht (mehr) zur Verfügung …
(Sarkasm off!)
lol .. you made my day! ^^
Die Frage stelle ich mir auch oft, aber auch bei alten Anwendungen, bzw. Server: Servermanager braucht eine halbe Ewigkeit für den ersten Start, egal ob da eine SingleCore 1Ghz ATOM CPU verbaut wurde oder die aktuellste Premiumhardware.
Aber den Effekt, dass beim Tippen der CPU-Load hochgeht, tritt jetzt nicht zum ersten Mal auf, das hatte ich schon ab und an.
1. Die meisten Komfortfunktionen (Rechtschreibung beim Tippen etc.) werden ja so realisiert, dass ein Keypress oder ein Event des Editor-Controls feuert und dann Code das bisher vorhandene untersucht.
Wenn man's megaclever macht, dann baut man dafür eine Struktur im Speicher auf, in der man instant erkennt, was geändert wurde.
Wenn sich aber Microsoft an seine eigene Dokumentation und Samples hält, machen sie das eher nicht. ;)
Ganz schlimm wird's dann, wenn man damit Kaskaden lostritt – andere Controls, die OnChange ihr Aussehen ändern sollen etwa – an denen ggf. andere Interpretationen von Einstellungen hängen…
Jeder, der mal eine Live-Eingabeprüfung versucht hat, kennt die Pforten zur Hölle….
Es wundert mich nicht, dass es da Lastspitzen gibt – ich bin eher ganz angetan davon, dass es sowenige davon gibt….(obwohl ich Office für eine Seuche halte…) ;)
2. Mein Outlook 2019 macht auch was Spannendes: Seit einigen Wochen beendet es sich während dem editieren von Mails – einfach -Fluff- und weg. Keine Rückfrage, ob ich die Mail speichern will – und die Mail ist dann auch weg. Ist ein bisschen ärgerlich, wenn da schon 1K Text drin ist…
Das scheint vor allem nach dem Löschen von (Text-)Komponenten zu passieren.. und mit einer Häufig von 1:20 vielleicht. Also mit jeder 20en Mail, zwei oder drei Mal am Tag, passiert das.
Ich denke, dass hat was mit MSGraph, also der Anbindung an M365 zu tun – aber das ist ja kaum zu debuggen oder auch nur zu reporten….
Supportverhinderung durch Komplexität…
Die Postbank hat in Zusammenarbeit mit der Deutschen Bank die ultimative Lösung gefunden, um keine Bugreports mehr zu bekommen.
Man hat auf dem Hotline Frontemd einfach das Feld für Beschwerden entfernt. So ein wohl völlig gefrusteter Hotliner(die ja nix für den Mist können, die die und Führung da baut aber den Arger der Kunden abbekommen).
Hintergrund könnte auch sein, das die Fehler alle bekannt sind
Hallo, ich setze bei mir die Version von Outlook classic ein:
"Microsoft 365 MSO (Version 2503 Build 16.0.18623.20178) 64 Bit"
und habe dieses Phänomen auch.
Kaum fängt man an zu schreiben, steigt bei mir die CPU auf ca. 20% an.
Hört man auf, sinkt die CPU wieder nach ein paar Sekunden runter auf < 1%.
Sehr seltsam dass dies scheinbar schon seit Monaten ersichtlich ist, aber dies noch nicht behoben werden konnte!
Es zeigt sich wieder was ich und andere immer Predigen:
Im Unternehmensumfeld sollte man IMHO keine "latest" Channels oder "Preview" Updates nutzen. Im Monthly Enterprise Channel (18526.20264) keine Probleme.
Der Monthly Enterprise Channel war von MS explizit genannt – tritt vermutlich aber nicht bei jedem Client auf.
Was da alles unnötig mitliest, will man vielleicht gar nicht wissen. Vermutlich ein wilder Mix aus Rechtschreibprüfung, Usertracking zur "Verbesserung der Benutzererfahrung", Virenschutz, Shortcut-Key Funktionen, Einfalltore für Backdoors usw. und über all das gestülpte halbgare KI- und sonstige Funktionen, alles zusammen gebaut aus uralter Codebasis mit zig zussammengeklickten Low Code Komponenten verschiedener Bibliotheken, die einzeln irgendwelche eigenen Datenhaltungen und Caches usw. betreiben. Fertig ist das Chaos, noch ganz ohne harten Programmierfehler.
Aber der Co-Auto-Pilot findet im Linux Kernel die Fehler … genial
Jede Eingabe will natürlich erstmal verarbeitet und an die üblichen Verdächtigen (Geheimdienste, KI Trainings, …) gesendet werden, insofern ist das doch gar nicht verwunderlich?!
Wenig zielführend, der Kommentar – eine Ausleitung würde an einer Stelle passieren und sicherlich keine Einzelzeichen umfassen. Die Theorie, dass da eine Menge Controls über Events getriggert werden und da ein Bock schlummert, erscheint mir wahrscheinlicher.
ich beobachte schon länger, das im Abstand von gefühlt 10s Tastatur und Maus einfriert. Abhilfe ist, den originalen Microsoft Treiber und nicht den vom Chip Hersteller AMD zu nehmen.
Das Problem ist bekannt. AMD kümmert es nicht. Nehmen sie die neuesten Treiber. ja. Bwana Hotliner, genau die funktionieren nicht…Danke für die Hilfe.
Wäre interessant zu wissen, welcher AMD Ryzen verbaut ist.
Beim Ryzen 3000 und 5000 wurde stuttering in diversen UEFI Updates behandelt. Offiziell lag es am fTPM. In Einzelfällen auch an defekten CPUs.
Das ist nur ein Notebook von Lenovo.
Auf seiner Schwester ist der Effekt gleich, auch bei W10.
Es ist aber als viel Doppel blind Tipper extrem ätzend wenn alle paar Sekunden die Zeichen nicht mehr oder Intervall auf angezeigt werden.
Ich hatte als Beispiel genannt, dass es nicht nur MS ist. denen denen die Kunden egal sind.
Ich nehme halt den MS Treiber
Ist natürlich bekannt, das Microsoft ein Problem hat(te) die CPU Last sinnvoll zu berechnen.
Es gab mal das Problem, das die knilche von MS die Last mit der Idle Task, dem Leer Lauf "verrechnet" hatte.
Man kann das allerdings abschalten (was erklären könnte, warum diese Last nicht überall angezeigt wird.
Die reale load lässt sich snhand der Stromaufnahme meist besser bestimmen. Intel hatte auch mal ein Low Level Tool, dass recht genau zeigte, wo im Code sich die CPUs gerade beschäftigen.
Wenn man eh nicht weiß was da läuft sehr interessant.
Ob da evtl Event Schleifen ausgelöst werden kann man mit einem Tool von MS Internals sehr hübsch sehen.
Es muss wohl etwas anderes sein. wenn MS das Problem nicht finden und beseitigen kann.
Vielleicht hat der letzte Entwickler bei MS einfach keine Zeit für so ein Pipifax? Wenn die Kunden eh lieber für Features zahlen und völlig absurd davon ausgehen, das MS die Fehler Suche gefälligst selbst zu zahlen hat?
Lastspitzen gab es schon immer. In modernen Systemen kann man die aber besser wahrnehmen. Wenn ein Prozess hängt und einen Kern meines AMD Ryzen 5900X blockiert, höre ich das an der Lüfterdrehzahl. Die Taktfrequenz geht dann dauerhaft auf 4,5 bis 4,8GHz hoch. (XFR funktioniert)
Auf meinem alten PC, mit einem AMD Phenom II X4 965 sehe ich das nur im Taskmanager.
Auslöser ist in meinem Fall, dass Wetterfeld des Explorer Patchers. Der zugrunde liegende WebView2 Prozess hängt sich auf. Weshalb weiß ich nicht. Ausblenden des Wetterfeldes behebt das Problem. Beide PCs haben noch Windows 11 23H2 installiert.
All diese Wetter Apps und Wetter Felder und Wetter Daten überall sind wohl weltweite Trackingsysteme mit ggf. Rückkanal für Backdooraktivierung oder Ausnutzung Lücken über geeigneten gezielten Payload, so kommt mir das mittlerweile vor…
Die Windows Minianwendung Wetter gibt es schon seit Windows Vista. Sie ist also nicht neu. Einzig das die Daten neben dem Infosymbol in der Taskleiste angezeigt werden ist seit Windows 10 neu.
Ha, mit Vista begann das Ausrollen von Tracking und Benutzer Überwachung bzw. Einschränkungen und damit einhergehender Hardwarehunger..
thanks 4 Info.
Wie bist Du drauf gekommen?