Hohe CPU-Last durch TiWorker nach Update KB4480977?

[English]Verursacht das kumulative Update KB4480977 vom 17. Januar 2019 für Windows 10 V1607 und Windows Server 2016 eine hohe CPU-Last durch den Prozess TiWorker?


Anzeige

Update KB4480977 für Windows 10 V1607/Server 2016

Microsoft hat am 17.1.2019 ein kumulatives Update KB4480977 für Windows 10 V1607 sowie Windows Server 2016 freigegeben. Ich hatte im Blog-Beitrag Windows 10 V1607: Update KB4480977 (17.1.2019) darüber berichtet. Das Update soll einige Bugs fixen, verursacht aber eine lange Liste an ‘known issues’ (siehe auch Artikel am Ende dieses Beitrags).

TiWorker, was ist das?

TiWorker ist ein Windows Modules Installer Worker Prozess des Trusted Installer, der durch Windows Update benutzt wird. Dieser Prozess fällt seit Jahren immer wieder auf, dass er nach Updates Amok läuft und plötzlich hohe CPU-Last verursacht. Wer per Suchmaschine nach ‘TiWorker process site:microsoft.com’ suchen lässt, wird zig Treffer finden. Allen Treffern ist gemeinsam: Plötzlich zieht TiWorker alle CPU-Leistung ab und die Maschine ist nicht mehr nutzbar.

Nach KB4480977 verursacht TiWorker hohe CPU-Last

Blog-Leser H. M. hat mich per E-Mail diesbezüglich kontaktiert und auf ein Problem hingewiesen, in welches er gelaufen ist. Er betreibt eine virtualisierte Instanz von Windows Server 2016. Er schrieb mir dazu:

seit ein paar Tagen geht nach Ende 2017 wieder mal das Problem um, das nach einem Windows Update (KB4480977) der Prozess TiWorker sehr hohe CPU Last verursacht.

In meinem Fall habe ich das aktuell bei einem virtuellen Server 2016 der nahezu unbrauchbar dadurch wurde.

Der Blog-Leser hat recherchiert und schreibt: Alle Einträge im Netz sind nur ein paar Tage alt und das Thema schein noch nicht wirklich bekannt. Er hat mir den Link zu diesem MS-Answers-Forenbeitrag vom 19. Januar 2019 gepostet, wo das Problem ebenfalls bestätigt wird.

TiWorker.exe

Hi ! I have a very interesting problem, here it is: when I simply do my work on my computer, this program named TiWorker.exe pops out of nowhere and uses ~50%  of my CPU for absolutely nothing. I heard it’s a part of a windows update installation program, but I really don’t think so. If so, then why it suddenly disappears when I open the task manager? Is my computer playing jokes on me ? Do I really have play this hide-and-seek game with this program? I hope to find some kind of solution to this problem. I’ve tried everything that I could find online: turn off windows update from services.msc and so. Temporarly, it seems that I’ve found some kind of bridge, if I keep the task manager opened, it would literally “scare” TiWorkes.exe and prevent it from happening. Although it may seem funny, trust me, it isn’t ! Thanks for reading this and trying to help, I really appreaciate all of that.

Im MS Answers-Forenthread gibt es dann die üblichen Hinweise, den Trusted Installer mit den Standardmethoden zu bändigen. Dazu gehört Windows auf Beschädigungen zu prüfen und ggf. reparieren zu lassen (siehe Windows 8: Komponentenstore reparieren). Weitere Hinweise gehen in die Richtung, die Download-Datenbank für Updates mit diversen Befehlen aus der Eingabeaufforderung heraus zu leeren (um defekte Dateien als Ursache auszuschließen).

Dieser MS-Answers-Forenthread vom 11. Januar 2018 befasst sich ebenfalls mit hoher CPU-Last durch den TiWorker, kann sich aber nicht auf Update KB4480977 beziehen. Ein weiterer Thread zum Fehlerbild findet sich hier. An dieser Stelle die Frage: Hat noch jemand eine hohe CPU-Last durch den TiWorker-Prozess nach Installation des Update KB4480977 festgestellt?

Ähnliche Artikel:
Windows 10 V1607: Update KB4480977 (17.1.2019)
Windows 10/Server 2016: Hyper-V-Problem durch Update KB4480977 bestätigt
Windows 10: Netzwerkbug, Fix soll später kommen
Windows 10 V1709: Probleme mit Update KB4054517


Anzeige
Dieser Beitrag wurde unter Update, Windows 10, Windows Server abgelegt und mit , , , , verschlagwortet. Setze ein Lesezeichen auf den Permalink.

8 Responses to Hohe CPU-Last durch TiWorker nach Update KB4480977?

  1. Samuel Bunlong sagt:

    Der Prozess “TiWorker.exe” ist ein speziell ungeliebter Kollege von mir.
    Der hat mir bei diversen Office-Installationen (vorwiegend auf Systemen ohne installierte Virensoftware von Drittanbietern) das Leben zur Hölle gemacht.
    Ich habe mehrfach die Erfahrung gemacht, dass der TiWorker Prozess plötzlich auf 99% CPU hochschnellt und dann den PC resp. die Office-Installation bis zu 90 Minuten blockiert.
    Nach langer Recherche konnte ich einen Zusammenhang mit dem Windows Defender herstellen. Der hat IMHO seit Jahren einen Bug, den Microsoft offenbar immer noch nicht wirklich behoben hat. Der Windows Defender kann sich nämlich (aus mit unerklärlichen Gründen) selber in den Schwanz beissen und dreht dann schier endlose Loops und legt damit das System lahm.

    Mein Lösungsansatz:
    Im Windows Defender die Datei “MsMpEng.exe” explizit ausschliessen.
    Danach das System neu starten.
    Danach hat der TiWorker wieder Ruhe gegeben, resp. seinen Dienst normal verrichtet.
    Der Pfad dieser Datei ist übrigens abhängig von der Windows-Version.

    …….
    Das erscheint auf den ersten Blick komisch – ich konnte das jedoch mehrfach reproduzieren.
    Wie gesagt, auf PC’s ohne Virensoftware – resp. nur mit Windows Defender.
    Bei mir jedenfalls hat’s geholfen.
    Ein Versuch auf anderen Systemen (Windows 10 v1607 habe ich grad keine VM auf Lager) könnte sich lohnen.

  2. wufuc_MaD sagt:

    da ich just heute nach einer aktuell total funktionierenden möglichkeit gesucht habe um den offender unschädlich zu machen, viele alte tweaks bringen das nicht mehr, hier das substrakt zum “selber-scripten” :-)
    der defender ist in der tat eine dauerhafte plage die abgetötet gehört! wird eh nur für telemetrie-zwecke missbraucht von microschrott! konnte dank folgenden lösungen mailpassview von nir sofer endlich einsetzen (1809)
    mit trusted installer privilegien ausgeführt und in die registry geäzt, lässt der defender sich wahrscheinlich auch komplett vernichten.

    .cmd:
    reg add “HKLM\System\CurrentControlSet\Services\WdBoot” /v “Start” /t REG_DWORD /d “4” /f
    reg add “HKLM\System\CurrentControlSet\Services\WdFilter” /v “Start” /t REG_DWORD /d “4” /f
    reg add “HKLM\System\CurrentControlSet\Services\WdNisDrv” /v “Start” /t REG_DWORD /d “4” /f
    reg add “HKLM\System\CurrentControlSet\Services\WdNisSvc” /v “Start” /t REG_DWORD /d “4” /f
    reg add “HKLM\System\CurrentControlSet\Services\WinDefend” /v “Start” /t REG_DWORD /d “4” /f
    – – – – – – – – – – – – – – – – – – – – –
    .reg:
    Windows Registry Editor Version 5.00

    [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows Defender]
    “DisableAntiSpyware”=dword:00000001
    “DisableRoutinelyTakingAction”=dword:00000001

    [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows Defender\Real-Time Protection]
    “DisableBehaviorMonitoring”=dword:00000001
    “DisableOnAccessProtection”=dword:00000001
    “DisableScanOnRealtimeEnable”=dword:00000001
    – – – – – – – – – – – – – – – – – – – – –

    grüßle!

  3. Werbung

  4. André sagt:

    der Prozess komprimiert seit Windows 8 den WinSxS Ordner und entfernt alte Update Daten die nach der Installation vom letzten Kumulativen Update nicht mehr benötigt werden.

    • wufuc_MaD sagt:

      das weiß ich. und er tritt bei installation / deinstallation von updates, beim hinzufügen / entfernen von windows features sowie auch bei einer systemdateiprüfung oder allerhand dism aktionen zutage. ich habe zwei skripte in meinem heiligen ordner die nur dazu da sind den windows modules installer service kalt zu machen und zu aktivieren ohne das manuell in den diensten tun zu müssen wie früher ;-)
      die zeilen dort oben wirken! da ich, wie leicht zu erahnen, täglich dabei bin die methoden im heiligen ordner zu verbessern kann ich sagen – ein bereits stark bearbeitetes WaaS-offline startet generell nochmal um 500ms schneller nach einpflegen der zeilen als ohnehin schon. vom piepen bis zum leuchten aller drei screens und fertigem autostart sind das 5 sekunden :-)
      mit der 1607 ist das nicht möglich, einer der wenigen gründe wieso ich die nur noch virtuell nutze. die wirklich entscheidenden dinge lassen sich unter windows meist nur mit maximalen (TI) rechten bewerkstelligen. ich bin das theater, das benutzerkonto unter dem bla… du bleibst vor der tür sitzen – einfach leid. da hilft nur elektronische gegengewalt.

      lg!

  5. Schlammhamster sagt:

    Haben wir auch hier. Dachten schon sonstwas, bis ich jetzt diesen Beitrag hier gleich gefunden habe.
    Defender ist nicht aktiv.
    Beim Update steht “Updates werden heruntergeladen (100%)” und die TiWorker.exe läuft seit Tagen auf 4 CPU Kernen auf 25%. Wechselt sich hin und wieder mit Diensthost: Lokales System = Windows Update ab. (Schleife)

    Keine Ahnung was man machen soll.
    Hab jetzt erst mal den Windows Update Dienst deaktiviert.

    Bin für Hilfen Dankbar.

    Grüße
    Schlammhamster

    • Günter Born sagt:

      Bei WU gibt es noch den Diensteausfall, der auch mit reinspielen könnte.

      • Schlammhamster sagt:

        Ich hab jetzt das Update KB4480977 als msu Datei manuell Installiert.
        Das hat auch geklappt und WU sagt: “Ihr Gerät ist auf dem neuesten Stand.”
        Nach dem Neustart geht die TiWorker.exe aber sofort wieder auf 25% hoch. Kenne ich ja für ein paar Minuten und dann sollte wieder Ruhe sein. Passiert hier aber nicht.
        Windows Update Dienst bleibt jetzt erst mal deaktiviert und dann schauen wir nächsten Dienstag ob was neues kommt.

  6. Eike sagt:

    Ich habe auch diese Last, in einer Azure-VM. Neben anderen wurde KB4480977 frisch aufgespielt. Ich weiß aber nicht, wie die Last vorher war. Ein aktuell anliegendes Update (KB4487026) manuell einspielen hat anscheinend geholfen.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.