Kurznotiz: TiWorker.exe – Hauptspeicherverbrauch eskaliert, Ursächlich KB3025096

Auf unterschiedlichen Servern mit Betriebssystem Server 2025* bekomme ich das Problem, dass der Hauptspeicher volläuft. Ursächlich sehe ich, dass TIWorker.exe über mehrere Gigabyte verbraucht und das Protokoll cbs.log sich aufbläht. ~~Ich habe keine Lösung für das Problem.~~ Ein Workaround für das Problem wurde gefunden.

Update: Auf den Lösungsansatz / den Workaround hat mich ein Kommentar bei Günter Born gebracht: WSUS (Link). Nachfolgend habe ich die „Lösung“ (die mir nicht wirklich gefällt) nochmal aufgeschrieben. Anders komme ich dem aber nicht bei. Ich hatte bei Günter mein Leid geklagt, und das hat geholfen. Danke an die Community.

*Das Problem ist ein alter Bekannter und hat sich früher schon auf andere Betriebssysteme von Microsoft ausgeweitet. Ich finde Meldungen zu allen Betriebssystemversionen im Internet, es reicht eine schlichte Suche nach dem KB-Artikel (Link). Mir selbst fällt dies jedoch erst mit diesem Serverrelease auf.

Ich hatte das Problem mit dem Memoryleak in CheckMK zwar bemerkt, allerdings konnte ich von unterwegs nicht rechtzeitig eingreifen oder das Problem auf TiWorker festnageln.

In diesem Fall hatte es einen DC sprichwörtlich „zerlegt“. DFSR, Kerberos und DNS waren dadurch quasi funktionsunfähig. Ich bin gerade nicht wirklich begeistert. Offensichtlich war CoPilot am Quellcode von Windows Update dran.

Weil das Log im Fehlerfalle absolut riesig – also mehrere Gigabyte und damit selbst für Notepad++ unbrauchbar – ist, hole ich mir mit einem Script die letzten 5000 Zeilen zurück. Die kann ich dann entweder selbst parsen oder in irgendeine KI kippen, um das Problem zu erkennen.

# Definiert die Pfade
$logFile = "C:\Windows\Logs\CBS\CBS.log"
$outputFile = "$env:USERPROFILE\Desktop\CBS_Letzte_Fehler.txt"
$linesToRead = 5000

# Informiert den Benutzer
Write-Host "Lese die letzten $linesToRead Zeilen aus der großen CBS.log-Datei ein. Das kann einen Moment dauern..." -ForegroundColor Yellow

try {
    # Liest nur die letzten Zeilen der Datei, ohne die ganze Datei in den Speicher zu laden
    $lastLines = Get-Content -Path $logFile -Tail $linesToRead

    Write-Host "Durchsuche die eingelesenen Zeilen nach relevanten Fehlern..." -ForegroundColor Yellow

    # Filtert die eingelesenen Zeilen nach den Schlüsselwörtern und speichert das Ergebnis
    $lastLines | Select-String -Pattern "error", "failed", "not applicable", "mismatched" | Out-File -FilePath $outputFile

    Write-Host "FERTIG! Eine kleine Datei namens 'CBS_Letzte_Fehler.txt' wurde auf Ihrem Desktop erstellt." -ForegroundColor Green
    Write-Host "Cbs-Logexport fertig."

} catch {
    Write-Host "Ein Fehler ist aufgetreten: $($_.Exception.Message)" -ForegroundColor Red
}

Hiermit bekomme ich über den Fehlercode

0x800f0805 - CBS_E_INVALID_PACKAGE

heraus, dass Server 2025 immer wieder versucht ein absolut ungeeignetes Paket „KB3025096“ zu installieren, welches nicht für diesen Server geeignet ist.

Wie zuvor erwähnt, finde ich das mehrfach im Netz, u.a. z.B. bei Reddit hier (Link) und hier (Link) u.a. für Windows 11, sowie auch für Server 2022 (Link) oder andere Windows Generationen (Link).

Dieses 11 Jahre alte Update ist dem Vernehmen nach für eine andere Betriebssystemgeneration gedacht, bzw. aus Dezember 2014. Die Installation für dieses technical preview (Link) wäre m.E. absoluter Quatsch.

In der Folge wird in vielen Foren die (mit Verlaub dämliche) Frage gestellt, warum der Anwender denn versuche, dieses Paket zu installieren. Liebe Leute! Nö, versucht der Anwender nicht, macht Windows in diesem Fehlerfalle selbst. Und nein, liebe Leute, der Anwender wird (auch in diesem Fall) kein 3rd Party Tool auf einem DC (ausser einem check_mk Agent) installieren. Und ja, es ist auch möglich, dass ich selbst keinen Einfluss habe auf die Wahl des Betriebssystems. Mir gefällt das so auch nicht.

Bei Microsoft habe die Leidensgeschichte ebenfalls dokumentiert (Link).

„funktionierender“ Workaround:

=> Bereitstellen von WSUS

Ich weiß, es ist ein altes, riesiges, speicherfressendes, wartungsintensives, langsames, schwer zu bedienendes Monster, und Microsoft will das dem Vernehmen nach auch loswerden (Link), aber wenn’s denn hilft… Und wenn wir eines haben, dann ist es Bumms und Platz…

Anmerkung: Intune habe ich bislang nicht versucht.

Tatsächlich hat die (!)passende(!) Gruppenrichtlinie für das ausschließliche Abholen von Updates via WSUS – bislang – geholfen. Seit dieser Konfiguration ist tatsächlich Ruhe.

Ich habe zur Lösung allerdings noch auf den Betroffenen Hütten die Softwaredistribution zurückgesetzt

net stop wuauserv
net stop bits
net stop cryptsvc
net stop trustedinstaller
net stop usosvc
net stop waasmedicsvc

Dann habe ich mit

takeown /f "C:\Windows\SoftwareDistribution" /r /d y
icacls "C:\Windows\SoftwareDistribution" /grant administrators:F /t
ren C:\Windows\SoftwareDistribution SoftwareDistribution.schrott

das alte Verzeichnis erstmal umbenannt und anschließend durchgestartet.

Gruppenrichtlinienkonfiguration:
Ich konfiguriere wie in c), und natürlich die WSUS-Konfiguration.

Update: Jetzt ist auch klar, dass ich diese Konfiguration nicht benötige: „Keine Verbindung mit Windows Update-Internetadressen herstellen“.

Die Funktion ist in sofern problematisch, als dass die im Taskplaner konfigurierten Update-Jobs für Edge, Webview und Virensignaturen dann nicht mehr funktionieren, es sei denn man holt sich das Zeug selbst über CURL bei Microsoft ab oder liefert sie über WSUS. Dies wiederrum kollidiert aber mit der Wunschkonfiguration „2“ oder „3“, sprich vor der Installation benachrichtigen.

Damit ist in den letzten Tagen tatsächlich Ruhe, das Problem tritt nach Zurücksetzen des Softwaredistribution-Folders und dieser Konfiguration bislang zuverlässig nicht mehr auf. Der TiWorker dreht nicht mehr frei und das CBS-Log bläht sich nicht mehr auf.

Nicht funktionierender Workaround B):

In Windows 10/11 und Server 2022/2025 wird immer mehr über den Update Orchestrator laufen. Das Deaktivieren der Dienste

UsoSvc
wuauserv
WaaSMedicSvc
TrustedInstaller
Bits

ist nicht zielführend, hier sorgen unterschiedliche Taskplaner im Bereich Update Orchestrator dafür, dass die wieder in den Originalzustand zurückkonfiguriert werden und wieder starten. Die KI erklärt mir das Vorgehen wie folgt:

Schedule Scan startet UsoSvc
UsoSvc startet wuauserv
wuauserv ruft TrustedInstaller/TiWorker
falls einer fehlt WaaSMedicSvc stellt ihn wieder her

Nicht funktionierender Workaround C):

Diese Gruppenrichtlinie Automatische Updates konfigurieren (ohne WSUS) wird konstant ignoriert, das Problem ist weiterhin evident. Hier: Die Updates kommen bei den neueren Systemen über den „Update Orchestrator“.

Nicht funktionierender Workaround D):

PSWindowsUpdate hatte ich zuerst versucht, dies funktioniert nicht:

Install-Module -Name PSWindowsUpdate -Force
Hide-WindowsUpdate -KBArticleID "KB3025096" -Confirm:$false

Anmerkung zur Systemumgebung, in jener der Fehler auftritt:

OS: S24H2, 26100.6899
ISO 1: Eval ISO, am 14.08.2025 von Microsoft heruntergeladen, 4 Wochen nach Test umgewandelt und aktiviert
ISO 2: HPE ROK, P77100-A21, aktiviert
HyperV VM, nach Empfehlung, Blech ist DL360 Gen10 (i.d.R. 5218×2, 256GB), SPP ist 2025.05