File system interoperability in multiple boot environments. CHKSDSK / AUTOCHK and unexpected NTFS dirty bit

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.

* Please try a lower page number.

* Please enter only numbers.

* Please try a lower page number.

* Please enter only numbers.

I have noticed this as well. Also, due to the way Windows 10 likes to update preview builds, I would not recommend dual booting Windows 7 at this time. I just had it thrash \Users and \Windows in my Windows 7 install on a separate drive. I would have 7 & 10 installed to separate drives, and have the alternate drive disconnected or disabled when running the other OS.

FYI, reparse records are not an indication of a problem with an NTFS filesystem, they are specific type of MFT entry and they are normal

 At least I was not dreaming !  I did not see reparse issues until Windows 10, so I am now wondering whether Windows 7 might have disrupted the $MFT on the Windows 10 volume.

Just in case for the ones who multiboot with Windows 10 for whatever reason, just a list of useful commands, most of which have to be issued from Administrative command prompt :

Disable autochk/chkdsk on c: and d: drive upon boot if dirty bit is found :

chkntfs /x  c: d:    

(beware that the command will override the previous one, so for instance if you issue chkntfs /x  d: and then chkntfs /x  c:  it will check d: next time around)  

Increase countdown time 30 seconds to waive autochk/chkdsk upon boot if dirty bit is found :

chkntfs /T:30  

Find the current status of autochk/chkdsk :

reg query "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager" /v BootExecute

/k =exclude, /P =unconditional volume, /p =unconditional volume mount point, /m =chkdsk if dirty bit

Find the current status of dirty bit on drive c:

fsutil dirty query c:

Run chkdsk in read-only mode to see if the dirty bit is false in relation to the current OS :
chkdsk c:

Check NTFS version and $MFT positioning data on drive c :

fsutil fsinfo ntfsinfo c:

Note that Windows 7, 8.x & 10 all are NTFS version 3.1 and LFS version 2.0

so this aspect Windows 8 NTFS compatibility with prior versions might not be at stake. 

Hoping no one will experience unexpected data loss issues from this point.

FYI I did an experiment (definitely don't play with this as your volume is unlikely to be bootable), after ensuring that there was no dirty bit and chkdsk reported no issues for both drives from Windows 7 and Windows 10 :

1) I booted Windows 10

2) I created a file on the Windows 7 drive

3) I queried the Windows 7 drive and it showed no dirty bit

4) I validated the above by running a "read-only" chkdsk and that's the result :

D:\>chkdsk d:
The type of the file system is NTFS.
The volume is in use by another process. Chkdsk
might report errors when no corruption is present.
Volume label is Kingston.

WARNING!  F parameter not specified.
Running CHKDSK in read-only mode.

Stage 1: Examining basic file system structure ...
Deleted corrupt attribute list entry
with type code 128 in file 58942.
Attribute record (128, $J) from file record segment 88359
is corrupt.
  203776 file records processed.
File verification completed.
File record segment 88359 is an orphan.
  819 large file records processed.

Errors found.  CHKDSK cannot continue in read-only mode.

D:\>fsutil dirty query d:
Volume - d: is NOT Dirty

5) I tried to boot Windows 7 and it does not go beyond the login step. No built-in repair option has gotten around the issue. (FYI I cloned the GPT volume beforehand, well aware of the UEFI BCD store aspects with clones and I have all my data in other locations). 

Then I USB-mounted the SSD on a Windows 7 computer and chkdsk finds no problems. 

So it's now a matter of rebuilding the dual boot ecosystem, including BCD store reconstruction, UEFI tweaks etc....

Also I NTFS-formatted a USB flash drive from Windows 10, copied a few files, then mounted it on a Windows 7 machine, copied files and chkdsk was fine. I then did the reverse and was fine, so I wonder whether the issues have to do with boot-related structures. I had no issues with exFAT on the thumb drive as well. (I did not test REfs as I skipped Windows 8.1)


You replied in my post about constant chkdsks. This is very useful information; thank you.

I was also having this problem on 9879. My Windows 7 partition is always dirty but chkdsk comes out clean.

Glad I don't see this problem I am running triple boot win 7,8.1 and 10 but on a single disk and so far no problems but it also is not a ssd nor multiple disks

As long as you don't access another partition (or volume) from Windows 10, you are fine. 

The danger is when you try to access data between OS partitions with somewhat incompatible formats. 

When I have time, I'll try to experiment with exFAT and FAT32 just to see if the issue is restricted to NTFS.

Maybe the writing is on the wall about making the leap of faith to Windows 10 while keeping data on the cloud, but where I saw some drawbacks with 9926 in relation to previous builds, such as  file system transaction log when installing VC++ 2005 redist, the single instance calculator that no longer has dates calculations, statistics or RoR programmer function and the included WHQL Intel Iris Graphics driver not doing better than 8bpc (where Windows supports deep color natively since Vista !), I did not feel like making the complete switch yet.

I resolved the VC++2005 issue and used the multiple instance calculator from prior build, and the main reason I go to Windows 10 is because transitioning from 4k to 8k display. 

I will have to check win 7 partition but have accessed my win 8.1 partition under users and had to provide admin privilege to get where I wanted to be but all I did was copy files from there I did not try to send files there all partitions are ntfs  something else to experiment with. I am behind times I am not even to 4k yet<G>

The fact that you read files on the other partition requires to change ACLs (if you do a cacls of a file you read and the one you did not, you'll see the different auhorities), so essentially you wrote on the 8.1 partition, but only ACLs, so this is not too critical IMHO. If you boot Windows 8.1, check if you have a dirty bit, and if you see one, then just do a chkdsk c: with no parameter to see if the bit is true. It seems to me that if chkdsk finds it's not true, it resets it. 

Let me know ; it's possible that NTFS 8.1 NTFS might be more compatible. 

Right you are on the cacls I did a "fsutil dirty query C:"  when I was in 8.1 and it said not dirty and that  was after  a file I sent from 10 partition while running TP 10 to 8.1 partition I will try on 7 tomorrow it is almost 1 am and I have to work in the morning.

Running W10 and W7 on separate physical hard drives.  I was passing MS Outlook PST files between the two previously.  First time on 9926 from W10 to W7 the file was corrupt under W7.

Using Paragon HDM15S, tried to pull the PST files from an VHD made in 9879 prior to the update.  I was getting file architechture mismatch.  Tried to a USB flash drive and got some sort of attribute error.  I was reading this thread and formatted the flash drive to NTFS and that worked.  Before that coping the files from W10 to the flash drive with FAT32 worked.

Sometime during the event I tried to restore from the 9879 VHD to the W7 which caused a boot into a blue screen showing it wasn't a registered W7 copy!  Booted from a  WinRE disk and found a two day old restore point, back in business.

I've been passing files back/forth using a USB flash drive with no BSODs or DSKCHK but there was that KB3035129 that addressed some conflicts.

Could it be the fast startup option which is on by default which causes your dual boot problems?

Have a look:

* Please try a lower page number.

* Please enter only numbers.

* Please try a lower page number.

* Please enter only numbers.


Discussion Info

Last updated October 27, 2020 Views 9,661 Applies to: