
Zitat von
honx
soweit ich das beurteilen kann, tritt das nicht regelmässig auf. oftmals vergehen auch mehrere monate dazwischen. manchmal jedoch nur 10 tage, siehe chronologische auflistung.
[...] gestern nacht um 03:20 uhr trat der fehler übrigens wieder auf, diesmal lagen erstmals nur 3 tage dazwischen.
Vielleicht könnte man es trotzdem ignorieren, solange keine ernsten Probleme auftauchen, ist wohl eine Ermessenssache, ob sich der Aufwand für dich lohnt. Die *.nfo-Datei gucke ich mir mal, wenn ich die nötige Ruhe dafür finde, näher an. Bisher habe ich die Infos grob durchgeguckt.
wegen dism oder sfc muss ich mal sehen, ob ich mich da ran wage (von letzterem höre/lese ich heute zum ersten mal).
Der System File Checker ist das Programm zum Überprüfen der Systemdateien.
Eigentlich sollte man, wenn möglich, per DISM vorher die Katalogdateien prüfen und nötigenfalls reparieren lassen, weil SFC sonst u.U. von verfälschten oder unvollständigen Informationen (in Katalogdateien) ausgehen könnte. Aber unter Windows 7 ist DISM auf ein Installations-Image angewiesen, wobei man kaum ein aktuelles Image haben wird (was nach der Reparatur Updates erfordert). Ferner ist das Tool unter Windows 7 noch nicht ganz vollständig. Man müsste also sehen, was trotzdem schon geht. Das war eher als ein Hinweis zur Vollständigkeit gedacht, falls alle Register probiert werden sollen. Vermutlich ist das in deinem Fall nicht unbedingt angebracht.
SFC kannst du trotzdem verwenden, aber es bezieht sich dann eben auf Informationen, bei denen du darauf angewiesen bist, dass sie noch stimmen. Ohne etwas Mut zur Lücke geht es also nicht. Normalerweise geschieht für einen automatischen Reparaturdurchlauf der Aufruf mit dem Parameter /SCANNOW. Man könnte stattdessen vorsichtshalber erst mal mit /VERIFYONLY die Integrität der Systemdateien lediglich testen lassen, um bei Funden selber zu entscheiden, wie verfahren werden soll. Das ist die sicherere Variante, z.B. zum Vorbeugen eines Kaputtreparierens wegen falscher Informationen.
CHKDSK ist vor den anderen Tools anzuwenden und sowieso zum gelegentlichen Gebrauch zu empfehlen. Ich würde mich nicht auf automatische Dateisystemüberprüfungen verlassen, da diese unter laufendem Windows vielleicht nicht gründlich genug sein könnten. Ich glaube z.B. kaum, dass sich die Berechtigungseinträge so schnell überprüfen lassen. Wenn du CHKDSK auf das Systemlaufwerk anwendest, dann wirst du normalerweise gefragt, ob du das beim nächsten Start von Windows ausführen lassen willst (um Zugriffe auf die Partition zu unterbinden). Das geht dann nicht ganz so schnell.
wie bzw. wo kann ich von dir angesprochene prefetch-dateien löschen?
Eingabeaufforderung mit Administratorberechtigungen starten, dort eingeben und jeweils mit Enter bestätigen (vor allem beim DEL-Befehl nicht vertippen, und falls dein Systemlaufwerk nicht C heißt, müsste das angepasst werden):
Code:
sc stop SysMain
del /s /f /q C:\Windows\Prefetch\*.*
sc start SysMain
Falls nach der ersten Zeile gemeldet wird, dass der Dienst sowieso nicht läuft (sinngemäß), dann lässt du die dritte Zeile aus. Falls der Dienst ordnungsgemäß beendet wurde, gibst du sie (zum Starten) ein. Anschließend ist ein umgehender Neustart zwar nicht nötig, aber u.U. empfehlenswert.
geradeeben lasse ich jedenfalls mal die datenträgerbereinigung laufen. diese "berechnung" dauert auch immer ewig...
Auch bei ziemlich frischem Windows habe ich schon lange warten müssen. Allerdings kann sich die Wartezeit durch Fehler (z.B. irgendwelche Zugriffsprobleme) noch teils drastisch verlängern. Das unzumutbar lange Warten kann schon von Kleinigkeiten ausgelöst werden. Es ist leider normal, wenn in dieser Phase das Herunterfahren blockiert ist.
//edit: nach dem esten neustart ist heute erstmalig ein ganz neuer fehler in der ereignisanzeige aufgetaucht:
nach einem zweiten neustart erschien diese neue meldung nicht mehr.
Solche DCOM-Zeitüberschreitungsfehler sind teilweise normal. Dieser scheint etwas mit dem Thumbnail-Cache zu tun zu haben und könnte noch mit der zuvor erfolgten Datenträgerbereinigung zusammenhängen, falls angewiesen wurde, diesen Cache zu leeren.
und dann gibts mit jedem neustart eine von microsoft security essentials verursachte meldung in der ereignisanzeige, jene ist normal. besagter fehler erscheint seit ich 2019 microsoft security essentials als ersatz der bis dahin genutzten panda endpoint protection installiert hab, etwa einen monat danach gings mit den meldungen in der ereignisanzeige los. der vollständigkeit halber kopiere ich eine solche meldung auch mal mit rein.
Ja, ignorieren, würde ich sagen. Gut, man könnte testweise die *.etl-Datei löschen (weiß man vorher nicht, ob es was bringt) oder dieses Logging des Kernels einfach deaktivieren (habe ich damals oft mit diversen Loggings unter Vista und 7 gemacht, damit das System etwas flinker reagiert, indem es u.a. weniger auf dem HDD herumrödelt). Es ist aber grundsätzlich damit zu rechnen, dass Windows es irgendwann wieder aktiviert.
hab heute mal wieder die defragmentierung per gui manuell angestossen, da mir das keine ruhe gelassen hat. lief vollständig und erfolgreich durch. ohne fehler im eventviewer.
Erfreulich.