Check disk on Win 10 SSD

Megahertz said:

I did not disable fast start.
Hibernation is of (powercfg -h off), so I suppose fast start is off.



I have tested in many ways (My main Win 7, my backup Win 7 and Win7PE). Same results.



chkdsk don't scan a OS or whatever is on the partition. It scans data structure and for what I know, Win 7 NTFS is the same as Win 10 NTFS.

I'm not sure that's correct. I would probably search for whether NTFS and/or disk structure (sectors, clusters, blocks, etc.), is identical.

I keep coming back to this, because I can't see any other way to explain the results you're getting.


Whatever you or I believe is not the issue here. The issue is that you get different results when running Win 7 chkdsk than you do when running Win 10 chkdsk. You need to "start" from there, when troubleshooting this problem.

I'm just trying to "guess" why you're getting different results.
If as you say... there's no difference between the NTFS or disk, structure... then you should be getting the same results.

But you could be correct, and then there still has to be "some" difference, or the results would be the same.

Ghot said:

I'm not sure that's correct. I would probably search for whether NTFS and/or disk structure (sectors, clusters, blocks, etc.), is identical.

I keep coming back to this, because I can't see any other way to explain the results you're getting.

You're right.
I was reading NTFS - Wikipedia and on the Journaling it says:

NTFS is a journaling file system and uses the NTFS Log ($LogFile) to record metadata changes to the volume. It is a feature that FAT does not provide and critical for NTFS to ensure that its complex internal data structures will remain consistent in case of system crashes or data moves performed by the defragmentation API, and allow easy rollback of uncommitted changes to these critical data structures when the volume is remounted. Notably affected structures are the volume allocation bitmap, modifications to MFT records such as moves of some variable-length attributes stored in MFT records and attribute lists, and indices for directories and security descriptors.

The ($LogFile) format has evolved through several versions: Win 7 and below uses $LogFile format version 1.1 and Win 8 and above use $LogFile format version 2.0
The incompatibility of the $LogFile versions implemented by Windows 8, Windows 10, Windows 11 prevents Windows 7(and earlier versions of Windows) from recognizing version 2.0 of the $LogFile.
Backward compatibility is provided by downgrading the $LogFile to version 1.1 when an NTFS volume is cleanly dismounted. It is again upgraded to version 2.0 when mounting on a compatible version of Windows.
However, when hibernating to disk in the logoff state (a.k.a. Hybrid Boot or Fast Boot, which is enabled by default), mounted file systems are not dismounted, and thus the $LogFiles of any active file systems are not downgraded to version 1.1.
The inability to process version 2.0 of the $LogFile by versions of Windows older than 8.0 results in an unnecessary invocation of the CHKDSK disk repair utility. This is particularly a concern in a multi-boot scenario involving pre- and post-8.0 versions of Windows, or when frequently moving a storage device between older and newer versions. A Windows Registry setting exists to prevent the automatic upgrade of the $LogFile to the newer version. The problem can also be dealt with by disabling Hybrid Boot.

The USN Journal (Update Sequence Number Journal) is a system management feature that records (in $Extend\$UsnJrnl) changes to files, streams and directories on the volume, as well as their various attributes and security settings. The journal is made available for applications to track changes to the volume.[52] This journal can be enabled or disabled on non-system volumes.

@Megahertz

Give yourself a gold star.

Other things I found... when googling.

MBR vs GPT
Fast boot and hibernation

Thanks to all who suggested something to find out a solution.

I'm setting this thread as solved.