Kann ein Wechsel zwischen Win7 und Win10 (Creators) eine von beiden genutzte Datenplatte beschädigen?

Ich boote entweder von einem Win7-Systemlaufwerk oder einem Win10-Systemlaufwerk von einem mobilen Rack. Wenn ich eines der beiden Betriebssysteme verwende, kann ich auf ein drittes fest installiertes Datenlaufwerk zugreifen. Es hat noch nie ein Problem gegeben.

Dieses Wochenende habe ich mein mobiles Win10-Laufwerk auf Creators- und Fall Creators-Updates aktualisiert. Ich habe in Win10 rumgespielt und alles sah gut aus.

Dann habe ich auf mein Win7-Laufwerk gewechselt und wollte vor dem Start von Windows eine Konsistenzprüfung des Datenlaufwerks durchführen. Es hat aber auch eine Überprüfung aller Laufwerke in meinem System durchgeführt (einige RAID- und SSD-Laufwerke, die derzeit alle leer sind). Chkdsk hat eine Reihe von Fehlern gefunden, die ich unten in einem anderen Fall erwähnen werde. Ich habe chkdsk manuell mit den Optionen / f / r auf dem Datenlaufwerk ausgeführt, und der Datenträger war in Ordnung.

Dann wechselte ich zurück zu meinem Win10-Systemlaufwerk und wollte erneut eine Konsistenzprüfung für die Daten- (und alle) Laufwerke durchführen. Diesmal gab es noch mehr Probleme mit dem Datenlaufwerk und einige Dateien gingen sogar verloren. Glücklicherweise sind auf dem Datenlaufwerk nur etwa 90 GB Daten gespeichert. Aber hier ist eine Auswahl der Dinge, über die berichtet wurde:

CHKDSK is verifying files (stage 1 of 3)...
Deleted corrupt attribute list entry
with type code 144 in file 9.
Unable to locate attribute of type 0x90, lowest vcn 0x0,
instance tag 0x7 in file 0xec7.
Deleted corrupt attribute list entry
with type code 160 in file 9.
Unable to locate attribute of type 0xa0, lowest vcn 0x0,
instance tag 0x9 in file 0xec7.
Deleted corrupt attribute list entry
with type code 160 in file 9.
Unable to locate attribute of type 0xa0, lowest vcn 0x0,
instance tag 0x6 in file 0xec7.
Deleted corrupt attribute list entry
with type code 176 in file 9.
Unable to locate attribute of type 0xb0, lowest vcn 0x0,
instance tag 0x8 in file 0xec7.
Unable to locate attribute with instance tag 0xf and segment
reference 0x27000000000ec7. The expected attribute type is 0x90.
Deleting corrupt attribute record (144, $SDH)
from file record segment 3783.
Unable to locate attribute with instance tag 0x11 and segment
reference 0x27000000000ec7. The expected attribute type is 0xa0.
Deleting corrupt attribute record (160, $SDH)
from file record segment 3783.
[...]
CHKDSK is verifying indexes (stage 2 of 3)...
The index bitmap for index $SII in file 0x9 is invalid or missing.
The index bitmap for index $SII in file 0x9 is invalid or missing.
The index bitmap for index $SII in file 0x9 is invalid or missing.
The index bitmap for index $SII in file 0x9 is invalid or missing.
Correcting error in index $SII for file 9.
The index bitmap $SII is present but there is no corresponding
index allocation attribute in file 0x9.
Correcting error in index $SII for file 9.
The down pointer of current index entry with length 0x30 is invalid.
14 00 14 00 00 00 00 00 30 00 04 00 01 00 00 00 ........0.......
44 01 00 00 54 7d 23 ff 44 01 00 00 20 3c 00 00 D...T}#.D... <..
00 00 00 00 d4 00 00 00 ff ff ff ff ff ff ff ff ................
14 00 14 00 00 00 00 00 30 00 04 00 01 00 00 00 ........0.......
Sorting index $SII in file 9.
Unable to locate the file name attribute of index entry Then using VE - 
Drive_CD checked.png
of index $I30 with parent 0x34 in file 0x19cb.
Deleting index entry Then using VE - Drive_CD checked.png in index $I30 of 
file 52.
Unable to locate the file name attribute of index entry THENUS~2.PNG
of index $I30 with parent 0x34 in file 0x19cb.
Deleting index entry THENUS~2.PNG in index $I30 of file 52.
The index bitmap $I30 in file 0x46 is incorrect.
Correcting error in index $I30 for file 70.
The file reference 0xf56000000000f55 of index entry 0x6DEC0471FF0A7A4A of 
index $I30
with parent 0xc4 is not the same as 0x19000000000f55.
Deleting index entry 0x6DEC0471FF0A7A4A in index $I30 of file 196.
The file reference 0xf56000000000f55 of index entry 0X6DEC~1 of index $I30
with parent 0xc4 is not the same as 0x19000000000f55.
Deleting index entry 0X6DEC~1 in index $I30 of file 196.
Unable to locate the file name attribute of index entry T2886E~1.MRI
of index $I30 with parent 0xc0a in file 0x19c7.
[...]
CHKDSK is scanning unindexed files for reconnect to their original 
directory.
Recovering orphaned file Chkdsk20171030081425.log (49) into directory file 
18.
Recovering orphaned file MANIFE~1 (3922) into directory file 3861.
Recovering orphaned file Manifests (3922) into directory file 3861.
Recovering orphaned file 670006~2.BIN (3924) into directory file 7424.
Recovering orphaned file 
6700069d9d4e5c7145e1aa8fc78892f0_fce8395c8fd8a98f_c96174849e9e4520_0_0.bin 
(3924) into directory file 7424.
Recovering orphaned file $IBLNG~1.MRI (3926) into directory file 2878.
Recovering orphaned file $IBLNGCR.mrimg (3926) into directory file 2878.
Recovering orphaned file CHROME~1.LOG (3927) into directory file 70.
Recovering orphaned file chrome_installer.log (3927) into directory file 70.
Recovering orphaned file DRIVE_~1.PNG (6603) into directory file 52.
Recovering orphaned file Drive_CD using VE.png (6603) into directory file 
52.
Recovering orphaned file X86_FS~1.0 (6605) into directory file 3861.
Recovering orphaned file [email protected] (6605) into directory 
file 3861.
Recovering orphaned file X86_FS~2.0 (6608) into directory file 3861.
Recovering orphaned file [email protected] (6608) into directory file 
3861.
Recovering orphaned file X86_NU~1.0 (6611) into directory file 3861.
Recovering orphaned file [email protected] (6611) into 
directory file 3861.
Recovering orphaned file X86_YO~1.0 (6614) into directory file 3861.
Recovering orphaned file [email protected] (6614) into 
directory file 3861.
12 unindexed files scanned. 
Recovering orphaned file !WINDO~1 (7587) into directory file 7588.
Recovering orphaned file !Windows 10 - Test (7587) into directory file 7588.
CHKDSK is recovering remaining unindexed files.
1 unindexed files recovered. 

CHKDSK is verifying security descriptors (stage 3 of 3)...
Creating index $SDH for file 9.
Inserting an index entry with Id 256 into index $SII of file 9.
Inserting an index entry with Id 257 into index $SII of file 9.
Inserting an index entry with Id 258 into index $SII of file 9.
Inserting an index entry with Id 260 into index $SII of file 9.
Inserting an index entry with Id 261 into index $SII of file 9.
Inserting an index entry with Id 262 into index $SII of file 9.
Inserting an index entry with Id 263 into index $SII of file 9.
Inserting an index entry with Id 264 into index $SII of file 9.
Inserting an index entry with Id 265 into index $SII of file 9.
Inserting an index entry with Id 266 into index $SII of file 9.
Inserting an index entry with Id 269 into index $SII of file 9.
Inserting an index entry with Id 270 into index $SII of file 9.
Inserting an index entry with Id 271 into index $SII of file 9.
Inserting an index entry with Id 272 into index $SII of file 9.
Inserting an index entry with Id 273 into index $SII of file 9.
Inserting an index entry with Id 275 into index $SII of file 9.
Inserting an index entry with Id 282 into index $SII of file 9.
Inserting an index entry with Id 283 into index $SII of file 9.
Inserting an index entry with Id 284 into index $SII of file 9.<code>
[...]

Ich habe auf keinem der anderen Datenlaufwerke im Computer Daten gespeichert, um zu sehen, was passiert, wenn ich zwischen Win7 und Win10 wechsle. Es sieht jedoch so aus, als ob das Problem derzeit an einem der Creator-Updates für Win10 liegt.

Ist das möglich? Ich kann solche Fälle online nicht finden.

Es befinden sich keine Programme auf dem "Datenlaufwerk". Es sind nur Bilder, Filme, Textdateien usw.

Da ich nicht wusste, was ich tun sollte, fing ich an herumzustöbern. Mir ist aufgefallen, dass die Dateien, die bei den erzwungenen chkdsk-Scans identifiziert wurden, aktuelle Dateien waren. Also habe ich eine neue Datei auf Laufwerk E (eine Festplatte, auf der die meisten Probleme aufgetreten sind), G: (eine SSD) und R: (ein LSI-RAID-Array) erstellt. Ich habe auch eine Datei auf Laufwerk F umbenannt: (eine SSD). Ich habe das mit Win7 Pro SP1 gemacht.

Ich habe dann Win7 durch das Win10-Rack ersetzt und im Ereignisprotokoll wurden erneut Fehler angezeigt, z. B. "In der Dateisystemstruktur wurde eine Beschädigung festgestellt" auf Laufwerk E: Die Dateien, die ich auf allen oben genannten Laufwerken erstellt habe, waren nicht sichtbar. Und die Datei, die ich umbenannt habe, zeigte immer noch den ursprünglichen Namen, nicht den neuen Namen.

Also ging ich ein paar Mal so von Win7 zu Win10 zu Win7 hin und her. Ich habe Fehler mit sfc / scannow auf der Win7-Festplatte gefunden, aber nicht mit Win10. Ich habe die neuen Dateien, die ich auf der Datenfestplatte erstellt habe, beim ersten Wechsel zu Win10 nicht gesehen. Irgendwann sah ich die neuen Dateien, als Win10 auf den Laufwerken E: und G: ausgeführt wurde, und das liegt wahrscheinlich daran, dass chkdisk die Dateistruktur repariert hat. Aber ich habe die neue Datei auf dem RAID-Array R: noch nicht gesehen. Wenn ich zurück zu Win7 wechsle, sehe ich es dann. Und die Datei, deren Namen ich geändert habe, wurde nie aktualisiert. Unter Win10 wird der ursprüngliche Name angezeigt, bevor ich ihn unter Win7 umbenannt habe.

Die Beschädigung ist immer noch zwischen den beiden Betriebssystemen, aber ich fange an zu denken, Win7 Pro könnte das Problem sein. Offensichtlich gibt es ein Problem beim Schreiben und Lesen auf einer gemeinsamen Festplatte, aber ich weiß nicht, wo das Problem liegt. Ich hatte wirklich gehofft, dass scannow das Problem beheben würde.