[English]Brauchen die Anmeldevorgänge für ein Benutzerkonto unter Windows extrem lange, ist oft guter Rat teuer. Die Tage hat sich ein Administrator im Blog gemeldet, der dieses Problem bei der Anmeldung an Windows-Clients, die Mitglieder einer Domain waren, hatte. Nach diversen Tests stellte sich heraus, dass sehr viele Dateien im TEMP-Ordner des Benutzerprofils die Ursache für dieses Verhalten darstellen.
Anzeige
Langsamer Start- und Anmeldung analysieren
Wenn Windows sehr lange zum Starten, Herunterfahren oder bei einer Benutzeranmeldung benötigt, kann dies sehr unterschiedliche Gründe habe. Manchmal recht dann eine Suche im Internet, um mögliche Ursachen herauszufinden. Tritt das Problem nach einem Update auf, kann durch Deinstallation dieses Updates sehr schnell getestet werden, ob es daran liegt.
In allen Fällen, in denen die Ursache aber nicht sofort klar ist, bleibt nur eine Analyse des betreffenden Vorgangs übrig. Ich hatte hier im Blog in diversen Artikeln verschiedene Ansätze vorgestellt. So lassen sich beispielsweise der Windows Performance Recorder und der Windows Performance Analyzer des Windows Assessment and Deployment Kit (Windows ADK) für die Analyse der Start, Anmelde- und Herunterfahren-Vorgänge verwenden. Ich hatte die Vorgehensweise vor einigen Jahren im Blog-Beitrag Windows: Start, Herunterfahren, Ruhezustand analysieren skizziert (siehe auch die Artikellinks am Beitragsende). Persönlich habe ich die Tools lange nicht mehr verwendet, die Techniken sollten sich auch noch unter Windows 10 und Windows 11 einsetzen lassen.
Eine weitere Möglichkeit besteht darin, den Start von Windows mit dem Windows Process Monitor aus den Sysinternals-Tools zu verfolgen und zu analysieren. Das kostenlose Tool ermöglicht eine Protokollierung der Boot-Vorgänge. Ich hatte den prinzipiellen Ansatz im Blog-Beitrag Windows-Start per Process Monitor analysieren beschrieben. Allerdings ist die Auswertung dieser Protokollierung, wegen der vielen Einträge, nicht immer ganz einfach.
TEMP-Dateien bremsen Anmeldung
Blog-Leser Peter ist über meinen Blog-Beitrag Windows-Start per Process Monitor analysieren gestolpert, weil er in seiner Umgebung das Problem hatte, dass die Windows-Clients sehr lange zur Anmeldung am Domain Controller benötigten. In diesem Kommentar schrieb er dazu:
Anzeige
Ich bin nach Problemen bei der Anmeldung eines Rechners in der Domain über den Artikel gestolpert. Leider ist die Ausgabe des Process Monitors extrem unübersichtlich, da es gefühlt eine Million Einträge waren.
Unser Problem hatte letztlich eine ganz profane Ursache: das Temp-Verzeichnis des Users (C:\User\Name\AppData\local\Temp) hatte über 300.000 Dateien und zig Unterverzeichnisse. Nach dem Leeren des Verzeichnisses war die Anmeldung deutlich schneller.
Von gefühlt 60 Sekunden ging es auf unter 5 Sekunden für die Zeit von der Anmeldung in der Domain bis zum Start des Desktops zurück.
Das in dem Fall vollständige Leeren des Verzeichnisses erfolgte über ein anderes Profil. Ansonsten geht es auch über das eigene Profil, aber es wird halt Dateien geben, die man nicht löschen kann, weil sie gerade offen sind.
Mein Dank an Peter, der schrieb: Dem Einen oder Anderen mag das helfen, zumal es ja doch recht leicht umsetzbar ist. Aus diesem Grund habe ich diese Erkenntnis mal herausgezogen. Denn leider gibt es unter Windows einige Anwendungen, die die temporären Benutzerordner und Verzeichnisse voll müllen (siehe Links am Artikelende).
Ähnliche Artikel:
Windows: Start, Herunterfahren, Ruhezustand analysieren
Windows Performance Toolkit – Installation – Teil 1
Windows Performance Toolkit – Performancetest – Teil 2
Windows Performance Toolkit – Starten/Herunterfahren analysieren – Teil 3
Nachträge zum Windows Performance Toolkit
Windows-Start per Process Monitor analysieren
Windows 10/11: AppReadiness und die sehr langsame Anmeldung
Windows 10 flutet Ordner mit leerem TMP-Verzeichnismüll
Auch Windows 11 flutet Ordner mit leerem TMP-Verzeichnismüll
Windows 10: Edge müllt Festplatte zu …
Windows 10: Müllen IE und Edge wieder die Festplatte zu? (Jan. 2022)
Anzeige
Waren es servergespeicherte oder rein lokale Profile?
Steht doch im Artikel: C:\User\Name\AppData\local\Temp
Nein, das ist kein Hinweis darauf. Bei Roaming Profiles gibt es die gleiche Ordnerstruktur wie bei lokalen Profilen.
Nein %localappdata% wird in einem Roaming Profile nicht gesynct, nur %appdata%
Gut das kann man ändern aber das macht man nicht, es gibt einen grund für die splittung und die temp dateien sind einer davon
meine 2 ct und Vermutung: Die Antiviren-Lösung spielt Ping-Pong mit dem Windows-Indexdienst. Letzterer will indexieren, ersterer schaut sich alle Zugriffe an. Zack – Gesäß langsam.
Bei 300 K Dateien sind das 600 K Zugriffe.
AppData ist doch standardmäßig von der Indizierung ausgeschlossen…
'Programme, die das Tempverzeichnis zumüllen' – welches wird das sein, dass hier etwas ablegt?
%LocalAppData%\Temp\Outlook Logging
oder hier?
%LocalAppData%\Temp\Diagnostics\OUTLOOK
bei mir hier scheint ein guter Geist aufzuräumen, weil die Dateien da drin max eine Woche alt sind…
der gute Geist versteckt sich hier:
Windows Einstellungen > System > Speicher >
Speicheroptimierung (aktiv) + Häckchen Temp Dateien löschen + Ausführen z.B 1x Woche
die Speicheroptimierung gibt es in älteren Versionen so noch nicht. und weil viele hier ihre Lösungen präsentieren, von mir ein Powershell-Skript. bitte die Zeitangaben beachten und ggf anpassen, denn aus dem %temp% werden nur Dateien älter als 1 Tag entfernt und beim Papierkorb 90 Tage. wirkt nur richtig, wenn mit erhöhten Rechten als Administrator ausgeführt. ich habe das z.B. am WTS als geplante Aufgabe bei Anmeldung eingebaut.
#$env:TEMP | Set-Content -Path e:\log\$env:username.log
$Shell = New-Object -ComObject Shell.Application
$Recycler = $Shell.NameSpace(0xa)
foreach($item in $Recycler.Items())
{
$DeletedDate = $Recycler.GetDetailsOf($item,2) -replace "\u200f|\u200e",""
$dtDeletedDate = get-date $DeletedDate
If($dtDeletedDate -lt (Get-Date).AddDays(-90))
{
Remove-Item -Path $item.Path -Confirm:$false -Force -Recurse
# $item.Path, $dtDeletedDate
}#EndIF
}#EndForeach item
#erstmal alle Dateien weg aus %temp%, die älter sind
get-childitem $env:TEMP -recurse -file -force | Where-Object CreationTime -lt (Get-Date).AddDays(-1) | Remove-Item -force -Verbose
#Get-ChildItem $env:TEMP -file -recurse | Select-Object directory,Name,CreationTime,length,@{n='AgeInDays';e={(New-TimeSpan -Start $PSItem.CreationTime).Days}} | fl
# A script block (anonymous function) that will remove empty folders
# under a root folder, using tail-recursion to ensure that it only
# walks the folder tree once. -Force is used to be able to process
# hidden files/folders as well.
$tailRecursion = {
param(
$Path
)
foreach ($childDirectory in Get-ChildItem -Force -LiteralPath $Path -Directory) {
& $tailRecursion -Path $childDirectory.FullName
}
$currentChildren = Get-ChildItem -Force -LiteralPath $Path
$isEmpty = $currentChildren -eq $null
if ($isEmpty) {
# Write-Verbose "Removing empty folder at path '${Path}'." -Verbose
Remove-Item -Force -LiteralPath $Path
}
}
& $tailRecursion -path $env:TEMP
#wieder anlegen, falls es weg war
New-Item -Force -Path $env:TEMP -ItemType Directory
#Start-Sleep -Seconds 30
Ich verwende für solche Zwecke das Tool "DelAge32/64" von Horst Schaeffer (https://www.horstmuc.de/wbat32d.htm), zusammen mit der Aufgabenplanung von Windows.
Danke! :)
Vielleicht hat das irgendwie damit zu tun? (Erinnert mich jedenfalls daran.)
Es gab mal eine Windows10-Zwischenversion, die einen Bug in den lokalen Default-Profilen hatte.
Wer damals servergespeicherten Profile anbot und in der Zeit eine Profil-Ersterstellung eines Benutzers hatte, der konnte unter Umständen zugucken, wie dieser Benutzer ALLES aus seinem lokalen Profil zum Server synchronisierte.
Es fehlte diesem Benutzer in dem Fall die mitgebrachte Standard-Direktive hier:
[HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon]
ExcludeProfileDirs=AppData\Local;AppData\LocalLow;usw…
"%TEMP%" liegt standardmäßig in "%LOCALAPPDATA%\TEMP", also innerhalb dieses relativen Pfades "AppData\Local" und wird standardmäßig von der Synchronisation ausgeklammert.
Sollte also dieser private Key fehlen, kann man ihn entweder dort nachbessern.
Besser und ordentlicher und eigentlich täglich Brot eines Sreverprofiladmins sollte das Absichern via GPO sein, mit der steinalten Direktive namens "Verzeichnisse aus servergespeichertem Profil ausschließen".
(Mein Neid an die Citrix-Admins mit ihrem tollen User-Profile-Manager, der viel mehr kann.)
…aber vielleicht isses ja was ganz anderes. Aufräumen schadet sicherlich sowieso nicht…
Daher habe ich seit Jahrzehnten folgende Batch-Datei "DelTemp.cmd" im Autostart. Die paar Dateien, die da bereits in Verwendung sind und daher nicht gelöscht werden können stören nicht weiter:
@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
cls
oh. du wechselst also in einen ordner, damit er bei der löschung verschont bleibt und prüfst hinterher er ob aus versehen doch gelöscht wurde?
gut dass du im windows temp keine berechtigungen hast, denn sonst wäre diese methode da meiner meinung nach bei gemanagten rechnern fahrlässig, weil du nicht wüsstest ob und wann systemprozesse da gerade was machen.
ich empfehle das hier mit erhöhten privilegien, da gibts keine längenbeschränkungen, man hat das serestoreprivilege und man kann zeitfilter einsetzen:
md tempdel 1>NUL 2>NUL
if not exist tempdel exit /b 1
robocopy tempdel "%TEMP:"=%" /e /purge /maxage:7 /b /r:0 /w:0 /xj
robocopy tempdel "%SystemRoot:"=%\TEMP" /e /purge /maxage:30 /b /r:0 /w:0 /xj
rd /s /q tempdel 1>NUL 2>NUL
ja genau, das ist der Zweck, dass der Ordner selbst eigentlich nicht gelöscht wird. Und durch "if not exist" wird abgefangen, falls der Ordner z.B. vorher schon nicht existiert haben sollte. Dass ich ihn selber nicht lösche wenn ich mich darin befinde ist ja eigentlich klar …
Der untere Teil nutzt natürlich nur, wenn ich mich mal als Admin anmelden sollte.
Und Systemprozesse sperren ihre Dateien normalerweise, so dass diese bestehen bleiben (perflog, ClickToRun-Blabla etc.)
Hier ist %TEMP% und %TMP% im Benutzerprofil des Arbeitsaccounts auf R:\Temp gesetzt und R:\ ist eine RAMDisk, die naturgemäss bei jedem Neustart neu angelegt wird.
Vorsicht beim Löschen der Temp-Ordner… Musste ich letztens auch mal machen, und bin beinahe auf die Schnauze gefallen. Danach war nämlich mein WSL-Linux kautt, es startete nicht mehr.
es half aber
wsl –unregister
wsl –install
Die Linux-Installation selbst blieb unverändert.
Ich hatte ein solches Verhalten an meinem privaten PC (Windows 10). Teilweise hat die Anmeldung Minuten gedauert. Laut Ereignislog war es der Benutzerprofildienst der so lange brauchte.
Mein Temp Ordner hatte sich auf 60GB oder so aufgeblasen und als ich den zufällig leerte ging das anmelden wieder Ruck Zuck.
Ich hätte bisher nicht gedacht, dass es hier einen Zusammenhang gäbe.
vielleicht für viele eine Bastellei, aber all unsere Systeme nutzen Temp Ordner mit Verweis in ein Ramdrive (setx Temp/Temp)
Vorteile sind:
1. Temps werden bei jedem Neustart vollständig geleert
2. butterweiche Profile
Mir ist klar, dass das womöglich Probleme bereiten kann. In der Praxis nicht.
Die Überschrift Login am Domain Controller ist verwirrend. Es geht hier doch wohl um das ganz normale Anmelden eines Benutzerkontos an einem Arbeitsplatz PC der Mitglied einer Windows-Domäne ist?
Login am Domain Controller deute ich aber so, dass sich der (hoffentlich) Administrator am DC selbst anmeldet um dort Admin Zeugs zu machen…
Wenn also um erstes geht. Joa – da gibt es soooo viele Ursachen für langsames Anmelden. Gigantisches Benutzerprofil mit Myriaden von Dateien ist da nur eines von vielen…
Das Verhalten ist nachvollziehbar, denn es wird ständig in den Temp-Ordnern gelesen und geschrieben. Und je mehr Dateien da drin stecken, desto länger dauert das Lesen des Verzeichnisinhalts.
Und auch die allgemeine Arbeit verlangsamt sich dadurch.
Deutlich spüren konnten wir das bei unserer CAD-Software.
Ab ca. 5000 Dateien im Temp-Ordner wurde die merklich langsamer, insbesondere bei PCs mit HDD (Bei SSDs merkt man das nicht so schnell).
Leider gibt es sehr viele Programme, die ihre temporären Dateien beim Beenden nicht aufräumen.
Deshalb wird bei uns regelmäßig sowohl der Ordner %userprofile%/AppData/Local/Temp als auch der Ordner %windir%/temp regelmäßig geleert.
Es gibt auch Anwendungen, die sich einen Dreck um die Umgebungsvariablen %tmp% und %temp% scheren (auch von Microsoft!) und die Standardordner verwenden.
Deshalb sollte man auch, wenn man die Tempordner über Systemvariablen umgeleitet hat, regelmäßig in die Standardordner rein schauen.
Und die Datenträgerbereinigung leert auch beim Anhaken der temporären Dateien diese beiden Ordner nicht!
Leider gibt es sehr viele Programme, die ihre temporären Dateien beim Beenden nicht aufräumen._
Vielleicht konnten sie es nicht mehr löschen, weil sie aus dem , Speicher gekickt wurden?
Weshalb es eigentlich zu um Guten Ton gehört seinen, Müll beim Starten zu entfernen….
Aber wer macht das schon…
Stört doch nicht in der Zeit der Terabyte Platten.
> Das Verhalten ist nachvollziehbar
naja, eigentlich nicht. Was hindert ein vernünftig geschriebenes Programm daran, seine Temp-Dateien auch wieder zu löschen, wenn diese nicht mehr benötigt werden?
Windows Einstellungen > System > Speicher >
Speicheroptimierung (aktiv) + Häckchen Temp Dateien löschen + Ausführen z.B 1x Woche
Ich weiß ja nicht wie heute programmiert wird.
Früher war es so, das ein Programm Fehler haben konnte.
Wenn es dann Temp Dateien angelegt hatte, wie sollen die gelöscht werden?
Sie sollten natürlich beim Starten gelöscht werden, nur, wenn jedesmal ein neuer Dateiname erzeugt wird, bleiben sie liegen.
Es kostet natürlich Zeit so etwas wegzuräumen, denn die Datei könnte ja von einer anderen Instanz kommen die auch noch läuft…
Bei anderen Betriebssystemen wird TMP bei jedem Boot neu angelegt, ja es gibt sogar ein spezielles Dateisystem hörte. Ein RAM drive ist ein ziemlich teurer Würg around, das RAM könnte besser genutzt werden. Aber was soll's, wird halt noch ein Streifen mehr reingesetzt…
Den Kommentar bzgl. CAD Software kann ich bestätigen inkl Verbesserung bei der Performance
C:\Users\USERNAME\AppData\Local\Temp\Proteinrun
War das Verzeichnis bei uns, dass sich SPORADISCH bei manchen Usern gefüllt hat.