For the moment this is just a warning and I waited to try Windows 10 build 9926 to see whether the symptom would disappear and as have seen others posting comparable concerns on the web, I thought of sharing this preoccupation.
I have been dual-booting Windows 7 and Windows 10 with two separate SSD and whenever I switched back to Windows 7 from previous Windows 10 builds like 9860, and then going back to Windows 10, autochk started correcting various entries, such as the bootex.log in index $I30 of file 5 (root dir), or deleting numerous extended attribute sets based on simultaneous existence of reparse point, numerous deletions of index entries from index $SDH of file 9 ($Secure). Then after another "excursion" to Windows 7, I had more corrupt attributes upon starting Windows 10, losing a profile, yet I always activate the Administrator account right upon installing Windows, so I could still use Windows 10.
The SSD are relatively new and I only encountered the issue when switching between OS, never during successive boots of same OS.
Note that the SSD where I have Windows 10 is MBR-partitioned and the one with Windows 7 is GPT-partitioned.
Also I have been accessing files residing on the disk with Windows 7 while in Windows 10, incurring ACLs updates.
In preparation for the (clean) installation of Windows 10 build 9926, I turned off disk checking in Windows 7 for both C: & D: manually checking dirty bit status of both drives upon booting.
I shut down Windows 10 last night and then this morning started Windows 7, seeing autochk 2 seconds default countdown for the booted Windows 7 (C: drive). I interrupted this right away and queried the dirty bits and both drives were dirty, even though chkdsk (read-only) run from Windows 7 only shows the Windows 10 drive having EA reparse issues.
I have not come across a situation where my Windows 7 drive would have a dirty bit since I started previewing Windows 10 last October 1st, but the main reason I post this is so that previewers in multiple boot environments are aware that there might be a concern for data integrity.
Hopefully someone is looking at Windows 10 build 9926 NTFS recoverability, hoping also it's backward compatible (at least with Windows 7 NTFS version).
Meanwhile I'll take a look at the physical sectors at stake (boot record, BPB, bootstrap code, MFT, dirty bit position and NTFS 55 timings) to see whether the might be architectural differences. Whereas I did not have much concerns with Windows 10 overall so far, except maybe the 9926 calc.exe that's single instance and no longer offers date calculations, stats, or RoR in programmer functions, but at least I can use calc.exe of previous builds or Windows 7, this could be a scary issue.
This is only an FYI so that multiboot testers can take the necessary precautions.
So if you see a dirty bit when booting Windows 10 or Windows 7, perform a read-only chkdsk on the system drive (no parameter) to see whether the dirty bit is legitimate or not. AFAIK, the "read-only" chkdsk will clear the dirty bit.
If you see a dirty bit on the other OS drive, boot from the other OS and perform a read-only chkdsk ; that will give you a better appreciation.
