Jump to content
Sign in to follow this  
Ihopso

Partition ist plötzlich unformatiert

Recommended Posts

Hallo zusammen,

seit einiger Zeit plagen mich Probleme mit meiner Notebookfestplatte. Auf meiner Datenpartition D: verschwinden immer wieder Dateien, an denen ich gerade gearbeitet habe, und unter C: zeigt Scandisk immer wieder die gleichen Meldungen (nicht verwendete Indexeinträge). Ein exemplarischer Auszug der Logdatei ist unten abgebildet.

 

Das Verückteste ist aber, dass nun schon zum zweiten Mal Windows ohne erkennbaren Grund behauptet hat, D: wäre unformatiert und könne jetzt formatiert werden. Meine Daten waren damit zunächst weg (Backup vorhanden). Einmal passierte dies nach einem Systemneustart und ein anderes Mal beim Wiedererwachen aus dem Ruhezustand.

 

Um dieses Mysterium nun abzurunden bleibt noch anzumerken, dass ich nach Tiefenscans mit Scandisk, PC-Doctor und dem festplatteneigenen Fujitsu-Tool keinerlei Festplattenfehler feststellen konnte. Auch die S.M.A.R.T.-Informationen verzeichneten keine Probleme.

 

Könnte es trotzdem Lesefehler geben, die nur sehr selten auftretten? Oder hat die Festplatte einen anderen Defekt als einen Oberflächenfehler? Könnte das Betriebssystem eine Macke haben und selbständig das NTFS-Dateisystem korrumpieren?

 

Ich bin für jede Idee oder jeden Hinweis sehr dankbar. Vielleicht kennt z.B. jemand noch eine bessere Methode die Festplatte zu untersuchen.

 

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

Dateisystem auf D: wird überprüft.

Die Volumebezeichnung lautet Daten.

Der Attributeintrag vom Typ 0x80 und mit der Instanzkennung 0x3 ist

von 0x3719a5 an für möglicherweise 0x2 Cluster quer verbunden.

Einige Cluster, die vom Attribut vom Typ 0x80 und der Instanzkennung 0x3

in der Datei 0x1038 belegt sind, werden bereits verwendet.

Beschädigter Attributeintrag (128, "") wird

vom Datensatzsegment 4152 gelöscht.

Der Attributeintrag vom Typ 0x80 und mit der Instanzkennung 0x4 ist

von 0x3bab3a an für möglicherweise 0x1 Cluster quer verbunden.

Einige Cluster, die vom Attribut vom Typ 0x80 und der Instanzkennung 0x4

in der Datei 0x6410 belegt sind, werden bereits verwendet.

Beschädigter Attributeintrag (128, "") wird

vom Datensatzsegment 25616 gelöscht.

Die Dateireferenz 0xc000000000864 von Indexeintrag Literatur.tex von Index $I30 mit dem

übergeordneten Element 0x2a33 ist nicht die gleiche wie 0xa000000000864.

Indexeintrag Literatur.tex in Index $I30 der Datei 10803 wird gelöscht.

Die Dateireferenz 0xc000000000864 von Indexeintrag LITERA~1.TEX von Index $I30 mit dem

übergeordneten Element 0x2a33 ist nicht die gleiche wie 0xa000000000864.

Indexeintrag LITERA~1.TEX in Index $I30 der Datei 10803 wird gelöscht.

Der Indexeintrag SweptVolumes.cpp von Index $I30 in der Datei 0x63b9 verweist auf die nicht verwendete Datei 0x1042.

Indexeintrag SweptVolumes.cpp in Index $I30 der Datei 25529 wird gelöscht.

Der Indexeintrag SWEPTV~1.CPP von Index $I30 in der Datei 0x63b9 verweist auf die nicht verwendete Datei 0x1042.

Indexeintrag SWEPTV~1.CPP in Index $I30 der Datei 25529 wird gelöscht.

Kleinere Inkonsistenzen auf dem Laufwerk werden aufgeräumt.

CHKDSK stellt verlorene Dateien wieder her.

Verwaiste Datei LITERA~1.TEX (2148) wird in Verzeichnisdatei 10803 wiederhergestellt.

Verwaiste Datei Literatur.tex (2148) wird in Verzeichnisdatei 10803 wiederhergestellt.

Verwaiste Datei SWEPTV~1.CPP (4170) wird in Verzeichnisdatei 25529 wiederhergestellt.

Verwaiste Datei SweptVolumes.cpp (4170) wird in Verzeichnisdatei 25529 wiederhergestellt.

2 nicht verwendete Indexeinträge aus Index $SII der Datei 0x9 werden aufgeräumt.

2 nicht verwendete Indexeinträge aus Index $SDH der Datei 0x9 werden aufgeräumt.

2 nicht verwendete Sicherheitsbeschreibungen werden aufgeräumt.

Attribut DATA wird in Datei 4152 eingefügt.

Attribut DATA wird in Datei 25616 eingefügt.

CHKDSK hat freien Speicher gefunden, der in der Volumebitmap als

zugeordnet gekennzeichnet ist.

Windows hat Probleme im Dateisystem behoben.

Share this post


Link to post

Meinen Speicher habe ich des Öfteren schon getestet. Dieser sollte soweit fehlerfrei sein. Speicherprobleme hätten sich sicherlich an anderer Stelle wesentlich deutlicher bemerkbar gemacht. Die verschiedenen Fesplattenscans waren jeweils mit der stärksten Überprüfung eingestellt. Die Fesplatte ist angeblich zu 100% in Ordnung (0 Byte in beschädigten Sektoren, etc.).

 

Das Problem, dass die Festplatte D: als unformatiert deklariert wird, tritt entweder beim Systemstart bzw. Aufwachen aus dem Ruhezustand oder vielleicht beim Herunterfahren bzw. Ruhezustand einleiten. Irgendwann in einer dieser Phasen wird das NTFS-Dateisystem von D: ausgelöscht.

Share this post


Link to post
Die Fesplatte ist angeblich zu 100% in Ordnung

Per ChkDsk??? ;)

Vergiss das - Tool vom Hersteller (besonders bei modernen HD's mit SMART)

oder du spielst Roulette. :-P

Share this post


Link to post

Hallo,

 

oder du spielst Roulette. :-P

 

selbst die Tools vom Hersteller ähneln einem Roulettspiel :D

Sie sind aber die sicherste Variante eine HDD zu testen.

 

MfG Schotte

Share this post


Link to post

Bis jetzt hat sich zwar meine Partition nicht mehr verabschiedet, dafür bekomme ich immer wieder seltsame Meldungen von Chkdisk (siehe unten).

 

Kann mir jemand sagen, was Chkdisk hier fleißig am korrigieren ist?

 

Kennt jemand ein Tool, mit dem man eine Festplatte zuverlässig auf korrekte Schreib-/Lesefähigkeit prüfen kann?

 

Ich bin schon fast am verzweifeln und für jede Hilfe dankbar.

 

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

Dateisystem auf D: wird überprüft.

Der Typ des Dateisystems ist NTFS.

Die Volumebezeichnung lautet Daten.

 

Eine Datenträgerüberprüfung ist geplant.

Die Datenträgerüberprüfung wird jetzt ausgeführt.

Kleinere Inkonsistenzen auf dem Laufwerk werden aufgeräumt.

Ein Indexeintrag mit der Kennung 267 wird aus dem Index $SII der Datei 9 gelöscht.

Ein Indexeintrag mit der Kennung 268 wird aus dem Index $SII der Datei 9 gelöscht.

Ein Indexeintrag mit der Kennung 269 wird aus dem Index $SII der Datei 9 gelöscht.

Ein Indexeintrag mit der Kennung 269 wird aus dem Index $SDH der Datei 9 gelöscht.

Ein Indexeintrag mit der Kennung 267 wird aus dem Index $SDH der Datei 9 gelöscht.

Ein Indexeintrag mit der Kennung 268 wird aus dem Index $SDH der Datei 9 gelöscht.

Ungültige Sicherheitskennung für Datei 38966 wird durch standardmäßige Sicherheitskennung ersetzt.

Ungültige Sicherheitskennung für Datei 38967 wird durch standardmäßige Sicherheitskennung ersetzt.

[...]

Ungültige Sicherheitskennung für Datei 39120 wird durch standardmäßige Sicherheitskennung ersetzt.

Ungültige Sicherheitskennung für Datei 39121 wird durch standardmäßige

Sicherheitskennung ersetzt.

[... der Logeintrag bricht hier ab]

Share this post


Link to post

Hallo,

drei Möglichkeiten,

 

-Chkdsk /r -> macht alle 5Phasen von Chkdsk

-Diag vom Hersteller -> stellt Fehler fest (oder auch nicht :rolleyes: )

-HDD auf neue HDD clonen -> du gehst auf Nummer sicher

 

MfG Schotte

Share this post


Link to post

Kann Er die HD in einem anderen Rechner testen? Ist das Gerät mal gefallen?

 

Ein Privarkunde kam mal mit seinem plötzlich defekten NB an. Lesefehler Spur 0. Seite Frau hatte das Ding wohl versehendlich fallen gelassen auf dem Boden oder den Tisch. Am Tag vorher hatten die beiden Krach.

Share this post


Link to post
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte überlege Dir, ob es nicht sinnvoller ist ein neues Thema zu erstellen.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  

Werbepartner:



×
×
  • Create New...