Win 10 Ntfs stops talking to my external hard drive.

acconnel2

Reputable
Dec 13, 2015
2
0
4,510
Ok, I've got a Win 10 question. My husband is an avid amateur photographer. He was previously using a Vista machine to run Photoshop CS 5. We've been keeping all of his photos on big external drives, so I thought I could just plug them into the new Win 10 machine. After using CS 5 for a little while, 2T Hitachi drive was taking a long time to pull up a directory listing. I shut it down, unplugged it, rebooted, reconnected it, and the directory listing was fine. So, I immediately copied everything over to a new empty Seagate 5T drive that is supposed to be compatible with Win 10. Now the new drive is having issues also.

Checking back through the event log, Ntfs seemed to be doing some sort of background process that kicked out this log:

Ntfs log:

RepairDetail 25008: Start repair on 12/05/2015 at 19:00:31:506 25013: Processing repair verb BadFrs: 0x7000000000031 Flags: 0x32, 0x2100 25010: Marked file record 7000000000031 as in use in MFT bitmap. 25011:
Security Id 0x112 is invalid in file record segment 0x7000000000031. It will be replaced with an administrator only Security Id. 27295: The parent 0x100000000025a of file name attribute $R1I3ZC9 in file 0x7000000000031 cannot be found. 27293: File record 0x7000000000031 maps to "\HITACHI". 25009: End repair on 12/05/2015 at 19:00:31:537

--------------------
I plugged the drive into my Win 7 machine, and ran a complete Check disk on the entire 5T - yes it took a while. And I thought I'd re-try it on the Win10 box today.

Does anyone have any other suggestions?

I read somewhere that Win 10 has some sort of snooping function that will disable your drives if it perceives copywrited material on it, but EVERYTHING on this drive is the intellectual property of my husband.

If I can't get this drive to work, I will have to return the machine.

 
Doh!

Ok, I've spent several hours pouring over the logs again. Looks like this is the chronology for the Seagate 5T drive is this:

6 instances of Error event 131, then,

6 instances of Error event 66, then,

1 instance of Error event 98, then

6 instances of Error event 131, then,

6 instances of Error event 55, then,

1 instance of Error event 98

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

The first error, 6 instances of Error event 131, included this text:

RepairDetail 25008: Start repair on 12/08/2015 at 09:55:02:846 25013: Processing repair verb BadFrs: 0x7000000000031 Flags: 0x32, 0x2100 25010: Marked file record 7000000000031 as in use in MFT bitmap. 27293: File record 0x7000000000031 maps to "\Utah 2015\Powell Reflection DSC_1398_399_400_401_Photographic.jpg". 25009: End repair on 12/08/2015 at 09:55:02:981

This was followed by 6 instances of Error event 66, included the following text:

Description The Master File Table (MFT) contains a corrupted file record. The file reference number is 0x7000000000031. The name of the file is "\fscommand\locale\sp\sp_formatting_pc_mac.txt\$R1I3ZC9".

-- which seems to me to be fallout from the first error.
Then comes 1 instance of Error event 98, including this text:

Volume F: (\Device\HarddiskVolume6) needs to be taken offline to perform a Full Chkdsk.

-- which seems like a logical next step if the MFT is fouled up.


The next set of 6 instances of Error event 131, include this text:

RepairDetail 25008: Start repair on 12/09/2015 at 09:05:27:207 25013: Processing repair verb BadFrs: 0x7000000000031 Flags: 0x32, 0x2100 25010: Marked file record 7000000000031 as in use in MFT bitmap. 27293: File record 0x7000000000031 maps to "\New folder". 25009: End repair on 12/09/2015 at 09:05:27:238

Followed by 6 instances of Error event 55, including this language:

Description The Master File Table (MFT) contains a corrupted file record. The file reference number is 0x7000000000031. The name of the file is "\fscommand\locale\sp\sp_formatting_pc_mac.txt\$R1I3ZC9".


1 instance of Error event 98, including this language:
Volume F: (\Device\HarddiskVolume6) needs to be taken offline to perform a Full Chkdsk.
-- which makes sense.


So the question is, why would it need to "Processing repair verb BadFrs" if all that has been done is to copy files onto a new disk using a new computer, unless there is something fundamentally wrong.

I've run a complete CHKDSK on this drive -- what are the odds this happens again?

(Thanks for your time and consideration.)