7
Chkdsk Ergebnisse nicht zu finden. In Ereignisanzeige-Anwendung auch nicht
Hallo liebe Administrator Gemeinde,
es geht um Windows Server 2003 SP2,
RAID1 (500GB+500GB) SATA,
2 Partitionen C: (30GB mit Windows) und D: (450GB mit Datenbank und anderen Kramm)
Kiste von DELL, 19'', 6 Jahre Alt
Eigenschaften von Laufwerk D: -> Extras -> Fehlerüberprüfung -> Jetzt prüfen -> Alle Checkboxen anklicken -> Starten.
Nach Rechner Neustart Chkdsk prüft ordentlich die Festplatte D: durch.
Die Ergebnisse sind nirgendwo danach zu finden:
Die gleiche Überprüfung von Laufwerk C: schreibt seine Ergebnisse ordentlich in Ereignisanzeige\Anwendung\wininit (!!!)
Die Überprüfung von D: dauert ca. 2,5 Stunden
Ob es tatsächlich bis zu Ende läuft, kann ich nicht sagen, da diese 2 Sekunden mit Ergebnisse konnte ich nicht fangen.
Hat jemand eine Idee
a) was es seien kann?
b) und wo sind die Ergebnisse?
Lieben Dank
es geht um Windows Server 2003 SP2,
RAID1 (500GB+500GB) SATA,
2 Partitionen C: (30GB mit Windows) und D: (450GB mit Datenbank und anderen Kramm)
Kiste von DELL, 19'', 6 Jahre Alt
Eigenschaften von Laufwerk D: -> Extras -> Fehlerüberprüfung -> Jetzt prüfen -> Alle Checkboxen anklicken -> Starten.
Nach Rechner Neustart Chkdsk prüft ordentlich die Festplatte D: durch.
Die Ergebnisse sind nirgendwo danach zu finden:
- in Ereignisanzeige\Anwendung - nicht
- Datei C:\checkdisk.log D:\checkdisk.log gibt es auch nicht
Die gleiche Überprüfung von Laufwerk C: schreibt seine Ergebnisse ordentlich in Ereignisanzeige\Anwendung\wininit (!!!)
Die Überprüfung von D: dauert ca. 2,5 Stunden
Ob es tatsächlich bis zu Ende läuft, kann ich nicht sagen, da diese 2 Sekunden mit Ergebnisse konnte ich nicht fangen.
Hat jemand eine Idee
a) was es seien kann?
b) und wo sind die Ergebnisse?
Lieben Dank
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: 163095
Url: https://administrator.de/contentid/163095
Ausgedruckt am: 26.11.2024 um 04:11 Uhr
7 Kommentare
Neuester Kommentar
Hallo @aviette,
Du müsstest in deinen Anwendungslogs (
Gruß
Snow
Du müsstest in deinen Anwendungslogs (
eventvwr.msc) ein winlogon-Event haben, welches zu der Zeit erstellt wurde, nachdem der chkdsk-Vorgang abgeschlossen war. In diesem sollten alle benötigten Informationen stehen.Gruß
Snow
Hallo Snowman25
du hast Recht: inter "winlogon" sind die Ergebnisse von "chkdsk C:" zu finden.
Aber die Ergebnisse von "chkdsk D:" sind auch nicht da. "winlogon" Eintrag fehlt.
Ich habe alle Ereignisse unter Katalog "System" und "Anwendung" innerhalb von Zeit des Rechnerstart überprüft. Kein Erfolg.
Es bleibt wahrscheilich die Festplatte auszubauen, an einen PC anschliesse und auf Fehler überprüffen lassen.
Aber ich habe hier viel Bedenken:
es geht um keinen echten RAID1 sondern einen gestrickten Software RAID1 with BIOS Config von DELL (PowerEdge SC-1425),
wo erste Platte ist Master und die Zweite ist Slave.
Z.B. Rechner ohne Masterplatte startet nicht.
Und wenn ich dort separte Fehlerüberpüfung lasse dann habe ich später Kopfschmerzen und ca. 5 verlorene Stunden mit Syncronisierung.
du hast Recht: inter "winlogon" sind die Ergebnisse von "chkdsk C:" zu finden.
Aber die Ergebnisse von "chkdsk D:" sind auch nicht da. "winlogon" Eintrag fehlt.
Ich habe alle Ereignisse unter Katalog "System" und "Anwendung" innerhalb von Zeit des Rechnerstart überprüft. Kein Erfolg.
Es bleibt wahrscheilich die Festplatte auszubauen, an einen PC anschliesse und auf Fehler überprüffen lassen.
Aber ich habe hier viel Bedenken:
es geht um keinen echten RAID1 sondern einen gestrickten Software RAID1 with BIOS Config von DELL (PowerEdge SC-1425),
wo erste Platte ist Master und die Zweite ist Slave.
Z.B. Rechner ohne Masterplatte startet nicht.
Und wenn ich dort separte Fehlerüberpüfung lasse dann habe ich später Kopfschmerzen und ca. 5 verlorene Stunden mit Syncronisierung.
Wie wäre is mit einer online-Defragmentierung? Immerhin ist die Platte ja nicht die Bootplatte.
Einfach in der Konsole folgendes eingeben:
Unter Umständen musst du erst die Auslagerungsdatei auf
Hierzu öffnest du
Da stells du den vArbeitsspeicher für
Danach musst du dein System neu starten. Du solltest die Festplatte jetzt über die Konsole per
Nach dem erfolgreichen
Gruß
Snow
Einfach in der Konsole folgendes eingeben:
chkdsk D: /F /V /R /XD: deaktivieren.Hierzu öffnest du
Eigenschaften von System(Win-Taste+Pause)- Reiter "
Erweitert" - Systemleistung
Einstellungen - Reiter "
Erweitert" - Virtueller Arbeitsspeicher
Ändern.
Da stells du den vArbeitsspeicher für
D: auf "Keine Auslagerungsdatei" (mit Festlegen bestätigen) und setzt den von C: auf automatisch oder die gleichen Werte wie vorher von D:.Danach musst du dein System neu starten. Du solltest die Festplatte jetzt über die Konsole per
chkdsk prüfen können.Nach dem erfolgreichen
chkdsk kannst du die Einstellungen wieder rückgängig machen.Gruß
Snow
Hallo Snowman25
danke für Turbotipps.
Meinen D: hat keine Auslagerungsdatei aber hat MSSQL DB. Ich versuche die Zeit zu finden um das SQL Dienst zu stoppen und dann müsste(?) Laufwerk für online Überprüfung frei sein.
Außerdem ich habe es gerade probiert:
1) mit "vrfydsk d: /v" - vrfydsk.exe stürtzt mit Exception ab.
2) mit "chkdsk d: /v" wärend Betribsystem läuft.
Hier sieht man schon die mögliche Problematikquellen:
a) Von Schritt zu Schritt hat chkdsk das Prozentindikator nicht geändert(!)
b) ab und zu erscheinen die 13 bis 14 -Stellige(!) Nummern wie "10305696305696"
Unten sind die Ergebnisse:
Der Typ des Dateisystems ist NTFS.
Die Volumebezeichnung lautet DATA.
WARNUNG! Der Parameter F wurde nicht angegeben.
CHKDSK wird im schreibgeschtzten Modus ausgefhrt.
CHKDSK berprft Dateien (Phase 1 von 3)...
0 Prozent abgeschlossen. (0 von 305696 Datens„tzen verarbeitet)
0 Prozent abgeschlossen. (5000 von 305696 Datens„tzen verarbeitet)
...
9 Prozent abgeschlossen. (300127 von 305696 Datens„tzen verarbeitet)
9 Prozent abgeschlossen. (305127 von 305696 Datens„tzen verarbeitet)
10305696305696
305696 Datens„tze verarbeitet. Dateiberprfung beendet.
10 Prozent abgeschlossen. (1 von 4561 groáen Datens„tzen verarbeitet)
1045614561
4561 groáe Datens„tze verarbeitet. 1000
0 ungltige Datens„tze verarbeitet. 1000
0 E/A-Datens„tze verarbeitet. 1000
0 Analysedatens„tze verarbeitet.
CHKDSK berprft Indizes (Phase 2 von 3)...
10 Prozent abgeschlossen. (511 von 883640 Indexeintr„gen verarbeitet)
10 Prozent abgeschlossen. (1023 von 883640 Indexeintr„gen verarbeitet)
...
92 Prozent abgeschlossen. (882697 von 883640 Indexeintr„gen verarbeitet)
92 Prozent abgeschlossen. (883197 von 883640 Indexeintr„gen verarbeitet)
92883640883640
883640 Indexeintr„ge verarbeitet. Indexberprfung beendet.
Es wurden kleinere Inkonsistenzen auf dem Laufwerk festgestellt. Es handelt sich dabei nicht um eine Besch„digung.
9255
5 nicht indizierte Dateien verarbeitet.
CHKDSK berprft Sicherheitsbeschreibungen (Phase 3 von 3)...
92 Prozent abgeschlossen. (5000 von 305696 Beschreibungen verarbeitet)
92 Prozent abgeschlossen. (10000 von 305696 Beschreibungen verarbeitet)
...
99 Prozent abgeschlossen. (296313 von 305696 Beschreibungen verarbeitet)
99 Prozent abgeschlossen. (301313 von 305696 Beschreibungen verarbeitet)
99305696305696
305696 Sicherheitsbeschreibungen verarbeitet. šberprfung der Sicherheitsbeschreibungen beendet.
1001348713487
13487 Datendateien verarbeitet.
457418713 KB Speicherplatz auf dem Datentr„ger insgesamt
388115040 KB in 143703 Dateien
71028 KB in 13489 Indizes
37904 KB in fehlerhaften Sektoren
386145 KB vom System benutzt
65536 KB von der Protokolldatei belegt
68808596 KB auf dem Datentr„ger verfgbar
4096 Bytes in jeder Zuordnungseinheit
114354678 Zuordnungseinheiten auf dem Datentr„ger insgesamt
17202149 Zuordnungseinheiten auf dem Datentr„ger verfgbar
danke für Turbotipps.
Meinen D: hat keine Auslagerungsdatei aber hat MSSQL DB. Ich versuche die Zeit zu finden um das SQL Dienst zu stoppen und dann müsste(?) Laufwerk für online Überprüfung frei sein.
Außerdem ich habe es gerade probiert:
1) mit "vrfydsk d: /v" - vrfydsk.exe stürtzt mit Exception ab.
2) mit "chkdsk d: /v" wärend Betribsystem läuft.
Hier sieht man schon die mögliche Problematikquellen:
a) Von Schritt zu Schritt hat chkdsk das Prozentindikator nicht geändert(!)
b) ab und zu erscheinen die 13 bis 14 -Stellige(!) Nummern wie "10305696305696"
Unten sind die Ergebnisse:
Der Typ des Dateisystems ist NTFS.
Die Volumebezeichnung lautet DATA.
WARNUNG! Der Parameter F wurde nicht angegeben.
CHKDSK wird im schreibgeschtzten Modus ausgefhrt.
CHKDSK berprft Dateien (Phase 1 von 3)...
0 Prozent abgeschlossen. (0 von 305696 Datens„tzen verarbeitet)
0 Prozent abgeschlossen. (5000 von 305696 Datens„tzen verarbeitet)
...
9 Prozent abgeschlossen. (300127 von 305696 Datens„tzen verarbeitet)
9 Prozent abgeschlossen. (305127 von 305696 Datens„tzen verarbeitet)
10305696305696
305696 Datens„tze verarbeitet. Dateiberprfung beendet.
10 Prozent abgeschlossen. (1 von 4561 groáen Datens„tzen verarbeitet)
1045614561
4561 groáe Datens„tze verarbeitet. 1000
0 ungltige Datens„tze verarbeitet. 1000
0 E/A-Datens„tze verarbeitet. 1000
0 Analysedatens„tze verarbeitet.
CHKDSK berprft Indizes (Phase 2 von 3)...
10 Prozent abgeschlossen. (511 von 883640 Indexeintr„gen verarbeitet)
10 Prozent abgeschlossen. (1023 von 883640 Indexeintr„gen verarbeitet)
...
92 Prozent abgeschlossen. (882697 von 883640 Indexeintr„gen verarbeitet)
92 Prozent abgeschlossen. (883197 von 883640 Indexeintr„gen verarbeitet)
92883640883640
883640 Indexeintr„ge verarbeitet. Indexberprfung beendet.
Es wurden kleinere Inkonsistenzen auf dem Laufwerk festgestellt. Es handelt sich dabei nicht um eine Besch„digung.
9255
5 nicht indizierte Dateien verarbeitet.
CHKDSK berprft Sicherheitsbeschreibungen (Phase 3 von 3)...
92 Prozent abgeschlossen. (5000 von 305696 Beschreibungen verarbeitet)
92 Prozent abgeschlossen. (10000 von 305696 Beschreibungen verarbeitet)
...
99 Prozent abgeschlossen. (296313 von 305696 Beschreibungen verarbeitet)
99 Prozent abgeschlossen. (301313 von 305696 Beschreibungen verarbeitet)
99305696305696
305696 Sicherheitsbeschreibungen verarbeitet. šberprfung der Sicherheitsbeschreibungen beendet.
1001348713487
13487 Datendateien verarbeitet.
457418713 KB Speicherplatz auf dem Datentr„ger insgesamt
388115040 KB in 143703 Dateien
71028 KB in 13489 Indizes
37904 KB in fehlerhaften Sektoren
386145 KB vom System benutzt
65536 KB von der Protokolldatei belegt
68808596 KB auf dem Datentr„ger verfgbar
4096 Bytes in jeder Zuordnungseinheit
114354678 Zuordnungseinheiten auf dem Datentr„ger insgesamt
17202149 Zuordnungseinheiten auf dem Datentr„ger verfgbar
nochmals Hallo @aviette,
Mach dir um die Zahlen keinen Kopf. Das kommt durch die umgeleitete Ausgabe in eine Datei.
Was mich hier vorallem stört ist das:
Du solltest möglichst bald
Nach Möglichkeit sollte die Platte danach bald getauscht werden.
Gruß
Snow
Mach dir um die Zahlen keinen Kopf. Das kommt durch die umgeleitete Ausgabe in eine Datei.
Was mich hier vorallem stört ist das:
37904 KB in fehlerhaften Sektoren
Das sind 37 MB in kaputten Sektoren(!)Du solltest möglichst bald
chkdsk D: /V /F /R ausführen. Dann werden die Fehlerhaften Sektoren mit dem bad_sector-Flag gekennzeichnet und der Inhalt auf frische, funktionstüchtige Sektoren geschrieben.Nach Möglichkeit sollte die Platte danach bald getauscht werden.
Gruß
Snow
Hallo Snowman25
ich dachte sind das die schon als "Bad" markiert und deswegen hier als "fehlerhaften Sektoren" angezeigt.
37904 KB in fehlerhaften Sektoren
ich dachte sind das die schon als "Bad" markiert und deswegen hier als "fehlerhaften Sektoren" angezeigt.
...
Das Problem wird ja längst gelöst sein. Ich hatte sogar mal selbes Problem und ChkDsk machte es nur noch schlimmer. Dies passierte zwar schon vor einigerr Zeit.
Inzwischen habe ich einen Post gelesen, welcher sich auf ChkDsk und Raid bezieht. Darin heisst es, dass man bei Raids mit ChkDsk vorsichtig sein sollte. Sobald eine Festplatte angeschlagen ist, kann u.U. ChkDsk u.U. auf eine einzelne Festplatte zugreifen und dort erheblichen Schaden hinterlassen. (Ob sich das auch auf Raid1 bezieht, weiss ich jetzt nicht.
Dies nur als Tip zur Vorsicht. Wobei ich ja schon annehme, dass wichtige Daten ja bereits vorgängig gesichert wurden.
Ich dachte bislang auch nicht, dass ChkDsk sogar destruktiv sein kann, aber ich hab's eben gelesen. Ich habe vor Kurzem Probleme mit meinem Raid0 gehabt. Und da auch ChkDsk im Spiel war und eine defekte HD, dachte ich, ich geb des hier weiter.
Zitat:
Um Missverständnisse zu vermeiden, hier ein Nachtrag zu unsere Meldung: Nein, es ist kein Unfug, bei einem RAID chkdsk auszuschalten. Bei einem 100% einwandfrei funktionierenden RAID sieht chkdsk tatsächlich keine einzelnen Platten und kann auch keinen Schaden anrichten. Ist aber eine Festplatte ausgefallen oder wird vom Raidkontroller als korrupt gemeldet, z.B. auf Grund zu vieler defekter Sektoren, wird es durch den BootExecute-Eintrag autocheck* richtig gefährlich für die Daten. In einem beschädigten RAID erkennt chkdsk eine oder mehrere Einzelplatten und versucht ein Dateisystem zu rekonstruieren, im besten Fall nur auf der ersten Platte des RAIDs, manchmal auch auf mehreren. Das Ergebnis sind viele korrupte Files und ein RAID das so weit zerstört ist, dass es auch nach dem Austausch der ursprünglich beschädigten Platte nicht mehr wiederaufgebaut werden kann. Die auf den Platten verteilten Daten müssen mit ziemlichem Aufwand rekonstruiert werden. Ein Problem, das vielleicht mit dem Tausch einer Platte und dem Rebuild des RAIDs hätte gelöst werden können, wird auf diese Weise zu einem anspruchsvollen Datenrettungsjob.
Conrad Heinicke
CBL Datenrettung GmbH
Zitat Ende...
Es gibt ja auch nicht umsonst Raidfestplatten, bei welchen gewisse Fehlerkorrekturen seitens der Festplatte selbst deaktiviert sind, weil diese ansonsten mit der Fehlerkorrektur des Raidkontrollers konkurrieren können. Heute machen ja viele EigenPC Bauer ein Raid, verwenden aber herkömmliche Festplatten dazu. Es muss nicht zu einem Fehler kommen, es kann aber. "Tler", (Time limited Error Recovery), heisst das bei Western Digital.
Hier mehr dazu > http://wdc.custhelp.com/app/answers/detail/a_id/1397/session/L3RpbWUvMT ...
Und hier zum Tler > http://wdc.custhelp.com/app/answers/detail/a_id/1478/session/L3RpbWUvMT ...
PS. Nebenbei... Das ist doch gleichwohl ein Hardware Raid. Auch wenn der Prozessor seine Arbeit leisten muss. Ich hab auch mal den Ausdruck Firmwareraid gelesen. Was ist nun richtig. Oder sind nur Raids auf Raidcontroller mit eigenem Prozessor und Arbeitsspeicher Hardwareraids?
...
Das Problem wird ja längst gelöst sein. Ich hatte sogar mal selbes Problem und ChkDsk machte es nur noch schlimmer. Dies passierte zwar schon vor einigerr Zeit.
Inzwischen habe ich einen Post gelesen, welcher sich auf ChkDsk und Raid bezieht. Darin heisst es, dass man bei Raids mit ChkDsk vorsichtig sein sollte. Sobald eine Festplatte angeschlagen ist, kann u.U. ChkDsk u.U. auf eine einzelne Festplatte zugreifen und dort erheblichen Schaden hinterlassen. (Ob sich das auch auf Raid1 bezieht, weiss ich jetzt nicht.
Dies nur als Tip zur Vorsicht. Wobei ich ja schon annehme, dass wichtige Daten ja bereits vorgängig gesichert wurden.
Ich dachte bislang auch nicht, dass ChkDsk sogar destruktiv sein kann, aber ich hab's eben gelesen. Ich habe vor Kurzem Probleme mit meinem Raid0 gehabt. Und da auch ChkDsk im Spiel war und eine defekte HD, dachte ich, ich geb des hier weiter.
Zitat:
Um Missverständnisse zu vermeiden, hier ein Nachtrag zu unsere Meldung: Nein, es ist kein Unfug, bei einem RAID chkdsk auszuschalten. Bei einem 100% einwandfrei funktionierenden RAID sieht chkdsk tatsächlich keine einzelnen Platten und kann auch keinen Schaden anrichten. Ist aber eine Festplatte ausgefallen oder wird vom Raidkontroller als korrupt gemeldet, z.B. auf Grund zu vieler defekter Sektoren, wird es durch den BootExecute-Eintrag autocheck* richtig gefährlich für die Daten. In einem beschädigten RAID erkennt chkdsk eine oder mehrere Einzelplatten und versucht ein Dateisystem zu rekonstruieren, im besten Fall nur auf der ersten Platte des RAIDs, manchmal auch auf mehreren. Das Ergebnis sind viele korrupte Files und ein RAID das so weit zerstört ist, dass es auch nach dem Austausch der ursprünglich beschädigten Platte nicht mehr wiederaufgebaut werden kann. Die auf den Platten verteilten Daten müssen mit ziemlichem Aufwand rekonstruiert werden. Ein Problem, das vielleicht mit dem Tausch einer Platte und dem Rebuild des RAIDs hätte gelöst werden können, wird auf diese Weise zu einem anspruchsvollen Datenrettungsjob.
Conrad Heinicke
CBL Datenrettung GmbH
Zitat Ende...
Es gibt ja auch nicht umsonst Raidfestplatten, bei welchen gewisse Fehlerkorrekturen seitens der Festplatte selbst deaktiviert sind, weil diese ansonsten mit der Fehlerkorrektur des Raidkontrollers konkurrieren können. Heute machen ja viele EigenPC Bauer ein Raid, verwenden aber herkömmliche Festplatten dazu. Es muss nicht zu einem Fehler kommen, es kann aber. "Tler", (Time limited Error Recovery), heisst das bei Western Digital.
Hier mehr dazu > http://wdc.custhelp.com/app/answers/detail/a_id/1397/session/L3RpbWUvMT ...
Und hier zum Tler > http://wdc.custhelp.com/app/answers/detail/a_id/1478/session/L3RpbWUvMT ...
PS. Nebenbei... Das ist doch gleichwohl ein Hardware Raid. Auch wenn der Prozessor seine Arbeit leisten muss. Ich hab auch mal den Ausdruck Firmwareraid gelesen. Was ist nun richtig. Oder sind nur Raids auf Raidcontroller mit eigenem Prozessor und Arbeitsspeicher Hardwareraids?
...
