Fehler im Volumebitmap bzw. im MFT-Bitmap

[Sendre]

Hallo,
ich versuche jetzt seit längerer Zeit eine Lösung zu finden allerdings ohne Erfolg.

"Chkdsk c:" findet entweder Fehler im Volumebitmap oder freien Speicher der in der MFT-Bitmap als zugeornet gekennzeichnet ist.
Eine Korrektur mit "chkdsk c: /f" gelingt nicht.

Wenn beim Hochfahren des Rechners chkdsk ausgefürht wurde, erscheinen anschließend 0 Fehler, der Fehler bei "chkdsk c:" bleibt weiter bestehen. Der PC macht ansonsten absolut keine Probleme.

Ich habe versucht mit Testdisk 6.7 der Sache auf den Grund zu gehen, weiß aber nicht so recht ob es damit möglich ist und was ich genau tun soll.

"chkntfs c:" ergibt "c: ist nicht fehlerhaft"

Soll ich das Ganze als Pseudofehler abhaken?

Danke, Sendre

 

[Mueli]

Hattest Du eine Konvertierung von Fat32 nach NTFS gemacht?
Wurde das chkdsk auch mal aus der Recovery-Console heraus probiert?
Chkdsk c: /p (evtl. zus. /r)
Du solltest Du vorsorglich ein Image der Partition erstellen, dann kannst Du wieder auf den Stand zurück.
Über eine PE-CD (BartsPE) könnte man die Partition auch per xcopy auf ein anderes Laufwerk kopieren, C: dann formatieren und per xcopy zurückspielen:
xcopy quelle ziel /k/r/e/i/s/c/h/o (/o für die Rechte)
Ich bin mir allerdings nicht mehr ganz sicher, ob ich auch noch /x mit angefügt habe.

Testdisk wird Dir sicher nicht helfen, da Du einen Fehler im dateisystem bzw. in der MFT hast.

 

[Sendre]

Hallo,

erst einmal vielen Dank für die Antwort.

Hattest Du eine Konvertierung von Fat32 nach NTFS gemacht?

nein war von Anfang an NTFS

Wurde das chkdsk auch mal aus der Recovery-Console heraus probiert?

nein, wie erreicht man diese?
Booten von der XP-CD? Ich habe so etwas noch nie gemacht, habe die SP2 CD.

Chkdsk c: /p (evtl. zus. /r)

chkdsk c: /r aus einer DOS-Box hatte ja nichts gebracht.

Du solltest Du vorsorglich ein Image der Partition erstellen, dann kannst Du wieder auf den Stand zurück.

klar, solche Dinge sind trotzdem aufwendig, weil der Rechner normalerweise 24/7 läuft und nur am Wochenende größere Experimente möglich sind.

Über eine PE-CD (BartsPE) könnte man die Partition auch per xcopy auf ein anderes Laufwerk kopieren, C: dann formatieren und per xcopy zurückspielen:
xcopy quelle ziel /k/r/e/i/s/c/h/o (/o für die Rechte)
Ich bin mir allerdings nicht mehr ganz sicher, ob ich auch noch /x mit angefügt habe.

BartsPE-BootCD habe ich sogar da.
Und da bekomme ich wohl auch die normalerweise gesperrten Windowsdateien wohl rüber.

Testdisk wird Dir sicher nicht helfen, da Du einen Fehler im dateisystem bzw. in der MFT hast.

dachte da wäre was möglich, da die Rede von Speicherzuordnung war.


Fazit:

a) Recovery-Console oder b) BartsPE

für a bitte noch 2-3 Hinweise (s. oben)
Danke. Sendre

 

[Mueli]

Die Recovery-Console erreicht man über unten stehendes Menü nach Boot vom Installationsmedium:

/r ist für evtl. vorhandene def. Sektoren (spared diese dann)
/p ist eine komplette Überprüfung des Dateisystems
Dein Problem ist allerdings ein in vielen Fällen sehr hartnäckiger Fehler im Dateisystem. Das chkdsk aus der RC ist eine andere Version, in einer Dos-Box hättest Du /f mit anfügen sollen, denn nur dann werden die Fehler im Dateisystem beseitigt.

 

[Fiona]

Testdisk mounted Laufwerke wie Linux und zeigt öfters noch Daten an, die Windows nicht mehr anzeigt.
Wenn dein Dateisystem NTFS ist, kannst du auch die Daten auf ein anders Laufwerk kopieren.
Dazu kannst du auch die Testdisk Boot-CD nehmen.
https://www.computerbase.de/downloads/systemtools/festplatten/testdisk/
Bestätige einfach mit Enter bis Analyse und Proceed durch.
Wenn deine Partition dann angezeigt wird (kann auch eine Suche starten, dann hinterher) drücke einfach p ob deine Daten oder eine Fehlermeldung angezeigt wird.
Wenn der Partitionssektor (Bootsektor) beschädigt ist, bestätige nach Proceed weiter mit Enter bis du unten Search! siehst lasse es laufen und schaue ob die dann gefunden wird.
Markiere die auch und drücke p ob deine Daten oder eine Fehlermeldung angezeigt wird.
Unter Dos kannst du nur Daten auf eine FAT-Partition kopieren.
Dateigrößenlimit unter FAT ist 4 GB.
Kopiere daher keine größeren Dateien, da es auch das Dateisystem beschädigen kann.

Chkdsk-Parameter wären in der Wiederherstellungskonsole;
C:\>chkdsk Laufwerk: /p /r
Der Pararmeter /r beinhaltet schon automatisch /f und ist gründlicher.

Viele Grüße

Fiona

 

[Mueli]

Gemäß Technet macht /p eine gründliche Suche nach Fehlern und zeigt sie an und /r beinhaltet (Implies) /p und beseitigt sie dann auch inkl. notwendiger Reallocation physikalisch def. Sektoren. Nötig wäre dann in der RC lediglich chkdsk <LW> /r. Ob /p jetzt identisch zu /f ist, kann man dem Techneteintrag nicht entnehmen.

 

[Sendre]

@ Mueli & Fiona
vielen Dank für die wertvollen Tipps, bin jetzt erstmal versorgt und melde mich sobald ich die entsprechenden Reparaturversuche unternommen habe.
Ist jetzt erst einmal nicht wichtig, interessant wäre schon, was/warum da was kaputt gegangen ist. Es handelt sich ja um 2 PC's mit identischen Merkmalen, die aber ansonsten im 24/7-Betrieb seit langer Zeit klaglos ihren Dienst tun.
Sendre

 

[Mueli]

Auch wenn das Problem jetzt keine Symptome zeigt, kann der Fehler 'tödlich' für ein System sein, denn es stimmt der 'Belegungsplan' für freie und belegte Sektoren nicht, weil u.U. vermeintlich freie Sektoren und somit Daten auch überschrieben werden könnten.

 

[Sendre]

kann der Fehler 'tödlich' für ein System sein

ich habe aktuelle Images und hoffe, daß ich es mit euren Hinweisen bald geregelt bekomme

 

[Sendre]

Hallo,
so ging es nun weiter:

erst einmal habe ich nach x-Jahren die Bekanntschaft mit der R-Konsole gemacht, man lernt bekanntlich ja nie aus.

TestDiscBootCD
ich bekomme keine Fehler alles scheint ok zu sein, mit "p" bekomme ich meine Daten angezeigt

RC:
chkdsk c: /p bringt Fehler
chkdsk c: / p /r läuft lange und repariert die Fehler

Anschließende Überprüfung "chkdsk c: /p" keine Fehler

Wenn ich nun in Windows "chkdsk c:" eingebe dann erhalte ich sofort wieder den bekannten Fehler > siehe Anhang

Die RC bringt mit "p" ebenfalls wieder Fehler, es läßt sich anschließend reparieren (Kontrolle mit /p ohne Fehler und dann in Windows wieder von vorne.

Für mich sieht es so aus, daß Windows irgendetwas "zerschießt" und dann selber nicht mehr damit klarkommt.

Möglich wäre auch ein falscher Umgang mit versteckten Partitionen.
Auf C:\ ist eine versteckte Recovery-Partition. Wenn ich in Acronis DiskDirektor die Clustergröße anschaue, dann sehe ich daß einiges dort ungenutzt zu sein scheint.

Aber hat das tatsächlich mit dem Volumebitmap-Fehler zu tun.

Könnte evtl. sein, daß in der versteckten Partition Fehler enthalten sind, chkdsk aber nicht richtig rankommt. Eine Möglichkeit ist die Recovery-Partition zu löschen, Recovery-CDs sind gemacht. Auf ein anderes Laufwerk des Notebooks läßt sich das jetzt ohne weiteres aus Platzmangel nicht verschieben, damit C: nur die normale NTFS-Partition enthält.


Wie läßt sich eine DVD (bootbar) so auf Festplatte sichern, daß im Notfall von der Sicherung wieder eine bootbare DVD gebrannt werden kann. Muß etwas berücksichtigt werden? Nero Reloaded liegt vor.
Auf jeden Fall ließ sich mit NERO die DVD schon einmal auf Festplatte sichern und sämtliche Dateien/Verzeichnisse scheinen da zu sein.

Eine BootCD konnte ich aber damit leider nicht wieder erstellen.
Evtl. geht das aber mit TrueImage von Aconis, werde es später noch probieren.

Sendre

 

[Mueli]

'C' oder besser die erste Partition ist bei Dir eine hidden Partition, damit wird das zweite Volume zu C: in Gestalt der zweiten Partition auf dem Laufwerk. Würde man bei dem ersten Volume den Hidden-Status aufheben wird es zu C: und das jetzige C: zu D: usw., dieser Mechniamus wurde früher z.B. beim OS/2 Bootmanager genutzt um mehre Installationen auf C. zu bringen und dann zum Bootzeitpunkt zu ändern.

Chkdsk kann u.U. nicht alle Fehler beheben (hatte ich glaube ich schon mal geschrieben), was bei Dir offenbar der Fall ist oder es gehen immer mehr Sektoren über den Jordan (kann man z.B. mit den Smartmontools auslesen).
Chkdsk wird immer nur bei den laufwerken durchgeführt, bei denen das Dirty-Bit gesetzt ist.
Das Dirty Flag kann man mit dem Kommandizeilentool fsutil abfragen (und auch setzen oder löschen):
fsutil dirty query C: #für laufwerk c:
Das Hidden-Volume wird sicher nicht beim Systemstart getestet, erst wenn es angesprochen wird, so belegt es nur Speicher auf der Disk.

Ich bin mir auch nicht sicher ob Imagingtools über den Weg des Neuaufbaus der C-Partition den Fehler beseitigen würden, da müßte man wohl das Handbuch konsultieren. In den Meißten fällen sind Images Abbilder einer Partition, also physikalisches lesen eines jeden Sektors bei der Erstellung und ebensolches bei der Wiederherstellung, Es ist mir allerdings bei der Arbeit mit Acronis Trueimage aufgefallen, dass die Files zumindest einzelnd beim zurücklesen angezeigt werden, das könnte darauf hindeuten, dass die MFT wirklich neu geschrieben wird.

Es könnte an der Disk aber auch ein Hardwaredefekt vorliegen und dies könnte man mit dem Herstellertool überprüfen.

Du kannst z.B. mit Nero ein Image von einer DVD einlesen und als ISO dann auf der Disk ablegen, wenn das Image auf der DVD bootbar war, ist es hinterher auch nach dem brennen wieder bootbar. Auch läßt sich eine DVD sicher nachträglich bootbat machen, indem man den Bootcode hinzufügt, ich habe es allerdings bisher nur mit CDs (bzw. CD-RWs) gemacht. Hier (unten auf der Seite) am Beispiel von CDs, sollte analog bei DVDs ähnlich sein.

Mit den Diagnose-CDs UBCD und / oder INSERT kannst Du die meißten Festplatten durch die Herstellertools testen und auch die S.M.A.R.T.-Werte abfragen (Smartmontools).

 

[Sendre]

Hallo,
ich lasse gerade einen ausführlichen S.M.A.R.T Test laufen, der kurzfristige hat keine Fehler gebracht.
Ansonsten habe ich die Hidden-Partition als Image auf eine andere Festplatte abgelegt. Damit wird sich, falls meine Recovery-DVD doch irgendwann den Geist aufgeben sollte, wieder wohl eine Boot-DVD brennen lassen.
C:\ liegt auch als Image vor.

Du kannst z.B. mit Nero ein Image von einer DVD einlesen

Die Recovery-CD liegt nicht als Image vor, sondern als mit normalen Files/Verzeichnissen gebrannt (ursprünglich erstellt mit Hilfe der Notebookfunktion aus der Recovery-Partition).

Der ausführliche Test hat keine Fehler gebracht.

Ich habe auf E:\ Platz gemacht die Hidden-Partition enabled, kopiert in E:\ (jetzt I:\) und wollte nun H:\ löschen.

Eigenartig ist jetzt folgendes:
C:\ bringt nun auf einmal keine Fehler mehr.

Wenn man den Rechner neu bootet bringt C:\ wieder den Fehler.
Wenn man H:\ prüft und anschließend C:\werden keine Fehler gebracht

Ich glaube 2 primäre Partitionen auf einer Festplatte sind nicht gesund?
Sollte ich in der Tat am besten löschen und gut ist.

Jetzt kann ich an den nächsten Rechner mit ähnlichen Fehlermeldungen rangehen, wobei dort keine versteckte Partition drauf ist.

Danke nochmal für die Hilfe,
Sendre

 

[Sendre]

Hallo,
jetzt habe ich es doch geschafft den Rechner lahm zu legen. Nachdem ich die alte Recovery-Partition (H) gelöscht habe, kann Windows nicht mehr starten.

Windows root \system32\hal.dll fählt oder ist beschädigt.

Vermutlich will Windows jetzt von der 2ten Partition starten, die jetzt ja die erste ist. Muß wohl irgendwie an die boot.ini kommen und es dort entsprechend einstellen, oder ich versuche vor der jetzigen ersten Partition wieder eine Pseudopartition einzufügen, damit er glücklich wird und in der zweiten das Windows findet.

Mal schauen wie die Story endet...

 

[Sendre]

oder ich versuche vor der jetzigen ersten Partition wieder eine Pseudopartition einzufügen, damit er glücklich wird und in der zweiten das Windows findet.

das war nichts

 

[Mueli]

Mit den Partitionen 'rumzuspielen' ist gefährlich, denn Du änderst die Sortierung gerade wenn Du vor der Startpartition etwas einfügst, was mit der Aufhebung des Hiddenstatus der Recovery-Partition ja geschehen ist.
In der Recovery-Console (vom Installationmedium starten und R auswählen) steht ein Befehl zur Erstellung der Boot.ini zur Verfügung, mit Bootcfg /scan kannst Du dir auch alle Installationen anzeigen lassen. Mit Diskpart kannst Du die Partitionen verändern (hidden setzen sollte auch möglich sein - Diskpart>attributevolume set .... ). Mit map kannst Du Dir die Zuordnungen der Laufwerksbuchstaben anzeigen lassen.

 

[Sendre]

Muß wohl irgendwie an die boot.ini kommen und es dort entsprechend einstellen

das war es! War zwar recht abenteuerlich die boot.ini aber jetzt startet der Rechner normal.
Der Volumebit-Fehler ist immer noch da.
Jetzt nochmal Reparatur in der RC probieren..

In der RC repariert Chkdsk den Fehler in Windows ist er wieder da.

Ich werde jetzt "fsutil" noch einmal probieren und wenn das auch nicht klappen sollte, dann könnte ich theoretisch das Gerät einschicken (noch 1/2 Jahr Garantie), wobei ich das sehr, sehr ungerne tun würde.

Mit den Partitionen 'rumzuspielen' ist gefährlich, denn Du änderst die Sortierung gerade wenn Du vor der Startpartition etwas einfügst, was mit der Aufhebung des Hiddenstatus der Recovery-Partition ja geschehen ist.

ja das ist nicht ohne, ging gut mit Acronis DiskDirektor


Update:
"fsutil dirty query c:" kann nicht gesetzt werden.
Die Meldung dazu: c hat keine Fehler.

Klasse - ich bin jetzt genauso weit wie vorher, muß ja teilweise noch zufrieden & froh sein, daß der Rechner läuft.

 

[Mueli]

fsutil dirty query c: # zeigt den Status nur an, da query
fsutil dirty set c: # hingegen setzt es

Da ich kaum glaube, dass am OS etwas das Filesystem immer wieder shreddert (obwohl ich beruflich Harakiri laufende Anwendungen schon erlebt habe), denke ich eher an einen Fehler der Disk, aber um das auszuschließen ist eine Diagnose nötig. Ich hatte Dir dazu ja bereits Links für zwei bootbare CDs geliefert, vielleicht testet Du die Disk jetzt wirklich mal auf Fehler hin.

 

[Sendre]

Ich hatte Dir dazu ja bereits Links für zwei bootbare CDs geliefert, vielleicht testet Du die Disk jetzt wirklich mal auf Fehler hin.

hatte ja gestern bereits einen ausführlichen SMART-Test machen lassen und auch heute brachte der Advanced IBM/Hitachi-Test von der UBCD keine negativen Erkenntnisse. Also scheint mit der Disk alles ok zu sein.
Ich werde dann gleich noch fsutil mit dem set-Parameter probieren.

 

[Sendre]

Hallo,
also das bringt auch wieder nichts:

fsutil dirty set c:

Ich habe noch mal Auslagerungsdatei und Ruhezustand disabled, defragmentiert und in der RC repariert.

Was ich jetzt noch entdeckt habe in Testdisk geht aus den Bildern hervor: Bild 003a verstehe ich nicht. Evtl ist vom Löschen der versteckten Partition gestern noch etwas drin geblieben.

Wenn ich in Bild 003d auf Extd Part gehe, dann verändert sich der Startblock von 1961 auf 138

Warum scheint die Platte unter Testdisk zu klein zu sein?

Könnte man vielleicht mit diesen Angaben etwas sinnvolles tun, oder sollte ich evtl. von allen Partitionen ein Image ziehen, alles formatieren und die Images wieder draufspielen?
Die Daten sind ja alle vorhanden.

Gruß, Sendre

 

[Mueli]

Die Werte aus dem PIC 003a sind ohnehin außerhalb des Bereichs (der Disk), wenn man mal vom Start absieht.

Bei dem ersten Laufwerk in der erweiterten Partition bin ich es auch etwas im Zweifel, ich würde da auch eher 138 als Start erwartet, hast Du dann mal Search! für eine tiefere Suche gemacht?