Broken NTFS drive but no error in SMART, CHKDSK or F3?

I've got a Windows 10 installation which always crashes a few minutes after boot-up.

I already checked the drive using SMART, chkdsk, Fight Flash Fraud and clamav. No errors at all. I also checked the hardware thoroughly and cannot find any problems.

But there are some odd problems on the drive which I cannot figure out:

When I mount the drive from linux and try to read the content using tar, I get a lot of messages like these:

tar: Windows/System32/davhlpr.dll: Cannot stat: Input/output error
tar: Windows/System32/daxexec.dll: Cannot stat: Input/output error
tar: Windows/System32/dbgcore.dll: Cannot stat: Input/output error

This error leads to installing ntfs-3g-compressed, which does not exist any more and should be included into ntfs-3g... So the cause is something else.

Now I tried to copy the content from a different Windows 10 installation (in VirtualBox). Windows tells me "unexpected error 0x80070032" which is totally unrelated to copying files. according to microsoft:

This error code is triggered when you try to set an external hard disk as your backup location. The issue can also occur when you're trying to install a major update to your Windows 10. The update relies on files that can be accessed from a direct download from Microsoft or an automatic update through the Windows Update. The error code 0x80070032 arises when you are trying to activate the Automatic File Backups setting. This option is located in the settings menu under the backup option. When you restart your PC to accept the changes made, the update fails to activate, thus the error code 0x80070032 appears.

How come chkdsk does not find any error even if run with /r?

I recently replaced the power cord to SATA drive, but this did not help. Might the bad power cable have caused the filesystem mess?

Solution was to reinstall Windows. No Hardware issues at all. The problem was a bad filesystem which wasn't bad according to chkdsk. Windows sucks. Windows 10 even more. I thought this should not happen with today's Journaling filesystems, and tons of recovery mechanisms.