5
Dateisystem fehlerhaft
Hallo,
ich habe seit längerer Zeit das Problem, daß in der Taskleiste immer wieder defekte (System-) Dateien gemeldet werden. Es gab auch 2-3mal blue screens. Nach einem Neustart meldet sich checkdisk und prüft und repariert irgendwas. Ansonsten ist nichts auffällig.
Zum System:
Win 2008 Server Standard 32 Bit und ist Up-to-date
SAS 15k Platten mit RAID1 600GB an LSI MgaRAID 512MB Controller mit Batt.
2x 2GB ECC RAM
McAfee SaaS Protection
Was ich bis jetzt unternommen habe:
chkdsk /F und chkdsk /F /R /B mehrfach ausgeführt, es wird auch irgendwas repariert, beim Neustart des Servers ackert aber checkdisk wieder los
sfc /scannow ausgeführt, hier wird auch etwas repariert, löst aber nicht das eigentliche Problem
Die Systemeigenen Tools ausgeführt -> Hardware OK
Nachgesehen ob Disk Fehler in der Ereignisanzeige protokolliert sind ->negativ
chkntfs c: ausgeführt -> meldet c: ist fehlerhaft
Disk, Raid und Win Cache abgeschaltet -> Fehler immer noch da
Firmware und Treiber auf den aktuellen Stand gebracht ->keine Veränderung
rdx Filekeeper deinstalliert -> Fehler immer noch da, aber das System hat einen spürbaren Performancegewinn
Ein RAM-Modul ausgebaut, seitdem keine Fehlermeldung in der Taskleiste über beschädigte Dateien mehr (Zufall?), checkdisk bringt aber immer noch Fehler
Das aktuell verbaute RAM-Modul mit memtest86 getestet -> OK (3 Durchläufe), das andere RAM-Modul habe ich noch nicht getestet und ist noch ausgebaut.
Nun, wenn es ein PC wäre hätte ich ihn schon längst neu aufgesetzt. Eine Systemsicherung liegt nicht vor - Datensichrung ist vorhanden und wird täglich auf RDX-LW durchgeführt. Vielleicht hat ja Jemand noch eine Idee oder weiss was zu tun ist? Ich zumindest habe keine Idee mehr...
KarlE
Hier noch das checkdisk-log:
Dateisystem auf C: wird überprüft.
Der Typ des Dateisystems ist NTFS.
Die Volumebezeichnung lautet System.
Einer der Datenträger muss auf Konsistenz überprüft werden.
Sie können die Datenträgerüberprüfung abbrechen, aber es
wird ausdrücklich empfohlen, den Vorgang fortzusetzen.
Die Datenträgerüberprüfung wird jetzt ausgeführt.
1674176 Datensätze verarbeitet. 2323 große Datensätze verarbeitet. 0 ungültige Datensätze verarbeitet. 0 E/A-Datensätze verarbeitet. 99 Analysedatensätze verarbeitet. Das Dateinamenattribut des Indexeintrags System.Drawing.dll von Index $I30,
der 0x383 untergeordnet ist, kann in der Datei 0x10e981 nicht
gefunden werden.
Indexeintrag System.Drawing.dll in Index $I30 der Datei 899 wird gelöscht.
Das Dateinamenattribut des Indexeintrags System.DirectoryServices.dll von Index $I30,
der 0x785 untergeordnet ist, kann in der Datei 0x10e977 nicht
gefunden werden.
Indexeintrag System.DirectoryServices.dll in Index $I30 der Datei 1925 wird gelöscht.
Das Dateinamenattribut des Indexeintrags System.DirectoryServices.Protocols.dll von Index $I30,
der 0x785 untergeordnet ist, kann in der Datei 0x10e96e nicht
gefunden werden.
Indexeintrag System.DirectoryServices.Protocols.dll in Index $I30 der Datei 1925 wird gelöscht.
Das Dateinamenattribut des Indexeintrags kernel32.dll.mui von Index $I30,
der 0x916 untergeordnet ist, kann in der Datei 0x10f44c nicht
gefunden werden.
Indexeintrag kernel32.dll.mui in Index $I30 der Datei 2326 wird gelöscht.
Das Dateinamenattribut des Indexeintrags kernel32.dll.mui von Index $I30,
der 0x92e untergeordnet ist, kann in der Datei 0x10f45c nicht
gefunden werden.
Indexeintrag kernel32.dll.mui in Index $I30 der Datei 2350 wird gelöscht.
Das Dateinamenattribut des Indexeintrags kernel32.dll.mui von Index $I30,
der 0xc48 untergeordnet ist, kann in der Datei 0x10f444 nicht
gefunden werden.
Indexeintrag kernel32.dll.mui in Index $I30 der Datei 3144 wird gelöscht.
Das Dateinamenattribut des Indexeintrags kernel32.dll.mui von Index $I30,
der 0xd4e untergeordnet ist, kann in der Datei 0x10f43c nicht
gefunden werden.
Indexeintrag kernel32.dll.mui in Index $I30 der Datei 3406 wird gelöscht.
Das Dateinamenattribut des Indexeintrags kernel32.dll.mui von Index $I30,
der 0xe1d untergeordnet ist, kann in der Datei 0x10f458 nicht
gefunden werden.
Indexeintrag kernel32.dll.mui in Index $I30 der Datei 3613 wird gelöscht.
Das Dateinamenattribut des Indexeintrags kernel32.dll.mui von Index $I30,
der 0xe9b untergeordnet ist, kann in der Datei 0x10f434 nicht
gefunden werden.
Indexeintrag kernel32.dll.mui in Index $I30 der Datei 3739 wird gelöscht.
1891582 Indexeinträge verarbeitet. CHKDSK stellt verlorene Dateien wieder her.
Verwaiste Datei System.DirectoryServices.Protocols.dll (1108334) wird in Verzeichnisdatei 1925 wiederhergestellt.
Verwaiste Datei System.DirectoryServices.dll (1108343) wird in Verzeichnisdatei 1925 wiederhergestellt.
Verwaiste Datei System.Drawing.dll (1108353) wird in Verzeichnisdatei 899 wiederhergestellt.
Verwaiste Datei kernel32.dll.mui (1111092) wird in Verzeichnisdatei 3739 wiederhergestellt.
Verwaiste Datei kernel32.dll.mui (1111100) wird in Verzeichnisdatei 3406 wiederhergestellt.
Verwaiste Datei kernel32.dll.mui (1111108) wird in Verzeichnisdatei 3144 wiederhergestellt.
Verwaiste Datei kernel32.dll.mui (1111116) wird in Verzeichnisdatei 2326 wiederhergestellt.
Verwaiste Datei kernel32.dll.mui (1111128) wird in Verzeichnisdatei 3613 wiederhergestellt.
9 nicht indizierte Dateien verarbeitet. Verwaiste Datei kernel32.dll.mui (1111132) wird in Verzeichnisdatei 2350 wiederhergestellt.
1674176 Sicherheitsbeschreibungen verarbeitet. 4 nicht verwendete Indexeinträge aus Index $SII der Datei 0x9 werden aufgeräumt.
4 nicht verwendete Indexeinträge aus Index $SDH der Datei 0x9 werden aufgeräumt.
4 nicht verwendete Sicherheitsbeschreibungen werden aufgeräumt.
108704 Datendateien verarbeitet. CHKDSK überprüft USN-Journal...
540080000 USN-Bytes verarbeitet. Die Überprüfung von USN-Journal ist abgeschlossen.
Windows hat Probleme im Dateisystem behoben.
585529340 KB Speicherplatz auf dem Datenträger insgesamt
207347736 KB in 1028893 Dateien
401108 KB in 108705 Indizes
0 KB in fehlerhaften Sektoren
2298056 KB vom System benutzt
65536 KB von der Protokolldatei belegt
375482440 KB auf dem Datenträger verfügbar
4096 Bytes in jeder Zuordnungseinheit
146382335 Zuordnungseinheiten auf dem Datenträger insgesamt
93870610 Zuordnungseinheiten auf dem Datenträger verfügbar
Interne Informationen:
c0 8b 19 00 c7 5b 11 00 e9 22 18 00 00 00 00 00 .....[..."......
b4 02 00 00 63 00 00 00 00 00 00 00 00 00 00 00 ....c...........
90 1a 25 00 48 01 25 00 35 09 00 3c 88 83 26 00 ..%.H.%.5..<..&.
Die Überprüfung des Datenträgers wurde abgeschlossen.
Bitte warten Sie bis der Computer neu gestartet wurde.
ich habe seit längerer Zeit das Problem, daß in der Taskleiste immer wieder defekte (System-) Dateien gemeldet werden. Es gab auch 2-3mal blue screens. Nach einem Neustart meldet sich checkdisk und prüft und repariert irgendwas. Ansonsten ist nichts auffällig.
Zum System:
Win 2008 Server Standard 32 Bit und ist Up-to-date
SAS 15k Platten mit RAID1 600GB an LSI MgaRAID 512MB Controller mit Batt.
2x 2GB ECC RAM
McAfee SaaS Protection
Was ich bis jetzt unternommen habe:
chkdsk /F und chkdsk /F /R /B mehrfach ausgeführt, es wird auch irgendwas repariert, beim Neustart des Servers ackert aber checkdisk wieder los
sfc /scannow ausgeführt, hier wird auch etwas repariert, löst aber nicht das eigentliche Problem
Die Systemeigenen Tools ausgeführt -> Hardware OK
Nachgesehen ob Disk Fehler in der Ereignisanzeige protokolliert sind ->negativ
chkntfs c: ausgeführt -> meldet c: ist fehlerhaft
Disk, Raid und Win Cache abgeschaltet -> Fehler immer noch da
Firmware und Treiber auf den aktuellen Stand gebracht ->keine Veränderung
rdx Filekeeper deinstalliert -> Fehler immer noch da, aber das System hat einen spürbaren Performancegewinn
Ein RAM-Modul ausgebaut, seitdem keine Fehlermeldung in der Taskleiste über beschädigte Dateien mehr (Zufall?), checkdisk bringt aber immer noch Fehler
Das aktuell verbaute RAM-Modul mit memtest86 getestet -> OK (3 Durchläufe), das andere RAM-Modul habe ich noch nicht getestet und ist noch ausgebaut.
Nun, wenn es ein PC wäre hätte ich ihn schon längst neu aufgesetzt. Eine Systemsicherung liegt nicht vor - Datensichrung ist vorhanden und wird täglich auf RDX-LW durchgeführt. Vielleicht hat ja Jemand noch eine Idee oder weiss was zu tun ist? Ich zumindest habe keine Idee mehr...
KarlE
Hier noch das checkdisk-log:
Dateisystem auf C: wird überprüft.
Der Typ des Dateisystems ist NTFS.
Die Volumebezeichnung lautet System.
Einer der Datenträger muss auf Konsistenz überprüft werden.
Sie können die Datenträgerüberprüfung abbrechen, aber es
wird ausdrücklich empfohlen, den Vorgang fortzusetzen.
Die Datenträgerüberprüfung wird jetzt ausgeführt.
1674176 Datensätze verarbeitet. 2323 große Datensätze verarbeitet. 0 ungültige Datensätze verarbeitet. 0 E/A-Datensätze verarbeitet. 99 Analysedatensätze verarbeitet. Das Dateinamenattribut des Indexeintrags System.Drawing.dll von Index $I30,
der 0x383 untergeordnet ist, kann in der Datei 0x10e981 nicht
gefunden werden.
Indexeintrag System.Drawing.dll in Index $I30 der Datei 899 wird gelöscht.
Das Dateinamenattribut des Indexeintrags System.DirectoryServices.dll von Index $I30,
der 0x785 untergeordnet ist, kann in der Datei 0x10e977 nicht
gefunden werden.
Indexeintrag System.DirectoryServices.dll in Index $I30 der Datei 1925 wird gelöscht.
Das Dateinamenattribut des Indexeintrags System.DirectoryServices.Protocols.dll von Index $I30,
der 0x785 untergeordnet ist, kann in der Datei 0x10e96e nicht
gefunden werden.
Indexeintrag System.DirectoryServices.Protocols.dll in Index $I30 der Datei 1925 wird gelöscht.
Das Dateinamenattribut des Indexeintrags kernel32.dll.mui von Index $I30,
der 0x916 untergeordnet ist, kann in der Datei 0x10f44c nicht
gefunden werden.
Indexeintrag kernel32.dll.mui in Index $I30 der Datei 2326 wird gelöscht.
Das Dateinamenattribut des Indexeintrags kernel32.dll.mui von Index $I30,
der 0x92e untergeordnet ist, kann in der Datei 0x10f45c nicht
gefunden werden.
Indexeintrag kernel32.dll.mui in Index $I30 der Datei 2350 wird gelöscht.
Das Dateinamenattribut des Indexeintrags kernel32.dll.mui von Index $I30,
der 0xc48 untergeordnet ist, kann in der Datei 0x10f444 nicht
gefunden werden.
Indexeintrag kernel32.dll.mui in Index $I30 der Datei 3144 wird gelöscht.
Das Dateinamenattribut des Indexeintrags kernel32.dll.mui von Index $I30,
der 0xd4e untergeordnet ist, kann in der Datei 0x10f43c nicht
gefunden werden.
Indexeintrag kernel32.dll.mui in Index $I30 der Datei 3406 wird gelöscht.
Das Dateinamenattribut des Indexeintrags kernel32.dll.mui von Index $I30,
der 0xe1d untergeordnet ist, kann in der Datei 0x10f458 nicht
gefunden werden.
Indexeintrag kernel32.dll.mui in Index $I30 der Datei 3613 wird gelöscht.
Das Dateinamenattribut des Indexeintrags kernel32.dll.mui von Index $I30,
der 0xe9b untergeordnet ist, kann in der Datei 0x10f434 nicht
gefunden werden.
Indexeintrag kernel32.dll.mui in Index $I30 der Datei 3739 wird gelöscht.
1891582 Indexeinträge verarbeitet. CHKDSK stellt verlorene Dateien wieder her.
Verwaiste Datei System.DirectoryServices.Protocols.dll (1108334) wird in Verzeichnisdatei 1925 wiederhergestellt.
Verwaiste Datei System.DirectoryServices.dll (1108343) wird in Verzeichnisdatei 1925 wiederhergestellt.
Verwaiste Datei System.Drawing.dll (1108353) wird in Verzeichnisdatei 899 wiederhergestellt.
Verwaiste Datei kernel32.dll.mui (1111092) wird in Verzeichnisdatei 3739 wiederhergestellt.
Verwaiste Datei kernel32.dll.mui (1111100) wird in Verzeichnisdatei 3406 wiederhergestellt.
Verwaiste Datei kernel32.dll.mui (1111108) wird in Verzeichnisdatei 3144 wiederhergestellt.
Verwaiste Datei kernel32.dll.mui (1111116) wird in Verzeichnisdatei 2326 wiederhergestellt.
Verwaiste Datei kernel32.dll.mui (1111128) wird in Verzeichnisdatei 3613 wiederhergestellt.
9 nicht indizierte Dateien verarbeitet. Verwaiste Datei kernel32.dll.mui (1111132) wird in Verzeichnisdatei 2350 wiederhergestellt.
1674176 Sicherheitsbeschreibungen verarbeitet. 4 nicht verwendete Indexeinträge aus Index $SII der Datei 0x9 werden aufgeräumt.
4 nicht verwendete Indexeinträge aus Index $SDH der Datei 0x9 werden aufgeräumt.
4 nicht verwendete Sicherheitsbeschreibungen werden aufgeräumt.
108704 Datendateien verarbeitet. CHKDSK überprüft USN-Journal...
540080000 USN-Bytes verarbeitet. Die Überprüfung von USN-Journal ist abgeschlossen.
Windows hat Probleme im Dateisystem behoben.
585529340 KB Speicherplatz auf dem Datenträger insgesamt
207347736 KB in 1028893 Dateien
401108 KB in 108705 Indizes
0 KB in fehlerhaften Sektoren
2298056 KB vom System benutzt
65536 KB von der Protokolldatei belegt
375482440 KB auf dem Datenträger verfügbar
4096 Bytes in jeder Zuordnungseinheit
146382335 Zuordnungseinheiten auf dem Datenträger insgesamt
93870610 Zuordnungseinheiten auf dem Datenträger verfügbar
Interne Informationen:
c0 8b 19 00 c7 5b 11 00 e9 22 18 00 00 00 00 00 .....[..."......
b4 02 00 00 63 00 00 00 00 00 00 00 00 00 00 00 ....c...........
90 1a 25 00 48 01 25 00 35 09 00 3c 88 83 26 00 ..%.H.%.5..<..&.
Die Überprüfung des Datenträgers wurde abgeschlossen.
Bitte warten Sie bis der Computer neu gestartet wurde.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 229188
Url: https://administrator.de/contentid/229188
Ausgedruckt am: 22.11.2024 um 19:11 Uhr
5 Kommentare
Neuester Kommentar
Hallo,
prüf mal ob alle Einsteckkarten korrekt sitzen und am besten das Mainboard tauschen.
Gruß
Andi
prüf mal ob alle Einsteckkarten korrekt sitzen und am besten das Mainboard tauschen.
Gruß
Andi
Hallo KarlE,
Bau die Platten mal einzeln aus, klemm sie an einen anderen Rechner und prüfe mit den smartmontools die SMART-Parameter der Platten. Eventuell stirbt gerade eine deiner Platten einen langsamen Tod. Hatte solche Fälle schon zu genüge ...
Grüße Uwe
Das aktuell verbaute RAM-Modul mit memtest86 getestet -> OK (3 Durchläufe), das andere RAM-Modul habe ich noch nicht getestet und ist noch ausgebaut.
mindestens jedes Paar jeweils ein paar Stunden durchlaufen lassen, 3 Durchläufe genügen nicht !Bau die Platten mal einzeln aus, klemm sie an einen anderen Rechner und prüfe mit den smartmontools die SMART-Parameter der Platten. Eventuell stirbt gerade eine deiner Platten einen langsamen Tod. Hatte solche Fälle schon zu genüge ...
Eine Systemsicherung liegt nicht vor
Kardinalsfehler !Grüße Uwe
Zitat von @colinardo:
mindestens jedes Paar jeweils ein paar Stunden durchlaufen lassen, 3 Durchläufe genügen nicht !
mindestens jedes Paar jeweils ein paar Stunden durchlaufen lassen, 3 Durchläufe genügen nicht !
zusätzlich solltest Du auch einen ausführlichen HDD-test machen, und zwar nicht mit chkdsk, sondern spezialisieretn HDD-testern, wie den herstelelrtools oder den Tools von der UBCD/HBCD.
lks
Vielen Dank für die Tips,
ich will hier einmal eine Zwischenmeldung geben:
1.
Ich habe das 2. RAM-Modul in den Slot vom getesteten Modul gesteckt und auch 3 Druchgeänge mit memtest86 gemacht ->kein Fehler gefunden.
2.
Also baute ich beide Module (es ist übrigens das einzigste Pärchen) in Originalposition ein. Nach dem Hochfahren des Servers werden wieder beschädigte Dateien gemeldet. Gedanke: Ist der eine RAM-Slot defekt...?
3.
RAM-Modul mit dem der Fehler nicht aufritt (zumindest die Meldung mit den beschädigten Dateien nicht) in den verdächtigen Slot gesteckt -> Meldungen über beschädigte Dateien kommen immer noch. sfc /scannow bricht bei 28% ab.
4.
Das eine RAM-Modul wieder umgesteckt, so wie keine Meldungen über beschädigte Dateien erschienen sind. Nach Start jedoch wieder Meldung über beschädigte Dateien. Gedanke: Evtl. muß ich zuvor nochmal chekdisk reparieren lassen. Checkdisk laufen lassen und danach sfc. sfc ist durchgelaufen und bringt alles sei OK. Die Meldung mit den beschädigten Dateien kommt aber wieder und checkdisk will nach Neustart immer wieder losackern.
5.
Beide RAM in Originalposition wieder eingebaut. Mit Hersteller Diagnostics CD gebootet und einamal Quick und einmal Full Test laufen lassen ->alles OK
Was mir eingefallen ist: die Festplatten wurden vor einigen Monaten gegen größere ausgetauscht. Nicht vom Hersteller sondern vom "Regal". Sprich, es sind Seagate ST3600057SS mit FW 0008 verbaut. Also nach FW-Update gesucht. Hier habe ich eine 000B gefunden und soll ein Zertifikat-Update sein!? Allerdings wird gewarnt diese auf ein RAID-System einzuspielen und man soll Tools vom RAID-Hersteller verwenden!? Da ich keine Systemsicherung habe, klone ich die Festplatte mit Acronis auf eine ext. USB HDD, das läuft gerade und dauert mit 2.0 noch ca. 3 Stunden.
Übrigens ist der Server ein Fujitsu Primergy TX150 S6 und hat noch Vor-Ort-Service. Nach telefonischem Kontakt meinen die, wenn das Testprogramm keinen Fehler bringt sei HW-mäßig alles OK und wenn die kommen und der Fehler liegt beim OS müssen die Kosten selbst übernommen werden.
Die Steckkarten, 1x Intel LAN PCI und einmal der SAS RAID sitzen fest, genauso die Stecker zu den einzelnen Komponenten.
Meine nächste Aktion wäre die FW in die HDDs einzuspielen, aber wie ist mir noch nicht ganz klar bei einem RAID. Kann vielleicht Jemand etwas dazu sagen?
es grüßt
KarlE
ich will hier einmal eine Zwischenmeldung geben:
1.
Ich habe das 2. RAM-Modul in den Slot vom getesteten Modul gesteckt und auch 3 Druchgeänge mit memtest86 gemacht ->kein Fehler gefunden.
2.
Also baute ich beide Module (es ist übrigens das einzigste Pärchen) in Originalposition ein. Nach dem Hochfahren des Servers werden wieder beschädigte Dateien gemeldet. Gedanke: Ist der eine RAM-Slot defekt...?
3.
RAM-Modul mit dem der Fehler nicht aufritt (zumindest die Meldung mit den beschädigten Dateien nicht) in den verdächtigen Slot gesteckt -> Meldungen über beschädigte Dateien kommen immer noch. sfc /scannow bricht bei 28% ab.
4.
Das eine RAM-Modul wieder umgesteckt, so wie keine Meldungen über beschädigte Dateien erschienen sind. Nach Start jedoch wieder Meldung über beschädigte Dateien. Gedanke: Evtl. muß ich zuvor nochmal chekdisk reparieren lassen. Checkdisk laufen lassen und danach sfc. sfc ist durchgelaufen und bringt alles sei OK. Die Meldung mit den beschädigten Dateien kommt aber wieder und checkdisk will nach Neustart immer wieder losackern.
5.
Beide RAM in Originalposition wieder eingebaut. Mit Hersteller Diagnostics CD gebootet und einamal Quick und einmal Full Test laufen lassen ->alles OK
Was mir eingefallen ist: die Festplatten wurden vor einigen Monaten gegen größere ausgetauscht. Nicht vom Hersteller sondern vom "Regal". Sprich, es sind Seagate ST3600057SS mit FW 0008 verbaut. Also nach FW-Update gesucht. Hier habe ich eine 000B gefunden und soll ein Zertifikat-Update sein!? Allerdings wird gewarnt diese auf ein RAID-System einzuspielen und man soll Tools vom RAID-Hersteller verwenden!? Da ich keine Systemsicherung habe, klone ich die Festplatte mit Acronis auf eine ext. USB HDD, das läuft gerade und dauert mit 2.0 noch ca. 3 Stunden.
Übrigens ist der Server ein Fujitsu Primergy TX150 S6 und hat noch Vor-Ort-Service. Nach telefonischem Kontakt meinen die, wenn das Testprogramm keinen Fehler bringt sei HW-mäßig alles OK und wenn die kommen und der Fehler liegt beim OS müssen die Kosten selbst übernommen werden.
Die Steckkarten, 1x Intel LAN PCI und einmal der SAS RAID sitzen fest, genauso die Stecker zu den einzelnen Komponenten.
Meine nächste Aktion wäre die FW in die HDDs einzuspielen, aber wie ist mir noch nicht ganz klar bei einem RAID. Kann vielleicht Jemand etwas dazu sagen?
es grüßt
KarlE
Zitat von @KarlE:
Da ich keine Systemsicherung habe, klone ich die Festplatte mit Acronis auf eine ext.
USB HDD, das läuft gerade und dauert mit 2.0 noch ca. 3 Stunden.
Da ich keine Systemsicherung habe, klone ich die Festplatte mit Acronis auf eine ext.
USB HDD, das läuft gerade und dauert mit 2.0 noch ca. 3 Stunden.
Du hast nicht als erstes mal eine Systemsicherung gemacht? Fahrlässig!
hast Du mal die festplatten geprüft oder zumindest mal die SMARt-Werte angeschaut? Wiederholte fehler im Dateisystem kann genausogut defekte festplattem, defekte, SAS/SATA-kKabel oder defekter Controller (Akku alle?)
heißen.
machst du den chkdsk aus dem laufenden System heraus oder mit einer Live CD (Systemwiederherstellung oder WinPE?)
Min Jung, nimm die Plattn udn prüfe sie erstmal, bevor Du noch mehr kaputtmachst.
lks
PS: Wenn mir solche Fehler (kaputte Dateisysteme) bei kunden untergekommen sind, war's fast immer die Platte und manchmal ein zerschossenes OS.
