Windows 10: Was erzeugt massenhaft mat-debug*.log-Dateien?

Windows[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.

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.


Anzeige

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


Cookies blockieren entzieht uns die Finanzierung: Cookie-Einstellungen

Dieser Beitrag wurde unter App, Software, Störung, Tipp, Windows abgelegt und mit , , , verschlagwortet. Setze ein Lesezeichen auf den Permalink.

41 Antworten zu Windows 10: Was erzeugt massenhaft mat-debug*.log-Dateien?

  1. Windowsnutzer1969 sagt:

    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 …

  2. Anonym sagt:

    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

  3. Andreas Barchfeld sagt:

    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.

  4. Mira Bellenbaum sagt:

    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!

    • Mira Bellenbaum sagt:

      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.

      • Mira Bellenbaum sagt:

        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.

    • Gigabernie sagt:

      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???

      • Mira Bellenbaum sagt:

        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!

        • Gigabernie sagt:

          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)

        • Anonym sagt:

          > "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

        • Peter Nagel sagt:

          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.

    • Bernd B. sagt:

      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

  5. Jens sagt:

    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.

    • Mira Bellenbaum sagt:

      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.

  6. Mira Bellenbaum sagt:

    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

  7. Anonym sagt:

    > … 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!

    • Mira Bellenbaum sagt:

      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.

    • Günter Born sagt:

      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.

  8. Anonym sagt:

    @ 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)

  9. C.Waldt sagt:

    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—

    • Anonym sagt:

      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

      • Bernd B. sagt:

        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

        • Mira Bellenbaum sagt:

          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.

          • Anonymous sagt:

            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…

            • Mira Bellenbaum sagt:

              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.

              • Bernd B. sagt:

                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/

          • Anonym sagt:

            >>> 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!

            • Mira Bellenbaum sagt:

              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.

              • Anonym sagt:

                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.

      • C.Waldt sagt:

        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—

        • Bernd B. sagt:

          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

          • C.Waldt sagt:

            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—

        • T Sommer sagt:

          Der Fehler ist, das "c:\>"
          das ist die Meldung der Console und gehört nicht zum Befehl.

  10. Thierry sagt:

    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/

  11. Robert sagt:

    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.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Hinweis: Bitte beachtet die Regeln zum Kommentieren im Blog (Erstkommentare und Verlinktes landet in der Moderation, gebe ich alle paar Stunden frei, SEO-Posts/SPAM lösche ich rigoros). Kommentare abseits des Themas bitte unter Diskussion.