"beschädigte Dateien" - was ist schief gelaufen?

Randy89

Captain
Registriert
Mai 2013
Beiträge
3.287
Erstmal vorneweg: Es ist kein akkutes Problem, da ich ein Backup zurückgespielt habe, wo es noch keine Integritätsverletzungen gab.
Mich würde es trotzdem interessieren, wie es dazu kam, dass sfc /scannow, bzw. sfc /verifyonly so plötzlich "beschädigte Dateien" gefunden haben sollten.

Ausgangsbasis: Vor ein paar Tagen hatte ich nach gründlichem Scannen auf den höchsten Settings mit der Kaspersky Live CD folgendes gefunden:
Objects Scan: completed 5 minutes ago (events: 3, objects: 5228743, time: 03:25:06)
3/5/14 6:39 AM Task started
3/5/14 7:47 AM Processing error C:/Windows/winsxs/amd64_microsoft-windows-winocr-ocrengines_31bf3856ad364e35_6.2.9200.16384_none_fc0ebe40bcd54a89/tctree.dat Read error
3/5/14 10:04 AM Task completed
Natürlich hab ich die Datei, bzw. eine Kopie davon, die mit SHA 512-Werten übereinstimmt, bei Virustotal hochgeladen, ohne dass jemand angeschlagen hat.
Also fuhr ich ganz normal fort mit Datenträgerbereinigung, alle Wiederherstellungspunkte löschen, sofort einen neuen zu erstellen und dann das Image-Backup zu fahren.

Hauptteil:
Da ein Lesefehler ein Anzeichen eines Dateisystemdefekts/Festplattenfehlers sein könnte, dachte ich mir, eine kurze Überprüfung über die Laufwerkseigenschaftsseite könnte nicht schaden. Gesagt getan, verlautete mir Windows, ich sollte zur Reparatur den Computer neu starten. Nach ca. 5 Minuten und 2 Neustarts war der Computer wieder betriebsbereit.
Ein chkdsk /f /r, sowie ein erneuter Check über die GUI, haben nachher keine Fehler ergeben.

Dann hab ich da noch die Datei C:\bootsqm.dat entdeckt, auf VT hochgeladen, danach gesucht und im Anschluss gelöscht, als ich erfahren habe, dass man die Datei sicher löschen könnte.
Ansonsten war ich noch auf irgendeiner botnetz-Testseite angeregt durch diesen Thread ohne negativen Ergebnisse natürlich. ;)
Dort wurde auf irgendeiner Unterseite der Avira EU-Cleaner angeboten, also hab ich ihn mir interesseshalber heruntergeladen, auf VT die Infos mit dem grünen "es scheint harmlos zu sein" Banner, einem Fehlalarm und den Signaturen (Signers: Avira, ..., Countersigners: Symantec...) angesehen, nochmal lokal mit Qihoo 360 gescannt, ohne Funde, und dann ausgeführt. Einen Komplettscan hab ich jedoch nicht gestartet, da ich mir erst die Settings anschauen wollte.
Dann schienen die Symbole im Internet plötzlich gesponnen zu haben, z.B. die Häckchen auf VT, sodass ich kurzerhand die Systemwiederherstellung zurückgespielt habe. Nach ungefähr einer Minute landete ich erneut auf dem Desktop. Ich startete abermals die Prüfung des Laufwerks C: über die GUI ohne gefundene Probleme und hab nachgeschaut, ob die Symbole wieder normal waren, was sie auch waren. :)

Irgendwann später hab ich dann sfc /scannow gestartet und beschädigte Dateien gefunden. Also hab ich das Image zurückgespielt, nochmal über die GUI-Prüfung und dem darauffolgenden Neustart das Laufwerk von Windows reparieren lassen, die C:\bootsqm.dat diesmal in Ruhe gelassen (welche später auch von selbst wieder verschwand), war nicht mehr auf der Bottest-Seite und hab auch nichts mehr heruntergeladen. sfc /scannow verlief ohne Systemintegritätsverletzungen.


CBS Logs sind im Anhang. Ansonsten noch ein frischer Screen von CDI:
CDI C 09.03.14.JPG

Und noch die Meldung der Reparatur damals:
Protokollname: Application
Quelle: Chkdsk
Datum: 08.03.2014 21:16:36
Ereignis-ID: 26226
Aufgabenkategorie:Keine
Ebene: Informationen
Schlüsselwörter:Klassisch
Benutzer: Nicht zutreffend
Computer: Computername
Beschreibung:
"Chkdsk" wurde im Überprüfungsmodus für eine Volumemomentaufnahme ausgeführt.

Dateisystem auf C: wird überprüft.

Phase 1: Die Basisdatei-Systemstruktur wird untersucht...
0xc0 Cluster, die der Datei "\$MFT <0x1,0>" an Offset "0xe1c0" zugeordnet wurden, werden als frei markiert.
...in der Warteschlage für die Offlinereparatur platziert.

Phase 2: Die Dateinamenverknüpfung wird untersucht...

Phase 3: Sicherheitsbeschreibungen werden untersucht...
Es wurden Probleme erkannt, die offline behoben werden müssen.
Führen Sie "chkdsk /spotfix" zum Beheben der Probleme aus.

----------------------------------------------------------------------


CHKDSK überprüft Dateien (Phase 1 von 3)...
Dateiüberprüfung beendet.

CHKDSK überprüft Indizes (Phase 2 von 3)...
Mehrere Dateien für die Objekt-ID gefunden. Zusätzliche Dateien für die Objekt-ID werden ignoriert.
Mehrere Quotendateien gefunden. Zusätzliche Quotendateien werden ignoriert.
Mehrfachanalysepunkt-Datei gefunden. Weitere Analysepunktdateien werden ignoriert.
Mehrere USN-Journaldateien gefunden. Die überflüssigen USN-Journaldateien werden ignoriert.
Indexüberprüfung beendet.

CHKDSK überprüft Sicherheitsbeschreibungen (Phase 3 von 3)...
Überprüfung der Sicherheitsbeschreibungen beendet.
CHKDSK überprüft USN-Journal...
Die Überprüfung von USN-Journal ist abgeschlossen.

116859903 KB Speicherplatz auf dem Datenträger insgesamt
56187576 KB in 148181 Dateien
99636 KB in 35259 Indizes
0 KB in fehlerhaften Sektoren
304227 KB vom System benutzt
65536 KB von der Protokolldatei belegt
60268464 KB auf dem Datenträger verfügbar

4096 Bytes in jeder Zuordnungseinheit
29214975 Zuordnungseinheiten auf dem Datenträger insgesamt
15067116 Zuordnungseinheiten auf dem Datenträger verfügbar

Ereignis-XML:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Provider Name="Chkdsk" />
<EventID Qualifiers="0">26226</EventID>
<Level>4</Level>
<Task>0</Task>
<Keywords>0x80000000000000</Keywords>
<TimeCreated SystemTime="2014-03-08T20:16:36.000000000Z" />
<EventRecordID>62698</EventRecordID>
<Channel>Application</Channel>
<Computer>Computername</Computer>
<Security />
</System>
<EventData>
<Data>

Dateisystem auf C: wird überprüft.

Phase 1: Die Basisdatei-Systemstruktur wird untersucht...
0xc0 Cluster, die der Datei "\$MFT &lt;0x1,0&gt;" an Offset "0xe1c0" zugeordnet wurden, werden als frei markiert.
...in der Warteschlage für die Offlinereparatur platziert.

Phase 2: Die Dateinamenverknüpfung wird untersucht...

Phase 3: Sicherheitsbeschreibungen werden untersucht...
Es wurden Probleme erkannt, die offline behoben werden müssen.
Führen Sie "chkdsk /spotfix" zum Beheben der Probleme aus.

----------------------------------------------------------------------


CHKDSK überprüft Dateien (Phase 1 von 3)...
Dateiüberprüfung beendet.

CHKDSK überprüft Indizes (Phase 2 von 3)...
Mehrere Dateien für die Objekt-ID gefunden. Zusätzliche Dateien für die Objekt-ID werden ignoriert.
Mehrere Quotendateien gefunden. Zusätzliche Quotendateien werden ignoriert.
Mehrfachanalysepunkt-Datei gefunden. Weitere Analysepunktdateien werden ignoriert.
Mehrere USN-Journaldateien gefunden. Die überflüssigen USN-Journaldateien werden ignoriert.
Indexüberprüfung beendet.

CHKDSK überprüft Sicherheitsbeschreibungen (Phase 3 von 3)...
Überprüfung der Sicherheitsbeschreibungen beendet.
CHKDSK überprüft USN-Journal...
Die Überprüfung von USN-Journal ist abgeschlossen.

116859903 KB Speicherplatz auf dem Datenträger insgesamt
56187576 KB in 148181 Dateien
99636 KB in 35259 Indizes
0 KB in fehlerhaften Sektoren
304227 KB vom System benutzt
65536 KB von der Protokolldatei belegt
60268464 KB auf dem Datenträger verfügbar

4096 Bytes in jeder Zuordnungseinheit
29214975 Zuordnungseinheiten auf dem Datenträger insgesamt
15067116 Zuordnungseinheiten auf dem Datenträger verfügbar
</Data>
<Binary>008A03009BCC0200AB2005000000000049030000450000000000000000000000</Binary>
</EventData>
</Event>
 

Anhänge

  • CBS Logs.rar
    255,5 KB · Aufrufe: 216
Beim nächsten mal CMD mit Administrator ausführen und folgendes eingeben:
dism /online /cleanup-Image /restorehealth

Danach sollte alles wieder okay sein ;)
 
Gute Idee, nur war diesmal das Image in greifbarer Nähe. ;)
Mich würde aber dennoch interessieren, wo genau der Fehler lag.
 
Mich würde aber dennoch interessieren, wo genau der Fehler lag.
Naja - da war halt eine Datei im winsxs-Verzeichnis defekt. Soweit ich das sehe, handelte es sich um eine Daten-Datei für irgendwas mit OCR (Optical Character Recognition)...
Das winsxs-Verzeichnis ist unter Windows 8.1 x64 ca. 5,8 GByte groß - da kann es schonmal passieren, dass eine 22 KByte Datei einfach so kaputt geht. Ich habe das bei mir viel öfter bei Musik-Dateien - da hat man dann nach 1-2 Jahren auf einmal einen Glitch beim Abspielen, der vorher noch nicht da war.
 
Naja - da war halt eine Datei im winsxs-Verzeichnis defekt.
Die WinSxS-Datei (bzw. der Verweis zu der Datei im WinSxS-Ordner) mag ja schon länger beschädigt gewesen zu sein, denn das Windows Systemdateiüberprüfungsprogramm (sfc /scannow bzw. sfc /verifyonly) scheint sich nicht daran gestört zu haben.
Es wundert mich einfach ein wenig, wie aufeinmal der Windows Ressourcenschutz plötzlich "beschädigte Dateien" gefunden und nach einem Backup + erneute GUI-Reparatur "keine Integritätsverletzungen" festgestellt haben sollte.

Ich habe das bei mir viel öfter bei Musik-Dateien - da hat man dann nach 1-2 Jahren auf einmal einen Glitch beim Abspielen, der vorher noch nicht da war.
Bei eigenen oder bei der Standard-Musik? Dass die öffentlichen Bilder/Videos/Musikstücke kaputt gehen können, hab ich schon in anderen Threads hier gelesen, aber bei mir hab ich diese schon längst rausgelöscht.
 
Es ist eine Datei (CHM Hilfe Datei) vom Update KB2769166 kaputt.

2014-03-08 20:28:58, Info CSI 0000088a [SR] Cannot repair member file [l:24{12}]"shfusion.chm" of Microsoft-Windows-NETFXCoreComp.Resources, Version = 6.2.9200.16430, pA = PROCESSOR_ARCHITECTURE_INTEL (0), Culture = [l:10{5}]"ja-jp", VersionScope = 1 nonSxS, PublicKeyToken = {l:8 b:31bf3856ad364e35}, Type neutral, TypeName neutral, PublicKey neutral in the store, hash mismatch
2014-03-08 20:28:58, Info CSI 0000088c [SR] Cannot repair member file [l:24{12}]"shfusion.chm" of Microsoft-Windows-NETFXCoreComp.Resources, Version = 6.2.9200.16430, pA = PROCESSOR_ARCHITECTURE_INTEL (0), Culture = [l:10{5}]"ja-jp", VersionScope = 1 nonSxS, PublicKeyToken = {l:8 b:31bf3856ad364e35}, Type neutral, TypeName neutral, PublicKey neutral in the store, hash mismatch
2014-03-08 20:28:58, Info CSI 0000088d [SR] This component was referenced by [l:158{79}]"Package_25_for_KB2769166~31bf3856ad364e35~amd64~~6.2.1.0.2769166-75_neutral_GDR"
 
Randy89, du hast soweit alles richtig gemacht, aber der Zustand an sich ist inakzeptabel.
Ergänzung ()

seluce schrieb:
Beim nächsten mal CMD mit Administrator ausführen und folgendes eingeben:
dism /online /cleanup-Image /restorehealth

Danach sollte alles wieder okay sein ;)

Dieses Kommando kennt man auch erst richtig seit Windows 8.1. Damit werden Fehler kaschiert. Das Update auf Windows 8.1 erscheint mir recht windig. :)
 
Ich hätte mich wirklich hier gerausgehalten, weil eigentlich alles gesagt wurde und ich auf die Frage
Mich würde es trotzdem interessieren, wie es dazu kam, dass sfc /scannow, bzw. sfc /verifyonly so plötzlich "beschädigte Dateien" gefunden haben sollten.
a. keine Antwort weiß und B mir solche Theoretischen Fragen keinen Post wert sind.
warum ist die Banane krumm, wer weiß was der jeweilige User alles macht und installiert und was da die Systemdateien zerhaut.
Ist mir noch nie passiert.

Aber das hätte sich @ horban einfach sparen können.
Dieses Kommando kennt man auch erst richtig seit Windows 8.1. Damit werden Fehler kaschiert. Das Update auf Windows 8.1 erscheint mir recht windig.
Das Kommando mag ja erst seit Windows 8.1 bekannt sein, keine Ahnung1
Aber Fehler kaschiert werden damit nicht sondern nur die Systemdateien repariert und zwar laut Anleitung noch sorgfältiger wie mit sfc /scannow
da wohl noch andere Ordner und Updates repariert werden.
http://www.pc-experience.de/wbb2/thread.php?threadid=35314
 
Fehler beim Windows-Update sorgen dafür, dass etwas repariert werden muss.
Zum Beispiel:
tiworker
"Windows 8: Update KB2821895 sorgt für Probleme - Lösung gefunden!"
http://www.drwindows.de/content/2086-windows-8-update-kb2821895-sorgt-fuer-probleme.html

Datenträgerbereinigung cleanmgr.exe als Admin starten.

@Randy89
Was sagt das Ereignisprotokoll?
"ocrengines_31bf3856ad364e35_6.2.9200.16384_none_fc0ebe40bcd54a89/tctree.dat Read error "

dürfte wohl ein astreiner Plattenfehler sein?
(Durch das Restore sieht man das nicht mehr. Ein "Profi" macht direkt vor einem Restore natürlich auch noch ein Backup.)
Ergänzung ()

http://www.pc-experience.de/wbb2/thread.php?threadid=35314
"wenn Windows 8.1 ständig einfriert, abstürzt und kaum noch zu bedienen ist."

Das ist einzig und allein die Schuld von Windows! Ein richtiges Betriebssystem kann nicht durch Anwendungsprogramme gestört werden! Das identifiziert den Störer und beendet ihn planmäßig.

IMHO tragen die nachträglich in das OS eingepfriemelten Apps einen großen Teil zu den Störungen bei.
 
Zuletzt bearbeitet:
MagicAndre1981 schrieb:
Es ist eine Datei (CHM Hilfe Datei) vom Update KB2769166 kaputt.
Danke erstmal, top Antwort! :)
Hätt ich doch glatt selber drauf kommen können, aber manchmal sieht man den Text vor lauter Buchstaben nicht. :D
Also wenn es nur die Hilfsdatei zu einem Update gewesen ist, hätte ich es theoretisch so ohne Probleme lassen können?

horban schrieb:
Randy89, du hast soweit alles richtig gemacht, aber der Zustand an sich ist inakzeptabel.
Wie meinst du das? Was ist inakzeptabel?
Und was das Ereignisprotokoll anbelangt: Lies den Spoiler im ersten Beitrag.
edit: hier noch der fehlerfreie Log:
Protokollname: Application
Quelle: Chkdsk
Datum: 09.03.2014 20:58:26
Ereignis-ID: 26226
Aufgabenkategorie:Keine
Ebene: Informationen
Schlüsselwörter:Klassisch
Benutzer: Nicht zutreffend
Computer: Computername
Beschreibung:
"Chkdsk" wurde im Überprüfungsmodus für eine Volumemomentaufnahme ausgeführt.

Dateisystem auf C: wird überprüft.

Phase 1: Die Basisdatei-Systemstruktur wird untersucht...

Phase 2: Die Dateinamenverknüpfung wird untersucht...

Phase 3: Sicherheitsbeschreibungen werden untersucht...

Dateisystem wurde überprüft, keine Probleme festgestellt.
Keine weiteren Aktionen erforderlich.

----------------------------------------------------------------------


CHKDSK überprüft Dateien (Phase 1 von 3)...
Dateiüberprüfung beendet.

CHKDSK überprüft Indizes (Phase 2 von 3)...
Mehrere Dateien für die Objekt-ID gefunden. Zusätzliche Dateien für die Objekt-ID werden ignoriert.
Mehrere Quotendateien gefunden. Zusätzliche Quotendateien werden ignoriert.
Mehrfachanalysepunkt-Datei gefunden. Weitere Analysepunktdateien werden ignoriert.
Mehrere USN-Journaldateien gefunden. Die überflüssigen USN-Journaldateien werden ignoriert.
Indexüberprüfung beendet.

CHKDSK überprüft Sicherheitsbeschreibungen (Phase 3 von 3)...
Überprüfung der Sicherheitsbeschreibungen beendet.
CHKDSK überprüft USN-Journal...
Die Überprüfung von USN-Journal ist abgeschlossen.

Dateisystem wurde überprüft, keine Probleme festgestellt.
Keine weiteren Aktionen erforderlich.

116859903 KB Speicherplatz auf dem Datenträger insgesamt
58071740 KB in 148082 Dateien
99704 KB in 35243 Indizes
0 KB in fehlerhaften Sektoren
337959 KB vom System benutzt
65536 KB von der Protokolldatei belegt
58350500 KB auf dem Datenträger verfügbar

4096 Bytes in jeder Zuordnungseinheit
29214975 Zuordnungseinheiten auf dem Datenträger insgesamt
14587625 Zuordnungseinheiten auf dem Datenträger verfügbar

Ereignis-XML:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Provider Name="Chkdsk" />
<EventID Qualifiers="0">26226</EventID>
<Level>4</Level>
<Task>0</Task>
<Keywords>0x80000000000000</Keywords>
<TimeCreated SystemTime="2014-03-09T19:58:26.000000000Z" />
<EventRecordID>62991</EventRecordID>
<Channel>Application</Channel>
<Computer>Computername</Computer>
<Security />
</System>
<EventData>
<Data>

Dateisystem auf C: wird überprüft.

Phase 1: Die Basisdatei-Systemstruktur wird untersucht...

Phase 2: Die Dateinamenverknüpfung wird untersucht...

Phase 3: Sicherheitsbeschreibungen werden untersucht...

Dateisystem wurde überprüft, keine Probleme festgestellt.
Keine weiteren Aktionen erforderlich.

----------------------------------------------------------------------


CHKDSK überprüft Dateien (Phase 1 von 3)...
Dateiüberprüfung beendet.

CHKDSK überprüft Indizes (Phase 2 von 3)...
Mehrere Dateien für die Objekt-ID gefunden. Zusätzliche Dateien für die Objekt-ID werden ignoriert.
Mehrere Quotendateien gefunden. Zusätzliche Quotendateien werden ignoriert.
Mehrfachanalysepunkt-Datei gefunden. Weitere Analysepunktdateien werden ignoriert.
Mehrere USN-Journaldateien gefunden. Die überflüssigen USN-Journaldateien werden ignoriert.
Indexüberprüfung beendet.

CHKDSK überprüft Sicherheitsbeschreibungen (Phase 3 von 3)...
Überprüfung der Sicherheitsbeschreibungen beendet.
CHKDSK überprüft USN-Journal...
Die Überprüfung von USN-Journal ist abgeschlossen.

Dateisystem wurde überprüft, keine Probleme festgestellt.
Keine weiteren Aktionen erforderlich.

116859903 KB Speicherplatz auf dem Datenträger insgesamt
58071740 KB in 148082 Dateien
99704 KB in 35243 Indizes
0 KB in fehlerhaften Sektoren
337959 KB vom System benutzt
65536 KB von der Protokolldatei belegt
58350500 KB auf dem Datenträger verfügbar

4096 Bytes in jeder Zuordnungseinheit
29214975 Zuordnungseinheiten auf dem Datenträger insgesamt
14587625 Zuordnungseinheiten auf dem Datenträger verfügbar
</Data>
<Binary>008A030028CC020099200500000000005A030000450000000000000000000000</Binary>
</EventData>
</Event>

Terrier schrieb:
Für Windows 8/8.1 finde ich den Link hier ausführlicher: http://www.deskmodder.de/wiki/index.php/Windows_8_reparieren_-_wiederherstellen
Letztendendes hieß es auch in deinem Link, dass ein funktionstüchtiges Image zurückzuspielen immer eine gute Lösung ist. ;)
 
Zuletzt bearbeitet:
Vor ein paar Tagen hatte ich nach gründlichem Scannen auf den höchsten Settings mit der Kaspersky Live CD folgendes gefunden:
Wenn ich Kaspersky nicht als Schild traue, warum sollte ich dann seinem vollen Scanlauf trauen?

Ein Virensuchlauf hat grundsätzlich nichts mit dem zu tun was SFC /SCANNOW liefert zu tun und beide haben nichts damit zu tun was CHDSK tut.
Wenn Du so einen Haufen Nebelkerzen zündest und operative Scanhektik verbeitest muss dir jeder kleine (sprichwörtliche) Furz den die Scanläufe finden wie ein mächtiger (ebenso sprichwörtlicher) Donnerschlag vorkommen. Ich sehe da nichts was die 3 Scans gemeinsam hätten, wo sie alle drei auf das selbe und dann wirklich ernste Problem verweisen würden.

Also durchatmen und wenn die Fehler behoben wurden weitermachen. Wo gehobelt wird fallen nun mal Späne.

CN8
 
Randy89 schrieb:
Und was das Ereignisprotokoll anbelangt...

Das komplette Protokoll mit allen Errors und Warnings.

Randy89 schrieb:
Wie meinst du das? Was ist inakzeptabel?
"3/5/14 7:47 AM Processing error C:/Windows/winsxs/amd64_microsoft-windows-winocr-ocrengines_31bf3856ad364e35_6.2.9200.16384_none_fc0ebe40bcd54a89/tctree.dat Read error"

Das ist doch wohl kein Virus, sondern ein ganz "normaler" Plattenfehler. Die Platte würde ich entfernen.
Ergänzung ()

cumulonimbus8 schrieb:
Wo gehobelt wird fallen nun mal Späne.

Cool. Sag das mal, wenn ein naher Angehöriger wegen eines Computerfehlers auf der Intensivstation verstorben ist.
Ergänzung ()

Randy89 schrieb:
Für Windows 8/8.1 finde ich den Link hier ausführlicher: http://www.deskmodder.de/wiki/index.php/Windows_8_reparieren_-_wiederherstellen
Letztendendes hieß es auch in deinem Link, dass ein funktionstüchtiges Image zurückzuspielen immer eine gute Lösung ist. ;)

Der Mann weiß, wovon er spricht. Er hat wahrscheinlich einige Erfahrung. Die "Reparaturen" sind Pfusch.
 
Zuletzt bearbeitet:
cumulonimbus8 schrieb:
Wenn ich Kaspersky nicht als Schild traue, warum sollte ich dann seinem vollen Scanlauf trauen?
Wie du auf die Frage kommst, erschließt sich mir nicht. Ich verwende nunmal keine kostenpflichtigen Scanner. Abgesehen davon, wenn der volle Scanlauf außerhalb von Windows und von einem der großen Anbieter stammt, hat es durchaus Aussagekraft. Zwar nicht hundertprozentig, aber eine gute Ausgangsbasis.

Ich sehe da nichts was die 3 Scans gemeinsam hätten, wo sie alle drei auf das selbe und dann wirklich ernste Problem verweisen würden.
Ja, der Verweis zu einer Datei für die Texterkennung, eine Hilfsdatei über die erneuerten Digitalen Signaturen und die Masterfile-Table-Datei haben tatsächlich nichts gemeinsam. Aber keine Sorge, durchgeamtet wird schon. :p

@ horban: Ich seh nicht ein, was die anderen Errors und Warnings damit zu tun haben.
edit: Miss Shizuku scheint aber oben zu strahlen, die Platte lief auch ohne die Chkdsk-Reparatur (was auch immer da genau wieder gerichtet wurde) ohne Probleme, mal abgesehen davon, dass die darauffolgenden CHDSK-Versuche komplett fehlerfrei abliefen und du würdest die Platte gleich im Müll schmeißen? :o

edit:
Ja, wenn es nichts war, was das Dateisystem oder defekte Datenträger oder Programme, dll usw. betrifft.
Nein, nichts dergleichen, abgesehen von dem CHKDSK-Eintrag oben im Anfangsbeitrag.
 
Zuletzt bearbeitet:
Randy89 schrieb:
@ horban: Ich seh nicht ein, was die anderen Errors und Warnings damit zu tun haben.

Ja, wenn es nichts war, was das Dateisystem oder defekte Datenträger oder Programme, dll usw. betrifft. Manche Sachen machen sich indirekt bemerkbar.
 
horban schrieb:
Dieses Kommando kennt man auch erst richtig seit Windows 8.1. Damit werden Fehler kaschiert.

den Befehl gibt es seit der ersten Win8 Preview und kaschiert gar nix. Es ersetzt das checkSur Update von Vista/7 und lädt defekte Dateien aus dem Internet herunter.

Randy89 schrieb:
Danke erstmal, top Antwort! :)
Hätt ich doch glatt selber drauf kommen können, aber manchmal sieht man den Text vor lauter Buchstaben nicht. :D
Also wenn es nur die Hilfsdatei zu einem Update gewesen ist, hätte ich es theoretisch so ohne Probleme lassen können?

führe einfach beim nächsten Mal den DISM Befehl aus und lasse Windows die Dateien reparieren.
 
MagicAndre1981 schrieb:
den Befehl gibt es seit der ersten Win8 Preview und kaschiert gar nix. Es ersetzt das checkSur Update von Vista/7 und lädt defekte Dateien aus dem Internet herunter.

Verstehe ich das richtig? Du findest es normal, dass sich ein System (zeitweise) in einem defekten Zustand befindet? Dieser Zustand wird wird im Normalfall nie erkannt - höchstens zufällig bei anderen Störungen. Kein Normalanwender kennt das Kommando.

Bei einem Einsatz im Unternehmen würde ich mit diesem Kommando im Notfall gerade noch das System flicken, um die Daten zu sichern und das OS neu zu installieren. Man müsste den Vorgesetzten informieren und Microsoft zu dem Vorfall befragen, und bei Wiederholung auf ein anderes Betriebssystem wechseln.

Was sagt denn Microsoft offiziell zu dieser Situation?
 
Zuletzt bearbeitet:
MagicAndre1981 schrieb:
führe einfach beim nächsten Mal den DISM Befehl aus und lasse Windows die Dateien reparieren.
Werde ich das nächste Mal versuchen und wenn es nicht klappt, entweder das betroffene Update neu installieren oder wieder die Sicherung zurückspielen.

horban schrieb:
Verstehe ich das richtig? Du findest es normal, dass sich ein System (zeitweise) in einem defekten Zustand befindet?
Naja, was heißt hier defekt: Wie oft ruft man eigentlich die Hilfe zu einem .net-Framework Update auf (noch dazu, dass grad mal die japanische Version betroffen worden ist)?

Bei einem Einsatz im Unternehmen würde ich mit diesem Kommando im Notfall gerade noch das System flicken, um die Daten zu sichern und das OS neu zu installieren.
Ist das nicht ein wenig übertrieben? Wie gesagt, auch wenn ich keine Reparatur vom Laufwerk gemacht hätte, bzw. für die beschädigten Hilfe-Dateien, würde ich so gut wie keine Probleme feststellen, bis auf, dass es schon in seltenen Fällen vorgekommen ist, dass der Computer eingefroren ist (meist unmittelbar nach einem Reset im POST-Screen, allerdings könnte es auch von was anderem kommen), aber manche würden wegen jedem kleinen Fehler gleich funktionstüchtige Teile austauschen. Meinen MP3-Player mit immernoch guter Akkulaufzeit schmeiß ich doch auch nicht gleich weg, nur weil er sich jemals aufgehangen hatte. Für solche Sachen wurde schließlich der Reset-Knopf erfunden. ;)

Auch in einem Unternehmen würden die sich lieber mit einer Reparatur, bzw. einem Neustart zu helfen wissen als gleich neuzuinstallieren oder neuzukaufen, weil der Zeitverlust oder das verwendete Geld nicht in dem Verhältnis des Nutzens steht.
 
Zuletzt bearbeitet:
horban schrieb:
Verstehe ich das richtig? Du findest es normal, dass sich ein System (zeitweise) in einem defekten Zustand befindet? Dieser Zustand wird wird im Normalfall nie erkannt - höchstens zufällig bei anderen Störungen. Kein Normalanwender kennt das Kommando.

Bei einem Einsatz im Unternehmen würde ich mit diesem Kommando im Notfall gerade noch das System flicken, um die Daten zu sichern und das OS neu zu installieren. Man müsste den Vorgesetzten informieren und Microsoft zu dem Vorfall befragen, und bei Wiederholung auf ein anderes Betriebssystem wechseln.

Was sagt denn Microsoft offiziell zu dieser Situation?
Offiziell genug? Fixing component store corruption in Windows 8 and Windows Server 2012
Das sich Dateien in einem Dateisystem zerlegen ist relativ normal. Das passiert durch amoklaufende Treiber, Stromversorgunsprobleme, usw. Ich muss dir allerdings insofern rechtgeben, als das ich es auch nicht in Ordung finde, wie MS dieses ganze Compontent Store Geschichte umgesetzt hat. Es gibt viel zu wenig Prüfsummen und die automatischen Reparaturmechanismen sind alles andere als zuverlässig.
 
Zurück
Oben