WD 3TB ist plötzlich RAW...

[Ernst@at]

Wenigstens eine gute Nachricht.
Denn chkdsk ist eines der Arschlochprogramme, welche durch tiefgreifende Änderungen des Filesystems jeden Versuch des Rückgängigmachens aussichtslos werden lässt, da man bei MS anscheinend noch nie was von einem Transaktions-Rollback-Log gehört hat.
Fällt das Tool auf die Schnauze oder macht es wie in dieserm Falle völligen Unsinn, wars das schon. Dummerweise wird bei derart kapitalen Fehlern wie einer Plattenschrumpfung die Partition als "bad" gekenzeichnet und beim nächsten Start eine automatische Überprüfung eingeleitet. Wenn der Verbrecher dieses Tools nicht später als BIOS-Coder bei GB sein Unwesen getrieben hat, war es zumindest ein Seelenverwandter von ihm.
.
Ich stelle mal die Anweisungen für die Extraktion der Daten zu einer Neuanalyse der Situation bis zum Abend zusammen. Dann sehen wir weiter. Einstweilen schönen Sonntag noch!

Ergänzung (4. Dezember 2011)

Während ich hier die Anweisungen erstelle, kannst Du ja mal testen, ob die Platte jetzt einen BIOS-Angriff, wenn sie bei POST des BIOS Power-on und angesteckt ist (alle anderen HDDs Powermäßig weggeschaltet) der Seuche standhält. Mehr als bisher kann nicht kaputt werden, ich will gerne wissen, ob das funktioniert. Sind ja dann nur ein paar Steps, das wieder richtigzustellen. Es gibt ja noch mehr zukünftige Fälle, wo dies vielleicht von Bedeutung wäre - und ich kenne diese Umgehung nur vom Hörensagen unter ungewissen Umgebungsbedingungen.

Ergänzung (5. Dezember 2011)

Ich habe lange sinniert, mir ist nichts eingefallen, was falsch gelaufen sein könnte.

Also machen wir von vorne eine neue Analyse.

Hol mir folgende Sektorinhalte in einen txt-file
jeweils Eingabe der Sektornummer,Enter, Edit select block, dort Länge anpassen, OK, ctrl-C
bei ersten mal in new file rechts in den char-Teil klicken, sonst nur den Tab vor ctrl-V.

0,800
34,200
262177,200
264192,200
5860532223,200
>| , 200

speichern in inspect1.txt

Wir werden schon rauskriegen, was da falsch läuft...

 

[Pazifist-Deluxe]

Hi Ernst@at.

Hat etwas länger gedauert aber hier ist die Datei... Hoffe du findest was raus.

Vielen Dank!

 

[Madnex]

Ich möchte Ernst@at zwar nicht wieder stören, aber ich habe im Planet3DNow Forum einen sehr ähnlichen Fall, bei dem auch wieder eine 3 TB Platte von WD mit nur 750 GiB erkannt wird. Diesmal hängt die Platte aber nicht an einem Gigabyte sondern an einem AsRock Board, das allerdings auch wieder auf einem AMD Chipsatz (wenn auch eine ältere Version) basiert. Der Fehler könnte also nicht bei Gigabyte sondern beim AMD-SATA-Controller (vielleicht auch Treiber) liegen oder die WD Platte könnte ein Firmware-Bug haben.

Hier der Link zum Thread: klick!

/Edit
Vorausgesetzt natürlich, dass die Platte nicht vorher mal an einem Gigabyte Board angeschlossen war und aufgrund der geschrumpften Kapazität vom Vorbesitzer zum Händler zurückgeschickt wurde. Die Kombination 3 TB WD Festplatte und Board mit AMD-Chipsatz wäre dann aber schon ein recht großer Zufall.

 

[Ernst@at]

Ach Madnex, DU störst doch nicht. Jedwede Beiträge zum Thema sind hochwillkommen.
Gibt auch ein wenig Sicherheit, wenn noch jemand kritisch mitliest, damit man sich nicht irgendwo in einer Sackgasse verbeisst.
Ich hab mal dort bei denen nach den genaueren Umständen angefragt.
Es könnte durchaus so sein, dass ein Hardwareversand eine Retoure eines enttäuschten GB-Käufers, den die Platte so doch etwas zu klein um diesen Preis war, ungeprüft einem Zweiten aufs Auge gedrückt hat - also ein "Schrumpfungsrücktritterwerb" sozusagen.

Hier bin ich mir wegen der Symptomatik (wir hatten sie ja schon wieder mit 3TB, plötzlich war sie aber wieder klein) absolut sicher, dass da sie GB-Feature dahintersteckt. Darauf haben sie ein Exklusivrecht, sowas macht sonst niemand


@Pazifist-Deluxe:

Da ich dummerweise in meiner Anweisung nicht ein "Copy as Editor View" geschreieben habe, sondern Ctrl+C, habe ich keine Kontrolle, ob auch die richtigen Sektoren im Auszug angekommen sind. Wenn ich mal drauf vertraue, das es fehlerfrei durchgeführt wurde, dann sehe ich hier eine um 1 Sektor verkleinerte HDD, sowie eine Zerstörung am Beginn der Datenpartition. Das NTFS-Header-Backup am Ende der Partition ist OK.
Woher die Zerstörung kommt, bin ich noch am suchen.

 

[Pazifist-Deluxe]

Hi Ernst@at.

Anbei noch mal das ganze als Editor View kopiert...

 

[Ernst@at]

Tja, so wie ich es schon gesehen habe

===== NTFS INFORMATION ===== at LBA=264192
000081001FE 34DB             Boot signature='34DB'... INVALID !!!
00008100000 E3F19B           jump around... WRONG CODE

===== NTFS INFORMATION ===== at LBA=5860532223
2BAA13FFFFE 55AA             Boot signature='55AA'... valid
2BAA13FFE00 EB5290           jump around... OK
2BAA13FFE03 4E54465320202020 NTFS ID... OK
2BAA13FFE0B 0002             Bytes per sector: 512
2BAA13FFE0D 08               Sectors per cluster: 8 ==> Clustersize=4K
2BAA13FFE0E 0000             reserved sectors: 0
2BAA13FFE10 000000           always zero...OK
2BAA13FFE13 0000             not used...OK
2BAA13FFE15 F8               <Media descriptor>
2BAA13FFE16 0000             always zero...OK
2BAA13FFE18 3F00             Sectors per track: 63
2BAA13FFE1A FF00             # heads: 255
2BAA13FFE1C 00080400         # hidden sectors: 264192
2BAA13FFE20 00000000         <not used by NTFS>
2BAA13FFE24 80008000         <not used by NTFS>
2BAA13FFE28 FF974C5D01000000 Total Sectors: 5860268031
.                            ==> Size:2861459MB 2794.39GB
.                            ==> NTFS Origin at sector: 264192 ==> Sector placement: OK
2BAA13FFE30 00000C0000000000 Cluster# of $MFT: 786432
.                            ==> $MFT at sector: 6555648
2BAA13FFE38 0200000000000000 Cluster# of $MFTmirr: 2
.                            ==> $MFTmirr at sector: 264208
2BAA13FFE40 F6000000         Clusters/File Record Segment: 246
2BAA13FFE44 01000000         Clusters/Index Block: 1
2BAA13FFE48 D270BAF47DBAF484 Volume Serial #
2BAA13FFE50 00000000         checksum

ist der NTFS-Header zerstört.

Ich werde mal versuchen, rauszukriegen, was an dessen Stelle steht.
Falls ich nicht erfolgreich sein sollte, müssen wir die Orte der Zerstörung per HxD genau eingrenzen. Da vorne steht normalerweise nur der NTFS-Bootcode, der bei einer Datenpartition uninterressant ist, und dann die ersten auf diese Partition übertragenen Dateien, wenn die nicht wieder gelöscht wurden bzw lustiges Herumgeschiebe per Defrag veranstaltet wurde.

Nachtrag: Ich sehe gerade, dass sich da vorne auch der $MFTmirr aufhält - naja, eine sehr sinnvolle Position hat man da ausgesucht...

Ergänzung (6. Dezember 2011)

Wie ich gesehen habe, ist die Microsoft reserved Partition nur platzmäßig angelegt, aber nicht formatiert worden. Am Ende dieser ist aber schon Müll zu erkennen.
Mach mal ein HxD
- positioniere Dich auf den Endsektor dieser Partititon, 262177
- Menu: Search/Find Search for: 00000000 00000000 00000000 00000000 , hex, backward

und mit F3 solange zurück, bis Du einen komplett leeren Sektor gefunden hast.
dann Edit/select Block, Startwert belasse, length 100000 , hex
mit strg+C in die Zwischenablage
File/New
Strg+V einfügen
file/save as 1MB.zip (.zip nur zum überlisten der Forumssoftware) und stell es in den Anhang

schreib mir noch, in welchem Sektor der Beginn des Mülls war

 

[Pazifist-Deluxe]

Hallo.

Sektor 247 war der Sektor der komplett leer war - ab Sektor 248 steht also was drin - wenn ich auch nicht beurteilen kann ob das Müll ist...

 

[Ernst@at]

Hingehören tut es hier gerade nicht. Ist aber kein BIOS-Backup, soweit ich das in Erinnerung habe, sieht sowas anders aus

Ergänzung (7. Dezember 2011)

Jedenfalls ist der Partitionbeginn, d.h. der NTFS-Header und höchstwahrscheinlich auch der $MFTmirr Cluster überschrieben und die folgenden Dateien auch.
Ich habe gerade mal im anderen Forum, wo eine leere Platte diese Schrumpfung erlitten hat, gebeten, mal nachzusehen, ob das dort auch passiert ist - wenn ja, ließe sich dort das Ende der Zerstörung genau feststellen.

Bei Deiner Platte kann man jetzt probieren, den NTFS-Header, Bootrecord und $MFTmirr zu reparieren und dann zu schauen, ob sich die Partition mounten lässt - damit könnte man die genauen Positionen der Files dort am Partitionbeginn feststellen und diese dann auf Zerstörung abklappern.
Wenn das nicht klappt, wird ein Tool wie GetDataBack oder TestDisk notig sein, um die Dateien runterzubekommen - und auch 2,2TB Plattenplatz dafür.

 

[Pazifist-Deluxe]

Hi Ernst@at.

Danke für das Update. Ich gehe davon aus das du eine gute Idee oder zumindest einen Plan hast wie ich den NTFS-Header, Bootrecord und $MFTmirr wieder reparieren kann - zumindest versuchen das zu tun.


Cya

 

[Ernst@at]

Ach, da fällt mir noch vieles ein...

ich stell mal ein paar Theorien auf, wie es zu der Zerstörung gekommen sein kann, die wir im Anschluss verifizieren oder falsifizieren werden:
- Sie erfolgte zum Zeitpunkt der HPA-Attacke, durch den Bug wurde wegen der Fehladressierung auch ein falscher Platten- und Speicherbereich für den I/O beim Schreiben des BIOS-Backup ausgeführt; dann könnten(müssten aber nicht) nur 2113 Sektoren überschrieben sein - die Bereiche setzen sich aus Unterbereichen von 2048, 64 und 1 Sektor zusammen. Die Sektoranzahl kann aber auch jeden beliebigen anderen Wert haben.
- Das Board-BIOS hat noch eine zweite Macke und kann keine LBA-Adressen >32Bit; ähnliche Fälle bei GB-Boards bei >31Bit und >30Bit habe ich schon bei Gigabyte als künstliche Limitierung gesehen; dann würde zwar vor, aber nicht mehr hinter der LBA=2**32 was auf der Platte zu finden sein.

Der zweite Fall wäre unmöglich, wenn Du die Platte selbst GPT-Formatiert hast.
Denn dann dürfte der NTFS-Header Mirror nicht am Ende der 3TB Partition stehen, wo wir ihn ja gefunden hatten. Wurde die Platte aber schon formatiert ausgeliefert, stammt dieser Sektorinhalt noch vom WD-Werk. Diese Beschränkung könnte bei der F6-BIOS Version noch bestanden haben, bei der F8 jedoch nicht mehr. Da die Affen in Taiwan auch höchst schlampig bei der Angabe der Änderungen des BIOS sind, wurde das vielleich nicht erwähnt, dass dies per F7 oder F8 behoben wurde.
Andererseits kann er immer noch vorliegen, und jeder Sektor >2**32 wird als Sektor x-2**32 referenziert, auch im HxD.

Hast DU die Partition selbst formatiert, oder war die schon?

zu diesem Zweck mach mal einen Benchmark mit HDDScan / Surface Test/ read mit Start-Adresse 4200000000 , End-Adresse 4400000000
Der Kurvenverlauf wird zeigen, ob jetzt mit der F8 tatsächlich bis zum Ende der Platte genuckelt wird oder ab 2TB wieder vom Anfang begonnen. Brauchst Du Anweisungen datu oder schaffst DU das auch ohne?

- Schau mit HxD auf die Platte, Sektor 1565564927. Steht da in der ersten Zeile ...NTFS

- Positioniere auf Sektor 6555648 - steht da am Beginn "FILE0..." ?

- Positioniere auf Sektor 4300000000 Steht Da was oder nur 00en?
Wenn leer, dann Menü Search/Find/ 80,Hex, backward. Welcher Sektor unterhalb ist der höchste mit Daten beschriebene? (Einfach ein Edit/Copy as/Editor View und Strg+V ins Post reicht)

 

[Pazifist-Deluxe]

Hi Ernst@at.

Bin momentan noch Arbeiten, daher hier nur ein paar kurze Vorabinfos:

- Ja ich habe die HDD selber GPT formatiert. Sie hing zu diesem Zweck an dem WD Controller + eSATA Gehäuse - sonst waren ja nur 750GB zu sehen und der Rechner wollte an Sata direkt auch nicht booten. Also Booten, einschalten, formatieren, fertig.

- Deine Erklärung zu HDDScan sollte ausreichend sein. Werde ich heute Nachmittag testen.

- Mein neues ASUS MB ist bereits unterwegs zu mir und sollte heute Nachmittag ankommen. Werde dann wohl am WE eine Umbauaktion starten und vielleicht sogar Win7 neu aufspielen... Mal sehen ob das sofort nötig ist oder noch bis Weihnachten warten kann...

Alles weitere dann sobald ich am Rechner bin...

Ergänzung (8. Dezember 2011)

So, bin am Rechner - hier die weiteren Ergebnisse:

- HDDScan, siehe Screenshot, scheint an den richtigen Sektoren gelesen zu haben.

- Sektor 1565564927 - hier steht nichts von NTFS

- Sektor 6555648 - da steht am Beginn "FILE0..."

- Sektor 4300000000 - nur Nullen

- Sektor 4294967543:

  Offset(h)   00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

2000001EE00  CE B1 C2 CA 89 C3 2C E4 BE E4 AE E2 4B 01 40 A8  αÂʉÃ,ä¾ä®âK.@¨
2000001EE10  4A D3 43 4C 4E 71 A3 B0 7F D7 95 F0 4B D3 72 01  JÓCLNq£°.וðKÓr.
2000001EE20  D3 00 96 52 E8 08 18 14 CB 2C 18 9D BF 5C C3 E7  Ó.–Rè...Ë,..¿\Ãç
2000001EE30  36 7B B9 56 D9 7A B9 BE 64 7D 21 E7 E8 69 BB 9B  6{¹VÙz¹¾d}!çèi»›
2000001EE40  0B 84 78 91 54 F3 0B 7E 40 C8 C5 10 6E 24 CE 9E  .„x‘Tó.~@ÈÅ.n$Ξ
2000001EE50  CB 0B 2C 65 58 66 AE 0C D3 8C 24 83 23 1A 33 9F  Ë.,eXf®.ÓŒ$ƒ#.3Ÿ
2000001EE60  B0 46 78 CE F0 66 57 D2 25 E4 B6 5C 0E 98 F6 C2  °FxÎðfWÒ%ä¶\.˜öÂ
2000001EE70  49 07 F2 5B 69 96 87 C7 0B 31 D3 E9 26 DF 2D F8  I.ò[i–‡Ç.1Óé&ß-ø
2000001EE80  49 3A 28 EF 52 C0 2C 7E 3C 9B A1 43 05 27 27 D0  I:(ïRÀ,~<›¡C.''Ð
2000001EE90  D6 A4 CB BF 78 A0 55 44 BF 20 BC 34 26 C4 AB 41  ֤˿x*UD¿ ¼4&Ä«A
2000001EEA0  D1 71 4D 09 9E 9F 86 CE CD 09 2A 5C C9 48 8F 7A  ÑqM.žŸ†ÎÍ.*\ÉH.z
2000001EEB0  7B F8 28 37 27 91 90 65 B1 DE 1D 18 2F DF 5E 43  {ø(7'‘.e±Þ../ß^C
2000001EEC0  E2 DB 51 68 2F 73 FB 6E C9 22 F4 41 C2 2D CF A8  âÛQh/sûnÉ"ôAÂ-Ϩ
2000001EED0  D3 5E 90 DD A1 B3 5D D3 53 60 0E 76 84 81 D9 0F  Ó^.Ý¡³]ÓS`.v„.Ù.
2000001EEE0  31 87 D7 EF 47 C6 98 B2 87 52 CB 83 7B 5C FA 45  1‡×ïGƘ²‡R˃{\úE
2000001EEF0  85 15 C7 E8 E5 6B 01 E0 FE D1 0E 71 66 AE E4 7F  ….Çèåk.àþÑ.qf®ä.
2000001EF00  F3 25 17 6A 95 E9 8E 24 76 6D A9 C5 B4 81 F6 CE  ó%.j•éŽ$vm©Å´.öÎ
2000001EF10  64 E6 D6 24 46 29 E7 D3 62 1F 2C 23 65 59 00 66  dæÖ$F)çÓb.,#eY.f
2000001EF20  D4 00 D3 F4 AC 8B 45 72 16 83 58 72 2A E2 F8 A7  Ô.Óô¬‹Er.ƒXr*âø§
2000001EF30  E9 8F 6F B1 A6 9D 3D 60 99 EC 09 EB 32 DA E3 4C  é.o±¦.=`™ì.ë2ÚãL
2000001EF40  89 70 FE FD 4A 8F A3 7E E5 82 00 06 84 07 7F FE  ‰pþýJ.£~å‚..„..þ
2000001EF50  80 01 FC 3C 7D B2 77 02 0D 3B 80 09 EF 7B DE DE  €.ü<}²w..;€.ï{ÞÞ
2000001EF60  F7 BD 80 00 FF F6 DB 6D B6 FF FF FF FF FF FF FF  ÷½€.ÿöÛm¶ÿÿÿÿÿÿÿ
2000001EF70  FF FF FF FF FF FF FF FF 40 00 00 00 00 00 00 00  ÿÿÿÿÿÿÿÿ@.......
2000001EF80  00 00 00 00 02 00 00 00 00 00 00 00 03 7A 5E D5  .............z^Õ
2000001EF90  AD 27 39 4A 52 8C 61 07 BD EE 6B 9A C6 2D 49 4B  .'9JRŒa.½îkšÆ-IK
2000001EFA0  DA C5 AD 49 4A 50 82 98 A5 31 4A 41 8C 42 10 42  ÚÅ.IJP‚˜¥1JAŒB.B
2000001EFB0  10 B9 AC 5A D2 93 A5 08 31 CA 52 98 84 20 C4 30  .¹¬ZÒ“¥.1ÊR˜„ Ä0
2000001EFC0  84 21 0B 56 A4 98 83 29 04 41 0C 63 10 86 21 08  „!.V¤˜ƒ).A.c.†!.
2000001EFD0  21 08 42 10 B5 6A 4A 4A 61 08 62 10 84 11 84 22  !.B.µjJJa.b.„.„"
2000001EFE0  10 82 10 84 21 08 00 00 00 00 00 00 00 00 00 00  .‚.„!...........
2000001EFF0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
2000001F000  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
2000001F010  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
2000001F020  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
2000001F030  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
2000001F040  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
2000001F050  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

That's it...

 

[Ernst@at]

Ich nehme an, es hat auch schon bei Dir gedämmert
429496754-2**32=248
Neben dem Schrumpf-Bug hatte die F6 auch noch zusätzlich die völlig sinnlose 32.Bit LBA Limitierung (seit gut 10 Jahren gibt es die 48-Bit LBA Adressierung!) in sich, womit Du Dir deine ersten Dateien durch die zuletzt aufgebrachten selbst überschrieben hast.
Wir können also die Reparatur in mehreren Schritten vornehmen, die ersten aufgebrachten und überschriebenen lassen sich aber nicht herstellen, jedoch identifizieren.
Die $MFT ist nicht beschädigt, also haben wir beste Chancen.

Womit hast Du kopiert?
Es wird so gelaufen sein: ein übertragener Dateiteil von 256 Sektoren pro I/O hat 8 Sektoren vor der 2TiB-Grenze begonnen und die auch noch 248 darüber hinaus übertragen, weil der Controller nicht der künstlichen Beschränkung unterliegt, sondern nur das BIOS mit der Beginnsektoradresse. Der nächste Dateiblock wurde dann unten ab Sektor 248 hingeschrieben, weil das GigaBitchBIOS die Beginnsektoradresse kastriert hat, usw.

der HDDScan ist mir nicht ganz geheuer,
mach den nochmal mit Start-Sektor-Adresse 4100000000 , End-Adresse 4300000000
eigentlich ist 2**32=4294967296, der Sprung findet aber schon kurz nach 4200.... statt

Ergänzung (8. Dezember 2011)

und dann übertrag einfach vom HxD hier ins Post

Edit/select Block Start: BAA13FFE00 length: 200 , hex & Edit(/Copy as../ Editor View
Edit/select Block Start: BAA1475C00 length: 400 , hex & Edit(/Copy as..( Editor View

 

[Pazifist-Deluxe]

Zuerst mal den Offset BAA13FFE00:

 Offset(h)   00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

0BAA13FFE00  15 89 BE 90 F7 2D FA 56 41 DC 43 E9 92 6D AE F0  .‰¾.÷-úVAÜCé’m®ð
0BAA13FFE10  0E 7F 52 DB 3F 21 F9 EA 21 F7 87 2A D3 E9 3F 3B  ..RÛ?!ùê!÷‡*Óé?;
0BAA13FFE20  A0 74 33 F2 AC 2D 2A BE 3C 35 35 3B F8 23 E8 8E  *t3ò¬-*¾<55;ø#èŽ
0BAA13FFE30  97 BB 10 52 25 76 26 A8 C8 1B A7 40 FC 07 0D FB  —».R%v&¨È.§@ü..û
0BAA13FFE40  5A B3 D6 51 F0 79 08 FE 8E 53 CC E3 4E B1 33 05  Z³ÖQðy.þŽSÌãN±3.
0BAA13FFE50  2A 76 12 92 48 F4 36 47 59 63 6E CF 4B 8A 87 AA  *v.’Hô6GYcnÏKŠ‡ª
0BAA13FFE60  A0 BF 00 D6 54 9F 6B 09 6A 2F 42 85 F1 0B 70 AD  *¿.ÖTŸk.j/B…ñ.p.
0BAA13FFE70  E2 E6 35 20 16 7C 87 4C BE 8A 57 72 95 24 A9 35  âæ5 .|‡L¾ŠWr•$©5
0BAA13FFE80  D6 F6 D2 ED FA D0 43 55 39 9D 8C EB 9E 67 E2 C6  ÖöÒíúÐCU9.ŒëžgâÆ
0BAA13FFE90  61 B5 3D 3A 21 05 6D 6B A2 09 11 AC FB 09 F9 93  aµ=:!.mk¢..¬û.ù“
0BAA13FFEA0  1E 6E 34 C8 A0 F4 A2 21 BB FF 87 4B D3 28 23 1C  .n4È*ô¢!»ÿ‡KÓ(#.
0BAA13FFEB0  24 28 31 90 6A 8D 4F 39 11 5C AA 9D 57 25 19 5D  $(1.j.O9.\ª.W%.]
0BAA13FFEC0  6D B1 1C 80 D1 6D 34 8A AB 36 D1 EB B1 8F 9A 54  m±.€Ñm4Š«6Ñë±.šT
0BAA13FFED0  A0 D8 65 9C B8 3B E1 CA CA 90 CE 62 23 F7 F7 A5  *Øeœ¸;áÊÊ.Îb#÷÷¥
0BAA13FFEE0  98 DD 9B 07 D0 82 B7 1A E1 3E 18 70 98 E3 16 21  ˜Ý›.Ђ·.á>.p˜ã.!
0BAA13FFEF0  16 18 04 AA C6 8F 09 5A 14 88 CA A3 53 5C 43 2F  ...ªÆ..Z.ˆÊ£S\C/
0BAA13FFF00  CB C1 00 11 80 63 66 4E 42 84 23 0C FC FD EC EA  ËÁ..€cfNB„#.üýìê
0BAA13FFF10  A1 27 DF 83 B4 97 37 63 A2 B9 43 BE B8 71 BD 04  ¡'߃´—7c¢¹C¾¸q½.
0BAA13FFF20  16 62 3D 9D F8 66 4B 64 82 F3 72 E3 95 AE 9D 64  .b=.øfKd‚órã•®.d
0BAA13FFF30  88 0F 6D 58 6F E7 0E 87 E8 CD 2F C5 30 34 7A 77  ˆ.mXoç.‡èÍ/Å04zw
0BAA13FFF40  01 B6 86 B9 1A B6 38 99 90 E8 27 B8 65 38 D2 C7  .¶†¹.¶8™.è'¸e8ÒÇ
0BAA13FFF50  1E 53 F4 84 61 29 B4 98 10 36 07 4B 1A FA A1 41  .Sô„a)´˜.6.K.ú¡A
0BAA13FFF60  ED 95 DC DC 8B 10 90 93 24 87 0C 1D 33 7E 2B 2E  í•ÜÜ‹..“$‡..3~+.
0BAA13FFF70  9C 47 47 AF 67 72 13 80 8B B1 24 35 2F 2B 9D 7F  œGG¯gr.€‹±$5/+..
0BAA13FFF80  BC 33 31 F8 BA E6 2F D1 2E E8 23 93 F7 66 E2 D4  ¼31øºæ/Ñ.è#“÷fâÔ
0BAA13FFF90  7B 47 C8 AA 88 E7 6D A1 CC 99 3A F0 DC 05 C0 24  {GȪˆçm¡Ì™:ðÜ.À$
0BAA13FFFA0  99 F1 EA 3B F3 74 74 21 47 F8 8C EE AA 55 30 CC  ™ñê;ótt!GøŒîªU0Ì
0BAA13FFFB0  FD 83 CE 0C 9F 69 E6 90 F3 0E A6 38 26 54 33 9F  ýƒÎ.Ÿiæ.ó.¦8&T3Ÿ
0BAA13FFFC0  49 88 88 AA 90 66 BF 44 45 B2 AE 77 99 E9 54 64  Iˆˆª.f¿DE²®w™éTd
0BAA13FFFD0  1F 7E EB 2A 0C 88 D6 06 C5 EC 17 0F B8 CE 8B E9  .~ë*.ˆÖ.Åì..¸Î‹é
0BAA13FFFE0  9C 1C E4 7A 00 EF DC 86 06 6D 38 64 37 83 C2 9A  œ.äz.ï܆.m8d7ƒÂš
0BAA13FFFF0  25 8D 34 AA A4 CB 48 1B 60 2B 55 61 4F AE 33 BF  %.4ª¤ËH.`+UaO®3¿

und dann BAA1475C00:

 Offset(h)   00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

0BAA1475C00  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0BAA1475C10  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0BAA1475C20  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0BAA1475C30  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0BAA1475C40  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0BAA1475C50  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0BAA1475C60  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0BAA1475C70  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0BAA1475C80  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0BAA1475C90  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0BAA1475CA0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0BAA1475CB0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0BAA1475CC0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0BAA1475CD0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0BAA1475CE0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0BAA1475CF0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0BAA1475D00  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0BAA1475D10  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0BAA1475D20  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0BAA1475D30  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0BAA1475D40  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0BAA1475D50  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0BAA1475D60  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0BAA1475D70  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0BAA1475D80  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0BAA1475D90  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0BAA1475DA0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0BAA1475DB0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0BAA1475DC0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0BAA1475DD0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0BAA1475DE0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0BAA1475DF0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0BAA1475E00  45 46 49 20 50 41 52 54 00 00 01 00 5C 00 00 00  EFI PART....\...
0BAA1475E10  99 B8 03 5C 00 00 00 00 AF A3 50 5D 00 00 00 00  ™¸.\....¯£P]....
0BAA1475E20  01 00 00 00 00 00 00 00 22 00 00 00 00 00 00 00  ........".......
0BAA1475E30  8E A3 50 5D 00 00 00 00 98 FD 27 A2 DD EF 98 4E  Ž£P]....˜ý'¢Ýï˜N
0BAA1475E40  A9 B7 95 C1 06 77 52 17 8F A3 50 5D 00 00 00 00  ©·•Á.wR..£P]....
0BAA1475E50  80 00 00 00 80 00 00 00 36 D2 2F B9 00 00 00 00  €...€...6Ò/¹....
0BAA1475E60  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0BAA1475E70  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0BAA1475E80  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0BAA1475E90  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0BAA1475EA0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0BAA1475EB0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0BAA1475EC0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0BAA1475ED0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0BAA1475EE0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0BAA1475EF0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0BAA1475F00  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0BAA1475F10  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0BAA1475F20  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0BAA1475F30  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0BAA1475F40  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0BAA1475F50  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0BAA1475F60  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0BAA1475F70  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0BAA1475F80  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0BAA1475F90  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0BAA1475FA0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0BAA1475FB0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0BAA1475FC0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0BAA1475FD0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0BAA1475FE0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0BAA1475FF0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

HDD Scan läuft - das langsame Anlaufen kann aber an der Geschwindigkeit der HDD liegen. Die WD Green läuft ja nur mit 5400 1/min und braucht auch immer seine Zeit zum Hochfahren.

Board ist gestern angekommen und auch schon eingebaut - alles läuft normal, die HDD hängt jetzt an dem JMicron Controller (der ist für die eSATA Anschlüsse zuständig) direkt am ASUS Board.

Greetings...

 

[Ernst@at]

Board ist gestern angekommen und auch schon eingebaut - alles läuft normal, die HDD hängt jetzt an dem JMicron Controller (der ist für die eSATA Anschlüsse zuständig) direkt am ASUS Board.

Da werden wir aber schwer die bisherigen GigaBitch-Board Eigenschaften studieren können, um den gesamten Fehlerverlauf zu rekonstruieren, um die geeignete Korrekturmethode zu finden
Der HDD-Scan am neuen Board ist damit schon für die Fisch'; interressanterweise habe ich noch nie eine Platte mit variabler Drehzahl gesehen, also mach ihn trotzdem fertig.

 

[Pazifist-Deluxe]

Moin.

Ja, ob ich da wirklich was vermissen werde, nachdem wir jetzt seit zwei Wochen an der HDD rumddoktorn... ich weiß es nicht - aber es steht dir natürlich offen die Analyse mit dem Gigabitch Board fortzuführen...

HDD Scan hab ich jetzt nochmal von 41 - 43 und von 40 - 44 laufen lassen und aktuell läuft er von 35 - 55. Das dauert natürlich noch. Bei dem 41 - 43er und dem 40 - 44er kannst du aber sehen das die HDD anscheinend immer am Anfang erst "aufwachen" muss bevor sie ihre eigentliche Leserate hinbekommt. Der 35-55 wird das sicher bestätigen.

Wie stehen denn die Chancen für die FS-Rettung?

Und bei 35 - 55 sieht es genauso aus...

 

[Ernst@at]

Tatsächlich kommt die erst nach einiger Zeit in die Gänge... Ich hätt es nicht geglaubt, wenn ich es jetzt nicht selbst sehen würde, da ich keine solcher Platten in meiner Menagerie halte. Viele im Festplattenforum äußern, es gäbe keine variable Drehzahl. Liegt wohl daran, dass HDTune da zuerst mal einen Probelauf macht, um den HDD-Cache zu überlisten, dass da alle dazu dummposten.

Die HDDScan-Läufe wären eigentlich am GB-Board dazu gedacht, einfach graphisch nachzuweisen, ob er auch bei der F8 noch nach 2,2TB (=2TiB) wieder vorne auf der Platte zu nuckeln beginnt, was man am sprunghaften Anstieg der Transferrate ab dieser Adresse ersehen würde.
War der erste Scan noch am GB respektive am eSATA-Anschluss am onboard-Controller durchgeführt?

Zur Frage der Filesystem-Rettung folgende einfache nicht proportionale Grafik:

[FONT="Lucida Console"][SIZE="3"]Reihenfolge der Befüllung:

||<0,125GiB><3,125GiB Daten><-349,300GiB $MFT res. -><-----1695,450GiB Daten------>|<--746GiB Daten-->||
 
a)          [COLOR="Red"]xxxxxxx[/COLOR][COLOR="Lime"]========>iii[/COLOR]
b)                             [COLOR="Lime"]iii[/COLOR]                   [COLOR="Lime"]=============================>[/COLOR]
c)    [COLOR="Lime"]============>               iii[/COLOR][/SIZE][/FONT]

3,125GiB Daten wurden vor der $MFT gespeichert(a) 1695,45Gib dahinter bis zur 2TiB Grenze (b).
Die darüber hinausgehende Menge(c) überschrieb die Daten (a) teilweise, aber nicht bis zur $MFT(iii)

Also sollten sich etwa 1698,7GiB retten lassen, egal, wieviel da vorne überschrieben wurde.
Installiere Dir den Process Explorer von Sysinternals (jetzt bei MS) und mach einen Screenshot vom Schirm
Menu: View/System Information.

Dann werden wir mit HxD
- die zuletzt fehlgeleiteten Dateien(c) an den rechten Ort(hinter b) rücken
- den $MFTMirr wiederherstellen
- den NTFS-Header wiederherstellen
worauf sich hoffentlich die Partition mounten lässt,
um uns dann mit NFI einen Überblick über das Ausmaß der Zerstörung verschaffen.

 

[Pazifist-Deluxe]

OK klingt gut. Warum der Screenshot vom Process Explorer?

Und wie gehen wir hier vor:

Dann werden wir mit HxD
- die zuletzt fehlgeleiteten Dateien(c) an den rechten Ort(hinter b) rücken
- den $MFTMirr wiederherstellen
- den NTFS-Header wiederherstellen
worauf sich hoffentlich die Partition mounten lässt,
um uns dann mit NFI einen Überblick über das Ausmaß der Zerstörung verschaffen.

Zum GB Board. Nein die Platte hatte ich zuletzt nur noch am WD Controller. Soweit ich mich erinnern kann hat doch das Board die HDD gar nicht mehr richtig erkannt - siehe Post #46
Deshalb habe ich mich gestern auch entschieden das MB direkt zu tauschen...

 

[Ernst@at]

Ich will den Storage Commit Wert sehen, ob wir das in einem Schlürf oder nur in mehreren Tranchen schaffen

Ergänzung (9. Dezember 2011)

ich dachte, Du warst nach Aufbringen der 1-Sektor HPA so überzeugt von der von mir versprochenen Wirksamkeit, um sie wieder direkt anzuschließen

 

[Pazifist-Deluxe]

Hi.
Ja, dass mit dem Aufbringen des 1-Sektor HPA hat mich schon überzeugt. Aber das Board hat mich in Gänze jetzt doch etwas verunsichert...

 

[Ernst@at]

Der Speicher sollte für unsere Vorhaben reichen
Ich möchte nur mal rekapitulieren, was der armen Platte bis jetzt zugestoßen ist:

Als Du sie direkt an den onboard-Controller angeschlossen und Daten draufkopiert hast, hat das GigaBitchBIOS F6 alle I/O's oberhalb der 2TiB Grenze nach unten auf der Platte umgeleitet, sobald die freien Datencluster unterhalb der 2TiB Grenze aufgebraucht waren.
Glücklicherweise wurde dabei weder die MBR/GPT-Area am Beginn noch der Dateiindex der $MFT beschädigt, soweit ich das bisher an den Proben gesehen habe. Die funktionslose obligate MS reserved Partition von 100MB musste dafür herhalten und noch der Beginn der Datenpartition. Da wurde der NTFS Header, Bootrec und $MFTmirr sowie $UpCase mit Dateidaten überklatscht, danach kamen die zuerst auf die Partition aufgespielten Dateien am Beginn der Partition zum Handkuss. Inwieweit vor der $MFT liegende andere Metadaten dran glauben mussten, ist noch nicht erhoben. Sollten diese alle intakt geblieben sein, erscheint eine inplace-Reanimation der Partition möglich. Andernfalls ist ein Rescue-Copy auf andere Datenträger nötig.​

Bei BIOS POST war die Platte dann mal nicht ausgeschaltet, wodurch das GigaBitch BIOS F6 die Platte um 2TiB kleiner gemacht. Dabei wurde nachträglich von Windows im Übereifer der GPT-Eintrag am Beginn der Platte auf falsche Werte verändert und am Ende des verbliebenen Userbereiches der Platte (ca 746GiB) ein Bereich von 33 Sektoren mit dem GPT-Mirror angelegt und an dieser Stelle stehende Daten zerstört.​

Die fehlerhaft angelegte HPA wurde entfernt, nachdem die BIOS Version F8 aufgespielt war.
Aber auch diese hatte den Bug nicht gefixt, worauf die Platte wieder mit einer 2TiB HPA beglückt wurde. Dies und Windows hat bloß die gleichen, aber keine weiteren Zerstörungen angerichtet.​

Danach wurde die 2TiB HPA erneut entfernt und eine HPA der Größe von 1 Sektor angelegt. Jeder Spaß hat schließlich auch mal ein Ende.
Nach erneuter Restaurierung der GPT wurde von Win dessen Mirror am neuen Ende(um 1 Sektor tieferliegend) der Platte angelegt und der GPT-Eintrag am Sektor 1 darauf ausgerichtet.​

Mir ist in diesem Universum kein Rettungstool bekannt, welches mit derartigen Zerstörungen artgerecht umgehen könnte. Einige Poster, die offenbar in Paralleluniversen leben, haben da sicher einfachere Mittel zur Hand.
Also bleibt nur die bewährte Ernst@at-Methode zur Korrektur, um zu retten, was noch nicht verloren ist. Was genau zerstört wurde, sollte auch festgestellt werden

<Anweisungen dazu folgen sogleich>
.

Ergänzung (10. Dezember 2011)

Rücken wir einmal 0,5GB der fehlgeleiteten Daten an die richtige Stelle

- Aufruf HxD, die geschändete physische Platte, diesmal read-only Häkchen entfernen

- Sektoradresse 4297064696 in das Sektoreingabefeld übertragen, Enter um hinzupositionieren.
ist der Sektor nur 00en: weitermachen, sonst Abbrechen
- in die erste Zeile dieses Sektors tippst du 80 40 20 10 08 04 02 01 von links beginnend über die Nullen drüber. Bei "File Size change" Popup Abbrechen
-File/Save

- Sektoradresse 4294967544 in das Sektoreingabefeld übertragen, Enter um hinzupositionieren.
- Menu: Search/Find/Search for: 20 , hex, forward
wenn der Sektor 4297064696 der gefundene ist: weitermachen, sonst Abbrechen
- Sektoradresse 248 in das Sektoreingabefeld übertragen, Enter um hinzupositionieren.
- Menü: Edit/Select Block/ Start-adresse belassen, length 20000000 , hex
- Strg+C , liest von der HDD und füllt es in eine 1GB Zwischenablage

- Sektoradresse 4294967544 in das Sektoreingabefeld übertragen, Enter um hinzupositionieren.
- Menü: Edit/Select Block/ Start-adresse belassen, length 20000000 , hex
- Strg+V , es tuckert etwas, bis das fertig ist. Bei Popup "File Size Change" abbrechen, wenn nur Warnung, dass Daten unwiederruflich geändert werden, weitermachen.

- File/Save ,tuckert länger

wenn das fertig ist, HxD beenden.
Ab hier sollten auch Rescue Tools mit dem Datenschrott was sinnvolles anfangen können (wenn nur 1GB überschrieben wurde, sonst müssen wir das noch weiterführen)

Wenn das fertig ist, pappen wir einen $MFTmirr und den NTFS Header drauf.

Nachtrag 10.12.11 11:50
Änderung der Übertragung von 1GB auf 0,5GB
Nachdem ich schon länger nicht in NTFS-Trüffeln gewühlt habe, ist mir entgangen, dass auch die $UpCase Tabelle der Metadaten da vorne im überklatschten Bereich liegt und restauriert werden muss...