I can read an NTFS file system on an SSD with Linux but not Windows

[mikeymikec]

I'm kinda stumped for how to proceed with this one. Windows 10 clean-installed on an SSD (Samsung 860 EVO) ran into problems and automatic repair doesn't fix the problem.

Where it really gets interesting is that:

1 - booting from Windows setup media results in one CPU core being saturated with no activity, no discernable storage activity in that time, forever (I left it for over an hour).
2 - connecting the drive to another PC via USB and Windows 10 also results in core saturation, but nothing in the event log to give any clues.
3 - connecting it to another PC running Linux (same USB enclosure), Linux can read the NTFS file system just fine (I backed up user data, nothing untoward in dmesg). SMART stats look ok.

I took a copy of the Windows system log while in Linux and hooked it up to the Windows event viewer. A BSOD or two had happened lately (stuff like SYSTEM_SERVICE_EXCEPTION), disk warnings pointing to disk 0, but nothing particularly interesting.

I have two theories:

1 - faulty SSD
2 - Mangled NTFS file system in such a way that causes Windows to crap itself but not Linux.

The first theory kinda falls down on Linux being as happy as a clam reading the disk. The second theory is possible, but I've never seen it happen.

Right now I just tried connecting the SSD back to its original PC and firing up Macrium Reflect off CD in the hope of getting an option to run say chkdsk on the volume, but it looks like I won't get any further with that idea (same symptoms, core saturation, cmd hanging when trying to change to the NTFS volume, I've started a full chkdsk on it but no chkdsk output has appeared).

One other thought - I could take a disk image of the NTFS partition, but how can I convince Windows to run a chkdsk on it without running into the same problem?

 

[mikeymikec]

Update:

Huh. I booted from a Win7 DVD, so far it's absolutely happy in talking to the NTFS partition. I ran a read-only chkdsk which reported no issues, now I'm running the full chkdsk. I'm not happy about running Win7 chkdsk against a Win10 installation because I've seen it throw odd warnings before, but I guess if it didn't mangle the FS then it can't be that bad?

 

[SamirD]

Well, the good thing is that you can access the partition and all the information just fine.

I would just back up all the data off of it and then completely reformat it and then check it using samsung's ssd tool and make sure it passes everything there.

 

[mikeymikec]

In case anyone was interested in an update: Once Windows was booting again, the only consistent symptom I had to work with were disk errors, complaining that the attempt to read/write to the drive was retried. I tried it in another computer and found I'd get the same warning if I installed Win10 1607, updated to 19xx then copied the customer's ~150GB of data back on to the drive.

However, both the computer with the issue to begin with and the spare PC were AMD AM3 systems (the spare was a chipset generation newer, the 800 series compared to the first being the 700 series). I contacted Samsung and they said to expect issues like this with any AMD chipset older than 2017, their suggestion was to add a registry key that disables NCQ in the standard MS AHCI driver.

The IO retry didn't occur after that, though I did get Windows asking to auto-check the drive once on startup way after that change was made (I even did a new clean install, adding that key in at the soonest opportunity).

So maybe the problem is fixed.

It's interesting though that I haven't had a single other AM3 system I've built with this issue with the Samsung 860 series added, though this was the only machine with an 860 EVO (I normally recommend the PRO).

 

[SamirD]

Odd for sure. I wonder if you would get the error if you run it native/legacy versus ahci? The last time I heard of an ncq issue like this was on the intel ss4200-e nas unit and certain hard drives, but this was due to a linux driver in the nas kernel.

 

[mikeymikec]

Their other suggestion was to run it in IDE mode.

 

[SamirD]

Their other suggestion was to run it in IDE mode.

I would do it--for booting and just regular stuff, you're not really going to notice the difference.

 

[mikeymikec]

I would do it--for booting and just regular stuff, you're not really going to notice the difference.

I was reticent to because I'm rusty on all the benefits of AHCI (for example, I had completely forgotten about NCQ despite having a major run-in about ten years ago with an nforce system that couldn't handle it quite properly leading to a pig of an intermittent issue).

 

[VirtualLarry]

You've done the obvious, and replaced the SATA cable? I didn't see that explicitly mentioned.

 

[mikeymikec]

I think I might have temporarily swapped out the cable during the test on the original system, but considering the problem occurred in another system with different power/cables, I doubt it's that.