[English]Ich stelle noch ein Thema hier im Blog ein, auf das mich ein Leser Anfang Mai 2024 angesprochen hat. Er stellt fest, dass der Defender Core-Dienst unter Windows 10 Pro vor gut einem Monat unerwartet gestartet wurde. Seit dieser Zeit wird der Temp-Ordner des Lesers von Dateien mit dem Muster mat-debug*.log geflutet. Es scheint keine Konfigurationsmöglichkeit zu geben. Bei einer kurzen Internet-Recherche habe ich aber festgestellt, dass diese log-Dateien seit 2019 in unterschiedlichen Szenarien thematisiert wurde. Mich interessiert die Frage, ob noch jemand diese Beobachtung gemacht hat. Ergänzung: Aus der Leserschaft gab es Hinweise und eine Erklärung.
Anzeige
Der Microsoft Defender Core-Dienst
Eine Übersicht findet sich in diesem Support-Beitrag von Microsoft. Der Microsoft Defender Core-Dienst wurde laut diesem Support-Beitrag veröffentlicht, um die Endpunktsicherheit zu verbessern und die Stabilität sowie die Leistung von Microsoft Defender Antivirus zu unterstützen. Veröffentlicht wird der Microsoft Defender Core-Dienst wird mit der Microsoft Defender Antivirus-Plattformversion 4.18.23110.2009. Microsoft hat folgende Termine für den Rollout veröffentlicht.
- November 2023, um Kunden vorab zu präsentieren (also eine Preview).
- Mitte April 2024 für Unternehmenskunden, die Windows-Clients ausführen.
- Mitte Juni 2024 für US-Behördenkunden, die Windows-Clients ausführen.
Die Timeline ist wichtig zum Verständnis für nachfolgende Leserbeobachtungen. Microsoft gibt an, dass Unternehmenskunden folgende URLs zulassen sollen, da der Defender Core-Dienst mit diesen URLs kommuniziert.
*.endpoint.security.microsoft.com
ecs.office.com/config/v1/MicrosoftWindowsDefenderClient
*.events.data.microsoft.com
Der Supportbeitrag von Microsoft enthält weitere Hinweise zu URLs, mit denen kommuniziert wird, falls man keine Wildcard-URLs zulassen möchte.
Anzeige
Ein Prozess erzeugt .log Files
Der Blog-Leser schrieb mir in einer E-Mail vom 3. Mai 2024, dass "vor etwa einem Monat der Defender Core-Dienst unerwartet auf dem Win10Pro gestartet wurde." Der Leser vermutet, dass dies vom OneSetting-Service erfolgte. Die "vage Angabe" vor etwas einem Monat deckt sich in etwa mit oben Microsoft Rollout-Terminen.
Dem Leser ist das Ganze aufgefallen, weil im Temp-Ordner plötzlich mat-debug****.log-Dateien landen. Laut Blog-Leser ist, außer der Richtlinie für den OneSetting-Service keine Konfiguration im Hinblick auf diese Log-Dateien möglich. Auf einem nicht [mit dem Internet] verbunden Rechner ist der [Dienst] nicht aktiv, schrieb der Leser in seiner Mail. Er vermutet einen "Experimentation Configuration Service", den Microsoft auf die Nutzer los lässt.
Ich habe im Support-Beitrag von Microsoft aber den Abschnitt Use PowerShell to update the policies for Microsoft Defender Core service. gefunden, wo diverse Richtlinien zur Konfigurierung des Core-Diensts zu finden sind. Man kann die Telemetrieb sowie die Core-Service-ESC-Integration abschalten.
Alte Fundstellen im Web
Ich habe mal nach mat-debug Log-Dateien im Internet gesucht. Erste Treffer im Microsoft Answers-Forum finden sich bereits 2019 (siehe mat-debug-xxxx.log files in temp folder), wobei es heißt, dass die Dateien eine Länge 0 haben. Auch aus dem Jahr 2020 gibt es einen Beitrag mat-debug-xxxx.log files im Microsoft Answers-Forum, der sich mit diesen Dateien befasst. Es kann also nicht ausschließlich mit dem Defender Core-Dienst zusammen hängen, dass die log-Dateien plötzlich im Temp-Ordner des Blog-Lesers landen. In beiden oben verlinkten Microsoft Answers-Foren-Threads gibt es den Hinweis (siehe hier), dass der Nutzer den Grafiktreiber erneut installieren solle. Der Effekt werde durch einen unsignierten Treiber hervorgerufen.
Aus dem Dezember 2023 gibt es den Microsoft Answers Forenthread What's the purpose of mat-debug-*.log files created by msteamsupdate.exe, in dem der Update-Prozess von Microsoft Teams als Verursacher genannt wird. Der Thread-Startet gibt an, dass er mittels Process Monitor herausgefunden habe, dass die .log-Dateien von msteamsupdate.exe und ms-teamsupdate.exe geschrieben werden.
Auf askwoody.com gibt es noch diesen Thread, aus dem hervorgeht, dass die log-Dateien geschrieben werden, wenn irgend ein Update schief läuft. Genannt wurden OneDrive und Microsoft Office. Susan Bradley macht den OfficeHub verantwortlich. So richtig befriedigend sind die Funde im Internet aber nicht. Daher die Frage: Hat noch wer diese log-Dateien bei sich im Temp-Ordner von Windows oder des Benutzerprofils gefunden, und kennt jemand die Ursache?
Werden von MS-Tools erzeugt
Ergänzung: Zum englischsprachigen Pendant dieses Blog-Beitrags gab es diesen Kommentar (und weitere). Der Leser hat diverse AI-Bots befragt und Antworten erhalten, die Licht ins Dunkel bringen (wenn ich bing.com mit Copilot befragt, wirft dieser dagegen die Erläuterungen aus obigem Text aus).
Die mat-debug*.log-Dateien in Windows 10 werden vom Microsoft Application Compatibility Toolkit (MAT) erzeugt, wenn es zur Diagnose und Fehlerbehebung von Kompatibilitätsproblemen mit Anwendungen unter dem Windows-Betriebssystem verwendet wird. Allerdings wird das MAT für Windows 10 nicht mehr angeboten. Es scheint aber ein Nachfolgetool für Windows 10 und Windows 11 zu geben, das Entwickler bei Microsoft und anderen Softwareherstellern zur Protokollierung nutzen.
Diese Protokolldateien enthalten Informationen über die von MAT durchgeführten Kompatibilitätstests und alle während des Prozesses aufgetretenen Probleme oder Fehler. Szenarien, bei denen log-Dateien erzeugt werden:
- Durchführung von Kompatibilitätstests für bestimmte Anwendungen, um Kompatibilitätsprobleme mit dem Windows-Betriebssystem zu ermitteln.
- Analyse von Berichten über Anwendungsabstürze und Erstellung detaillierter Protokolle, um die Grundursache des Problems zu ermitteln.
- Sammeln von Informationen über Systemkonfigurationen, Softwareinstallationen und andere Faktoren, die die Anwendungskompatibilität beeinflussen können.
- Fehlerbehebung bei Kompatibilitätsproblemen mit älteren Anwendungen oder Software, die nicht vollständig mit neueren Windows-Versionen kompatibel ist.
Das ist dann auch die Erklärung, warum ich verschiedene Ursachen für die erzeugten log-Dateien gefunden habe. Und es schaut nicht so aus, als ob man da was steuern kann – der Entwickler hat die Hohheit, ob log-Dateien erzeugt werden oder nicht.
Ähnliche Artikel:
Windows-Temp-Ordner werden mit Aria-debug-xxx.log-Files geflutet
Windows 10/11: Edge müllt den Temp-Ordner mit Edge_BITS_xxx-Dateien voll
Windows Temp-Ordner wird mit "Computername-yyyMMdd-hhmm.log" Dateien geflutet
Windows: Login an Client in einer Domain wegen TEMP-Dateien extrem langsam
Anzeige
Diese Dateien "begleiten" mich schon seit sehr langer Zeit (auch schon bei Windows 7) Treten – ohne bestimmten Rhythmus – mal mehr und mal weniger auf. Ursache und Wirkung unbekannt; wie bei so vielen Dateien, die sich in den verschiedenen Temp-Ordnern befinden. Auch im User-Ordner z. B. (AppData > Local > Temp) gibt es bei mir massenhaft wct****.tmp-Dateien, mit denen ich nichts anfangen kann. Lösche den Kram i. d. R. wöchentlich und lasse nur immer die Dateien stehen, die aktuell und ein bis zwei Tage alt sind. Hat sich bisher so bewährt …
In den DACLs all dieser Dateien erscheinen ACEs des Musters S-1-15-2-…
Gem. (1) sind dies App Container SIDs. Das Konzept App Container ist auf (2) dokumentiert.
App Container lassen sich per (3) ermitteln. Hier begegnen einem zahlreich vertraute Namen wie Microsoft.WindowsCalculator, Microsoft.MicrosoftStickyNotes etc.
Unter günstigen Bedingungen lässt sich dem Muster (4) folgend die "PackageSid" eines App Containers ermitteln.
Umwandlung der PackageSID in eine lesbare Form des Musters S-1-… s. (5), C++ Code!
Achtung vor freien SID Konvertern wie bspw. nettools.net/sid-converter/. Mangels (vertrauenswürdigem) Impressum sollte sicherheitshalber von Malware ausgegangen werden.
(1) devblogs.microsoft.com/oldnewthing/20220502-00/?p=106550
(2) learn.microsoft.com/en-us/windows/win32/secauthz/appcontainer-for-legacy-applications-
(3) c:\>reg query "HKEY_CURRENT_USER\Software\Classes\Local Settings\Software\Microsoft\Windows\CurrentVersion\AppModel\Repository\Packages"
(4)
c:\>reg query "HKEY_CURRENT_USER\SOFTWARE\Classes\Local Settings\Software\Microsoft\Windows\CurrentVersion\AppModel\Repository\Packages\Microsoft.LanguageExperiencePackde-DE_19041.46.139.0_neutral__XXXXXXXXXXXXX"
Achtung: Nur Beispiel, XXXXXXXXXXXXX repräsentiert einen anonymisierten Abschnitt!
(5)
learn.microsoft.com/en-us/windows/win32/api/sddl/nf-sddl-convertsidtostringsida
Moin,
über 70 solcher Dateien in 2 Tagen. Alle eine Größe von 0 kB. Recht häufig werden auch *.tmp.ico mit gleichem Zeitstempel angezeigt.
Mit so vielen Log-Dateien geht es mir wirklich auf den Zeiger.
Oft weiß ich gar nicht welches Programm oder welcher Dienst sie erstellt.
Nach Tagen sind die Temp-Ordner geflutet von diversen Log-Dateien.
Seit zwei Tagen kommen nun auch noch diese "mat-debug-XXXX.log" hinzu!
Warum können die entsprechenden Dienste und/oder Programme nicht eigenständig
ihren Datenmüll entsorgen?
Kann jemand eine Anleitung schreiben, wie man gescheit einen neuen Dienst einrichtet, der bei jedem
Systemstart mit "höheren" Rechten startet.
Dieser soll ein Batch oder ein PowerShellScript starten, dass aber unbedingt im Hintergrund abläuft!
Es muss auch nicht unbedingt ein Batch oder ein PS-Script sein, Bedingung ist "Hintergrund"!!
Und wichtig, nur Dateien löschen älter als drei Tage.
Z.Z. lösche ich diese mit einem PS-Script, immer mal so zwischendurch, aber das alles nervt!
Was natürlich viel besser wäre anstatt der Symptome zu bekämpfen, wäre es,
wenn es eine Möglichkeit gäbe die Verursacher dieser Log-Dateien zu identifizieren
und diesen Mist dann abstellen zu können.
Aber auch da bin ich überfordert.
Nachtrag!
Besagte "mat-debug-XXXX.log" ist in "C:\Windows\Temp".
Und der Ordner "C:\Users\Mira\AppData\Local\Temp"
wird von "amcXXXX.tmp"-Dateien geflutet.
Schreibe folgendes mit deinen angepassten Pfade(n) in eine .cmd:
==========================================
C:
cd C:\temp\
REM obiger Befehl greift auf das ParentVerzeichnis zu und sperrt es, wodurch der folgende/untere Befehl das Verzeichnis nicht löschen kann.
REM Enthaltene Dateien und Ordner im ParentVerzeichnis werden aber gelöscht.
rmdir /s/q c:\temp\ > nul
exit
===================================================
ohne Kommentar sind das dann nur 4 Zeilen…
Dann legst du in der Aufgabenplanung eine Task an, die das Script regelmäßig gemäß deinem Trigger ausführt.
Ergänzung: vor und hinter "temp" sollten jeweils ein Backslash sein, welcher bei mir komischerweise nicht angezeigt wird???
Das mit der Aufgabenplanung ist ja kein Problem,
aber die "Prüfung", ob die zu löschenden Dateien älter als drei Tage sind,
schon.
Das bekomme ich einfach nicht hin!
Das obere Script löscht wahllos.
Falls dein PS unten Probleme macht, kannst du nach Alter löschen mit einer .vbs mit folgendem Inhalt:
==============================
sLogFolder = "c:\temp\"
iMaxAge = 3 'in days
Set objFSO = CreateObject("Scripting.FileSystemObject")
set colFolder = objFSO.GetFolder(sLogFolder)
For Each colSubfolder in colFolder.SubFolders
Set objFolder = objFSO.GetFolder(colSubfolder.Path)
Set colFiles = objFolder.Files
For Each objFile in colFiles
iFileAge = now-objFile.DateCreated
if iFileAge > (iMaxAge+1) then
objFSO.deletefile objFile, True
end if
Next
Next
========================
Du musst halt die Pfade\Tage anpassen. Unterordner werden auch durchsucht und behandelt.
Das Script rufst du so in der Aufgabenplanung auf:
Programm starten: cscript.exe
Argumente: Pfad zum Script (z.B C:\scripts\deine VBS)
> "Prüfung", ob die zu löschenden Dateien älter als drei Tage sind, … sfk list -before 3d C:\Users\user\AppData\Local\Temp +delete
Erläuterung: Sucht alle Dateien im Verzeichnis (inkl. Unterverzeichnissen; diese können aber bei Bedarf ausgeschlossen werden), die seit mindestens 3 Tagen (3d) nicht mehr geändert wurden und löscht diese dann. Die Auswahl der Dateien kann quasi beliebig gesteuert werden, indem man noch selektiert 'nur .tmp und .temp', 'auch in allen Unterverzeichnissen ausser x, y, z' etc. pp.
Kommandoübersicht unter (2).
(1) stahlworks.com/blog/sfk-highlights.html
http://stahlworks.com/downloads.html
(2) stahlworks.com/dev/swiss-file-knife.html
In Powershell:
$Age = 3 # Mindestalter in Tagen
Get-ChildItem $Path -File | Where-Object { $_.LastWriteTime -lt (Get-Date).AddDays(-$Age) } | Foreach-Object {
Remove-Item $_
}
Ich hab mir daraus mal eine function gemacht, die (unter anderem)
beim Start einer PS automatisch eingebunden wird.
Procmon* ist das perfekte Tool dafür.
Filter auf entsprechenden Dateinamen/Typ (auch Fragmente davon) setzen und warten. Et voila!
* live. sysinternals. com/Procmon64. exe
Ich habe schon seit gefühlt Jahrzehnten folgende Batchdatei im Autostart (Win+R "shell:startup"):
@echo off
pushd "%Temp%"
RD /S /Q "%Temp%"
if not exist "%Temp%" md "%Temp%"
popd
pushd "%windir%\Temp"
RD /S /Q "%windir%\Temp"
if not exist "%windir%\Temp" md "%windir%\Temp"
popd
Damit wird beim Start von Windows (bzw. beim Anmelden) mein persönlicher Temp-Ordner geleert – und falls ich mich mit einem Benutzer mit Admin-Rechten anmelde auch der Windows-Temp-Ordner.
Dateien, die aktiv in Verwendung sind, werden dabei nicht gelöscht, da sie gesperrt sind.
Durch das Wechseln in den zu löschenden Ordner spart man sich die Angabe irgendwelcher *, *.* etc., die ja gerne mal unterschiedlich interpretiert werden, außerdem kann der aktuell aktive Ordner nicht wirklich gelöscht sondern nur geleert werden.
Das ist ja schön, dennoch ist es eventuell nicht so gut auch Temponäre Dateien zu löschen,
die bei einer Installationsroutine erst nach einem Neustart gebraucht werden.
Ach, ich nutze zu löschen ein PS-Script.
Ach hier werden Dateien, die im Gebrauch sind, nicht gelöscht.
Remove-Item $env:temp\* -recurse -force
Remove-Item $env:Windir\Temp\* -recurse -force
Jedoch fehlt hier, wie auch bei Dir die "Prüfung" der zu löschenden Dateien, ob älter als drei Tage.
Und auch wenn ich es mit der Aufgabenplanung starte,
es läuft nie nur im Hintergrund!
Es blitzt immer kurz auf.
Hilfe zu finden hier – beides sollte gut funktionieren
https://stackoverflow.com/questions/46086358/batch-or-powershell-script-to-clean-up-the-files-older-than-6-hours
https://stackoverflow.com/questions/40620331/powershell-remove-files-older-than-x-days
Ich bin ja wirklich ein Freund von Workarounds (ehe ich mich kange mit einem Anbieter herumärgere…), wenn aber die Ursache so schnell zu finden ist wie hier* würde ich dann schon zuerst da ansetzen, denn Workarounds bringen oft zusätzliche Komplexität ins System.
* www. borncity. com/blog/2024/05/18/windows-10-was-erzeugt-massenhaft-mat-debug-log-dateien/#comment-181977
Danke auch Dir.
Ich habe schon des Öfteren versucht, mit genau diesem Programm
den Übeltätern auf die Schliche zu kommen.
Doch leider bin ich wohl zu blöd, Procmon zu bedienen.
Natürlich, und das habe ich ja auch schon geschrieben, wäre es viel
schöner, im Sinne von besser, man könnte das entsprechende Programm bzw. den entsprechenden Dienst ausfindig machen und könnte dann diese protokolliererei einfach abstellen.
Jedoch ist auch dies nicht immer Möglich.
Damit hatte ich tatsächlich noch nie Probleme:
Installationsroutinen hängen sich in den Run-Zweig der Registry ein, und dessen Inhalt wird vor der Batchdatei ausgeführt und kann somit seine benötigten Dateien wieder sperren, bevor das Skript sie löschen kann.
Die Prüfung auf das Alter habe ich daher bisher nicht benötigt.
Habe nun eine Lösung dank der Hilfe hier.
Also, ein PowerShellSkript erstellen, dies in den Autostart packen, fertig.
Hier das Skript:
get-childitem -path $env:temp -recurse |
where-object { -not $_.PSIsContainer -and ( $_.LastWriteTime -lt (Get-Date).AddDays(-3) ) } |
remove-item -recurse -force
get-childitem -path $env:windir\temp -recurse |
where-object { -not $_.PSIsContainer -and ( $_.LastWriteTime -lt (Get-Date).AddDays(-3) ) } |
remove-item -recurse -force
> … Verbissenheit … Irgendwann muß man auch mal nein sagen. <
Sehe ich genau so. Man könnte ja meinen, diese bösen temporären Dateien verursachten existentiell bedrohliche Unterhaltskosten, müssen raus weil sie keine Miete zahlen etc. pp. Es sind halt Dateien, die herumliegen, aber wer nicht krampfhaft danach sucht, sieht sie eigentlich auch nicht.
Wir haben doch weiss Gott andere Sorgen in der IT: Informationssicherheit!
Stimmt, wenn SSD voll, kauft man sich halt 'ne neue.
Was waren die Zeiten, als Entwickler noch Ressourcenschonend programmieren mussten, so schön.
Heute gilt ja nur noch, nach mir die Sintflut. Alles egal, Hauptsache funktioniert irgendwie und bringt Geld.
Ordnung, Nachhaltigkeit und vieles mehr, Scheißegal.
Leider ist mir eine Revision des Ursprungsartikels überschrieben worden, hab es erst durch die Kommentare hier gemerkt. Habe den Teil mit den Links am Artikelende wieder restauriert. Dort steckt der Hinweis drin, warum das mit der "Verbissenheit" Unsinn ist. Ich habe den betreffenden Ausgangskommentar übrigens gelöscht, weil er am Thema arg vorbei ging.
@ Günter Born:
> Die mat-debug*.log-Dateien in Windows 10 werden vom Microsoft Application Compatibility Toolkit (MAT) erzeugt, … <
Kann ich so aus dem von Ihnen herangezogenen Kommentar (1) nicht herauslesen. Der Kommentar spricht von "Microsoft Application Management (MAM) service". Das von Ihnen genannte Microsoft Application Compatibility Toolkit (MAT) ist alt und wohl eher abgekündigt (2). Aus (2): "We're no longer updating this content regularly …".
(1) borncity.com/win/2024/05/18/windows-10-what-generates-masses-of-mat-debug-log-files/#comment-16955
(2) learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-7/cc749328(v=ws.10)
Es gab ja mehrere Kommentare mit Zitaten diverser AI-Bots, die beides an Informationen enthielten. Hatte das auch mal in einer Textfassung so geschrieben, diese wurde wohl von mir irrtümlich überschrieben.
Wer AI Bots als Quelle vertraut, nun denn…
Also wenn ich das so lese, ist es für mich ein weiterer Punkt, warum ich bei Windows 10 auf eine Drittanbieter-Lösung (in meinen Fall Bitdefender) setze.
Total Security legt im Temp Ordner in der Regel max. ein bis zwei etilqs_ Dateien an und das war es dann auch.
Da ich mir auch schon seit mehreren Jahren eine Verknüpfung zu beiden Temp Ordnern auf den Desktop gelegt habe behalte ich die Temp Daten recht gut im Blick.
Der Zeit beim Surfen im Windows/Temp Ordner zwei Dateien. Eine von PDF24, eine von Bitdefender.
Im Local/Temp Ordner 8 Dateien vom Brave-Browser, mit VPN und LibreWolf sind es nochmal weniger.
Der ganze Kram aus dem Local/Temp Ordner wird nach jeder Internet Sitzung einmal bereinigt und gut ist.
Klar "fressen" Dateien im Temp Ordnern kein Brot und nicht sooo viel Platz weg, aber ich finde es gut da nicht so viel Ballast mit sich rum zu schleppen.
Einen weiteren kleinen Vorteil hat dieses Vorgehen ebenfalls. Falls man mal so dumm ist und wie ich vor kurzem ein portables Programm von einer unbekannten Seite geladen hat und der Virenscanner vor anklicken der Exe Datei beispielsweise die DLL Datei sperrt, kann ja der "Klassiker" eintreten.
Man sieht plötzlich keine geschützten oder ausgeblendeten Dateien mehr auf dem Rechner. Der Vorteil der beiden Temp Ordner Verknüpfungen auf dem Desktop ist aber der, das man so Zugriff behält. Klickt man auf die angelegten Verknüpfungen sieht man selbst die versteckten Dateien in den Temp Ordnern und kann sie vorm großen Virenscan einfach löschen, obwohl man eigentlich keinen Zugriff auf sie bekommt.
Nach dem Virenscan kann man dann mit dem sicheren Gefühl die Kiste neu starten, dass sich kein Müll mehr im Temp Ordner mehr befindet, kann seine uneingeschränkte Dateiansicht wieder herstellen und kann nach einem weiteren Systemscan in Ruhe wieder zur Tagesordnung übergehen. Auch deshalb halte ich gerne meine Temp Ordner sauber. Denn ich rechne lieber vorher meine eigene menschliche Fehlerquote (also Dummsdödeligkeit) als möglichen Faktor mit ein.
—Grüße—
Ich verstehe Ihre Botschaft nicht ganz. Wollen Sie sagen, dass Sie nur wenige temporäre Verzeichnisse auf ihrem System haben? Wenn Sie sich da mal nicht irren.
Setzen Sie einmal als Adminstrator in einer erhöhten Eingabeaufforderung (1) folgendes Kommando ab: c:\>dir c:\tmp c:\temp /s /b
Das sind typischerweise mehrere hundert Verzeichnisse! Und jene, auf die Sie auch als Administrator keinen Zugriff haben sind noch gar nicht dabei.
(1) de.minitool.com/nachrichten/erhoehte-eingabeaufforderung.html
Hach, die gute alte Zeit mit Win 3.x, als das Leben noch einfach war…
In Win95/98 lagen Tempdateien standardmässig bereits in %Windir%//Temp, in/seit Win2K in %LOCALAPPDATA%//Temp, die findet man (inkl. individueller/nonstandard Configs wie bei Ihnen) alle zuverlässiger mit %TEMP% oder/und %TMP%. In %WINDIR%//Temp ist auch noch ein Tempdir (wird z.B. von "WindowsUpdate" zugemüllt*).
P.S. "//" bitte durch Backlash ersetzen, wird zumindest bei mir von Browser oder WordPress verschluckt
* beschrieben, aber nicht aufgeräumt
Danke!
"%systemroot%\Temp\"
oder
"%windir%\Temp" => "C:\Windows\Temp"
"%userprofile%\AppData\Local\Temp"
oder
%LOCALAPPDATA%\Temp
=> "C:\Users\"Benutzer"\AppData\Local\Temp"
Mehr Temp-Ordner gibt es in Windows nicht,
wenn man nicht selber andere definiert hat.
Hier zeigen die Temp Variablen auf eine 1GB RAMDisk von Dataram, so erledigt sich das täglich alles von alleine, da der PC nachts nicht durchläuft…
Und Updates funktionieren?
Gerade die, die einen Neustart erfordern?
Oder legen diese ihre temporären Dateien woanders ab?
Wenn ja, würde ich das mit der RAMDisk eventuell ins Auge fassen.
Das konterkariert zwar Anonymous' Idee des selbstreinigenden TempDirs, aber IMDisk* kann das RAM-Drive vor dem Reboot in den konfigurierten Ordner zurückschreiben (man kann ausschliessen, was man möchte) und lädt es danach erneut.
Ob das für Updates genügt weiss ich aber nicht (ich mache ja Keine).
Auf der anderen Seite ist "Reset bei Reboot" heute oft eh nicht mehr ausreichend, denn man bootet doch kaum noch (stattdessen Standby oder Hibernation).
ibb. co/ySGVTwJ
* sourceforge. net/projects/imdisk-toolkit/
>>> Mehr Temp-Ordner gibt es in Windows nicht, wenn man nicht selber andere definiert hat.
Jetzt bin ich aber sauer. Ich schreibe extra noch
c:\>dir c:\tmp c:\temp /s /b
und dann kommen Sie mit einer sofort als grundfalsch erkennbaren Aussage daher. Etwas mehr Respekt bitte.
Führen Sie das angegebene Kommando einfach einmal aus!
Sorry für meine ungenaue Aussage.
Es müsste heißen: "Mehr Temp-Ordner sind es in Windows nicht, die wirklich relevant sind, wenn man nicht selber andere definiert hat.
Da ist beim Kopieren einfach etwas untergegangen, oder so.
Entschuldigung.
Angenommen.
Vorsorglich noch folgenden Output:
sfk stat -sum c:\Windows\WinSxS\temp
400 mb, 3718 files, 40742 dirs, 400290010 bytes.
der Ihre Aussage "die wirklich relevant sind, " dann doch etwas relativiert. Im Klartext: Das ist ein 400 MB umfassendes temporäres Verzeichnis mit über 3000 Dateien und über 40000 (sic!) Unterverzeichnissen!
sfk ist sfk.exe welches Sie unter stahlworks.com/swiss-file-knife.html (genauer: stahlworks.com/dev/sfk/sfk.exe) kostenlos herunterladen können und mit seinen Unterkommandos ein wahrer Tausendsassa ist. Es besteht aus nur einer .exe mit ca. 2,5 MB Grösse und bedarf keiner Installation. S. a. Anwendungsbeispiele unter stahlworks.com/blog/sfk-highlights.html.
sfk list -before 3d -hidden -size -time c:\users
listet alle Dateien in c:\users und darunter, die älter als 3 Tage sind – weil sie oben so etwas suchten.
Okay! Als Laie lerne ich immer gerne etwas dazu!!!
Adminkonto…klar
CMD als Admin ausführen… klar
c:\>dir c:\tmp c:\temp /s /b… einfügen klar
CMD Antwort: Der Befehl "c:\" ist entweder falsch geschrieben oder konnte nicht gefunden werden. …???
Ich habe dann mal alternativ mit dem Programm Delete.On.Reboot_x64 als Admin unter Extras und Admin-Explorer mit Systemrechten geschaut und konnte auch dort nicht mehr Dateien in beiden Temp Ordnern finden.
Wirklich ganz ohne Ironie oder sonst etwas… wo liegt gerade mein Denkfehler?
—Grüße—
Alle Kommentare zu lesen hilft oft (er stand schon 6h da, als Sie fragten)…
www. borncity. com/blog/2024/05/18/windows-10-was-erzeugt-massenhaft-mat-debug-log-dateien/#comment-182019
Danke @Bernd B. für die Antwort!
Der Fehler lag bei mir da ich nach öffnen der CMD einfach einen cd \ Befehl vergessen hatte.
Danach klappte das mit dem CMD Befehl von @Anonym ganz wunderbar!
Er hatte auch keinen Formatierungsfehler und listet sämtliche Temp Ordner unter C auf.
Ich bin dann mal Seiner Vermutung nachgegangen wie viel Krams man in diesen Temp Ordnern mit sich rumschleppt und war durchaus bei mir zufrieden.
Klar in c:\Windows\WinSxS\Temp ist schon einiges durch die Updates, aber bereits unter c:\Windows\System32\DriverStore\Temp war alles lehr. Auch waren sämtliche Temp Ordner unter c:\Users\Blabla\AppData\Local\Packages\ waren ohne Befund.
Habe mir dann auch die Mühe gemacht in die Temp Ordner unter c:\Users\All Users\Microsoft\Windows Defender Advanced Threat Protection\Temp und c:\ProgramData\Microsoft\Windows Defender Advanced Threat Protection\Temp zu schauen.
Bekommt man ja nicht unbedingt Zugriff, aber auch die waren bereinigt.
Also bis auf ein paar Profil Dateien, etc, war das echt lehrreich sich durch den ganzen Kram durch zu wühlen 😋.
Auch scheint hier Bitdefender (von den Temp Dateien her betrachtet) die Privatsphäre seiner Nutzer zu akzeptieren.
Letzten Endes hat sich dann mein Gefühl bestätigt, dass was ich monatlich, wöchentlich und täglich zum Bereinigen des allgemeinen Temp Wahnsinns verwende definitiv Wirkung gezeigt hat und seinen Aufwand wert ist!
Danke nochmal für die Geduld von @ Bernd B. und Anonym! Habe mir den Kram in einer Textdatei gesichert, damit ich mal alle paar Monate oder bei gegebenen Anlass die kompletten Temp Dateien durchforsten kann.
—Grüße—
Der Fehler ist, das "c:\>"
das ist die Meldung der Console und gehört nicht zum Befehl.
Liebe Blogliebhaber und -liebhaberinnen, einmal pro Woche starte ich die Anwendung Bleach Bit und trenne mich richtig vom ganzen Müll. Beachte bitte, dass diese Anwendung teilweise mit Vorsicht zu genießen ist, denn diese geht ziemlich tief in die Ordner und Dateien ein. Mehr? https://www.bleachbit.org/
Auch ich habe seit dem letzten Mai update "2024-05 Kumulatives Update für .NET Framework 3.5 und 4.8.1 für Windows 11, version 23H2 für x64 (KB5037591)" auf meinem Lenovo "IdeaPad 5 15ITL05" dieses Problem, den es ist scheinbar eins. 1. wie beschrieben füllt es den Temp-Ordner ungewöhnlich stark. 2. Habe ich bemerkt, das der Speicher meiner Einheit seit dem immer kleiner zu werden scheint. Normal immer um die 330GB, jetzt runter gegangen auf 325GB.
An der Arbeit bemerkt man nichts. Es behindert nicht.
Trotzdem ist es lästig und die Frage lautet – wie wird man es wieder los
Sorry, muss gerade feststellen das Word deutlich langsamer arbeitet.