Warum ist mein Flash-Laufwerk "schreibgeschützt" geworden und (wie) kann ich es reparieren?

Ich habe ein brandneues Flash-Laufwerk (eine Woche alt), das von Windows, Kubuntu und einem bootfähigen Partitionierer als schreibgeschützt markiert wurde. Warum ist das passiert? Ist es behebbar? Wenn ja, wie kann ich das beheben?

Das Problem

Erstens ist dieses Laufwerk neu. Es wurde sicherlich noch nicht genug benutzt, um an normalem Verschleiß zu sterben, obwohl ich defekte Komponenten nicht ausschließen würde.

Das Laufwerk selbst ist irgendwie in einem Nur-Lese-Zustand blockiert worden. Windows’ Datenträgerverwaltung:

Generic Flash Disk USB Device
Disk ID: 33FA33FA
Type : USB
Status : Online
Path : 0
Target : 0
LUN ID : 0
Location Path : UNAVAILABLE
Current Read-only State : Yes
Read-only : No
Boot Disk : No
Pagefile Disk : No
Hibernation File Disk : No
Crashdump Disk : No
Clustered Disk : No

Diskpart:

Warning: Only 7762 of 7812 MByte tested.
The media is likely to be defective.
7.5 GByte OK (15896472 sectors)
52 KByte DATA LOST (104 sectors)
Details:0 KByte overwritten (0 sectors)
0 KByte slightly changed (< 8 bit/sector, 0 sectors)
52 KByte corrupted (104 sectors)
0 KByte aliased memory (0 sectors)
First error at offset: 0x0000000186003000
Expected: 0x0000000186003000
Found: 0x00200800c40c3061
H2testw version 1.3
Writing speed: 3.95 MByte/s
Reading speed: 14.0 MByte/s
H2testw v1.4

Was mich wirklich verwirrt ist Current Read-only State : Yes und Read-only : No.

Versuchte Lösungen

Bis jetzt habe ich es versucht:

• Formatieren in Windows (in der Datenträgerverwaltung sind die Formatierungsoptionen beim Rechtsklick ausgegraut).

• DiskPart Clean (CLEAN - Clear the configuration information, or all information, off the disk.):

• Windows-Kommandozeilenformatierung

• Windows chkdsk: siehe unten für Details

• Kubuntu fsck (über VirtualBox USB Passthrough): siehe unten für Details

• Acronis True Image zum Formatieren, zum Konvertieren nach GPT, zum Zerstören und Wiederherstellen des MBR, im Grunde alles: fehlgeschlagen (konnte nicht in den MBR schreiben)

Details (und eine nette Geschichte)

Hintergrund

Dies war ein brandneues, generisches 8GB-Flash-Laufwerk, mit dem ich ein Multiboot-Flash-Laufwerk erstellen wollte. Es war als FAT32 formatiert, aber merkwürdigerweise etwas größer als die meisten 8-GIGAbyte-Flash-Laufwerke, die ich kenne. Ungefähr 127MB wurden von Windows als “verwendet” aufgelistet. Ich habe nie herausgefunden, warum. Der nutzbare Endspeicherplatz war ungefähr das, was ich normalerweise von einem 8GB-Laufwerk erwarte (ca. 7,4 GIBIbytes).

Ich hatte eine ganze Reihe von Linux-Distros aufgespielt, zusammen mit einer Kopie von Hiren’s. Sie ließen sich alle perfekt booten. Sie wurden mit YUMI aufgesetzt.

Als ich versuchte, die Knoppix-DVD einzulegen, fügte YUMI eine seltsame Video-Option zu seinem Boot-Kommando hinzu, was dazu führte, daß Knoppix mit einem schwarzen Bildschirm unter X startete. ttys 1 bis 6 funktionierten noch als reine Textschnittstellen.

Ein paar Tage später habe ich mir die Zeit genommen, die seltsame Videooption zu entfernen, so daß der Boot-Befehl mit dem von Knoppix übereinstimmt. Beim Versuch zu booten, meldete Knoppix eine Art von LZMA-Korruption.

Das führte zum aktuellen Problem

Ich dachte, die Knoppix-Dateien könnten irgendwie beschädigt worden sein, also versuchte ich, es neu zu laden. Das Laufwerk war fast voll (45MB frei), also löschte ich ein generisches ISO, das ebenfalls nicht bootete. Das ging gut. Dann ging ich durch YUMI, um Knoppix zu ‘deinstallieren’, d.h. Dateien zu löschen und aus den Menüs zu entfernen. Die Dateien gingen zuerst, dann wurden die Menüs erfolgreich gelöscht. Allerdings blieb der freie Speicherplatz bei etwa 700 MB hängen, genauso wie vor dem Entfernen von Knoppix. Im alten Knoppix-Ordner befand sich eine 0-Byte-Datei namens KNOPPIX, die nicht gelöscht werden konnte.

Ich habe versucht, das Laufwerk wieder einzulegen, um diese Datei zu löschen - ohne sie sicher zu entfernen, falls das einen Unterschied machte (hey, es gibt für alles ein erstes Mal). Das Ausführen der Standard-Windows-Überprüfung chkdsk ohne /r oder /f meldete gefundene Fehler. Das Ausführen mit /r ließ ihn einfach stecken.

Ich beschloss, es mit fsck zu versuchen, also lud ich meine Kubuntu-VM und schloss das Laufwerk mit dem USB-2.0-Passthrough von VirtualBox an. Ich wählte umount (/dev/sda1) und führte einen fsck durch. Ich wählte There are differences between boot sector and its backup.. Es sagte mir, dass sich die FATs unterscheiden und bat mich, entweder die erste oder die zweite FAT auszuwählen. Unabhängig davon, welche ich auswählte, bekam ich die Meldung No action. Wenn ich Free cluster summary wrong wählte, gab es eine Liste mit falschen Dateinamen. Um zumindest zu versuchen, etwas zu reparieren, führte ich es mit der Option Correct aus. Auf halbem Weg durch die Korrektur der Dateien fror die VM ein - ich beendete den Prozess etwa zehn Minuten später.

Ursache?

Mein nächster Versuch war, wieder YUMI zu verwenden, um das gesamte Laufwerk neu zu erstellen. Ich verwendete die in YUMI eingebaute Option zum Neuformatieren (nach FAT32) und installierte ein Kubuntu-ISO (700MB). Das Formatieren war erfolgreich, aber das Entpacken und Kopieren von Kubuntu (wofür YUMI ein 7zip-Binary verwendet) fror bei etwa 60% ein. Nachdem ich etwa fünfzehn Minuten gewartet hatte (länger als das 3,5GB Knoppix-ISO beim letzten Mal brauchte), zog ich das Laufwerk heraus. Das Laufwerk war zu diesem Zeitpunkt bereits formatiert, SYSLINUX bereits installiert, es wartete nur noch auf das Entpacken eines ISOs und das Anpassen der Bootmenüs.

Als ich das Laufwerk wieder einsteckte, funktionierte es normal - allerdings schlug jeder Schreibvorgang fehl. Die Datenträgerverwaltung meldete, dass er nur gelesen werden kann. Nach dem erneuten Anschließen funktionierte er wieder normal, aber ein Schreibvorgang führte dazu, dass er wieder als schreibgeschützt angezeigt wurde. Nach ein paar Versuchen wurde sie beim Einlegen wieder als schreibgeschützt angezeigt.

Versuche zur Behebung von

Hier habe ich die oben aufgelisteten Versuche durchlaufen, um zu versuchen, es im Falle eines fehlerhaften Formats neu zu formatieren. Die Unfähigkeit, dies selbst auf einer bootfähigen Platte zu tun, deutet jedoch darauf hin, dass etwas Ernsteres nicht stimmt. -p meldet jetzt, dass nichts falsch ist, und chkdsk meldet immer noch MBR-Inkonsistenzen, wählt aber jetzt immer automatisch die erste FAT, nachdem es mir gesagt hat, dass sich die FATs unterscheiden. Danach macht es immer noch das gleiche fsck. Ich kann nicht mehr mit Free cluster summary wrong laufen, weil es jetzt als schreibgeschützt markiert ist. Es hat auch geschafft die Festplatte meiner VM beim ersten Versuch irgendwie beschädigt (ja, ich bin sicher, dass ich sda gewählt habe, die auf ein 7,4-GB-Laufwerk abgebildet ist - ich habe es dreimal überprüft). Gott sei Dank für Snapshots?

Ich habe so gut wie keine Ideen mehr. Für meinen unerfahrenen Verstand sieht es so aus, als ob irgendetwas in der Firmware des Laufwerks es irgendwie “permanent” auf “nur lesen” eingestellt hat - gibt es eine Möglichkeit, dies zurückzusetzen? Es ist mir nicht besonders wichtig, die Daten zu behalten, da ich das Laufwerk bereits zweimal neu formatiert habe.

Außerdem sind Korrekturen, die mich in Windows halten, besser; es reduziert das Risiko, dass ich versehentlich meine Hauptfestplatte vernichte.

Update 1:

Ich habe das Laufwerk aus Neugierde auseinandergenommen.

Wie Sie sehen können, gibt es keine offensichtlichen Schreibschutzschalter. Auf der anderen Seite befindet sich ein IC der Marke ALCOR mit der Bezeichnung AU6989HL, falls das eine Rolle spielt. Wenn es keine Möglichkeit zu geben scheint, das Problem zu beheben, werde ich wahrscheinlich die (eingeklebte) Karte herausziehen und in ein Kartenlesegerät stecken, um zu prüfen, ob es die Karte oder der Controller ist, der gestorben ist.

Update 2:

Ich habe die Karte herausgezogen, Windows erkennt das Laufwerk jetzt als Kartenleser. Die Kontakte auf der Karte scheinen nicht benutzt zu werden, und auf der Karte selbst befinden sich mehrere Reihen von Löchern. Wenn Sie die Karte in den Kartenleser stecken, werden nur etwa 30 MB erkannt, und zwar im RAW-Format. Wahrscheinlich meldet entweder das ursprüngliche Laufwerk die Karte fälschlicherweise als defekt (als ob der Schreibschutz einer echten SD-Karte eingeschaltet wäre) oder es ist irgendwo ein schlechter Kontakt.

Zumindest habe ich jetzt eine 8GB-Micro-SD-Karte als Ersatz… sobald ich herausgefunden habe, wie ich sie als 8GB formatieren kann. Was nicht möglich zu sein scheint (Windows, Partedmagic, -p, DBAN… nö, immer noch 30MB). Na ja.

Update 3

Ich hatte noch ein paar mehr von diesen. Der zweite ist heute ähnlich ausgefallen (nur lesend). Von den verbleibenden wurden zwei als leere Kartenleser/unformatierte Laufwerke erkannt, je nach Erschütterung (defekter Kontakt?). Eines wurde als 1/3 voll erkannt und hatte einen seltsamen Volume-Namen.

H2testw Ergebnisse (auf dem letzten voll funktionsfähigen, das ich habe!):

Während dies ein wenig beunruhigend ist, haben die Laufwerke offensichtlich tatsächlich eine Kapazität von fast 8 GB, wie von einem Tool verifiziert wurde, das oft erfolgreich zum Aufspüren gefälschter Flash-Laufwerke verwendet wird. Die Verwendung einer Micro-SD-Karte anstelle eines markierten Flash-Speichermoduls macht es nahezu unmöglich, das Laufwerk neu zu flashen, da Alcors Tools zum Flashen von Laufwerken das Speichermodell als Parameter erwarten. Ich denke, ich werde einfach alles wegwerfen.