I boot either from a Win7 system drive or a Win10 system drive from a mobile rack. When I am using either OS, I can access a third permanently installed data drive. There has never been any problem. This weekend I upgraded my Win10 mobile drive to Creators and Fall Creators updates. I played around in Win10 and everything looked fine. Then I switched to my Win7 drive and before Windows came up it wanted to do a consistency check of the data drive. It did, but also did a check of all the drives in my system (some RAID and SSD drives, which are currently all empty). Chkdsk found a bunch of errors that I will mention below in another case. I manually ran chkdsk on the data drive using the /f /r options, and the disk was fine. Then I switched back to my Win10 system drive and again it wanted to run a consistency check on the data (and all) drives. This time there were even more problems with the data drive, and some files were even lost. Fortunately the data drive only has about 90GB of data on it. But here is a sample of the things it reported: CHKDSK is verifying files (stage 1 of 3)... Deleted corrupt attribute list entry with type code 144 in file 9. Unable to locate attribute of type 0x90, lowest vcn 0x0, instance tag 0x7 in file 0xec7. Deleted corrupt attribute list entry with type code 160 in file 9. Unable to locate attribute of type 0xa0, lowest vcn 0x0, instance tag 0x9 in file 0xec7. Deleted corrupt attribute list entry with type code 160 in file 9. Unable to locate attribute of type 0xa0, lowest vcn 0x0, instance tag 0x6 in file 0xec7. Deleted corrupt attribute list entry with type code 176 in file 9. Unable to locate attribute of type 0xb0, lowest vcn 0x0, instance tag 0x8 in file 0xec7. Unable to locate attribute with instance tag 0xf and segment reference 0x27000000000ec7. The expected attribute type is 0x90. Deleting corrupt attribute record (144, $SDH) from file record segment 3783. Unable to locate attribute with instance tag 0x11 and segment reference 0x27000000000ec7. The expected attribute type is 0xa0. Deleting corrupt attribute record (160, $SDH) from file record segment 3783. [...] CHKDSK is verifying indexes (stage 2 of 3)... The index bitmap for index $SII in file 0x9 is invalid or missing. The index bitmap for index $SII in file 0x9 is invalid or missing. The index bitmap for index $SII in file 0x9 is invalid or missing. The index bitmap for index $SII in file 0x9 is invalid or missing. Correcting error in index $SII for file 9. The index bitmap $SII is present but there is no corresponding index allocation attribute in file 0x9. Correcting error in index $SII for file 9. The down pointer of current index entry with length 0x30 is invalid. 14 00 14 00 00 00 00 00 30 00 04 00 01 00 00 00 ........0....... 44 01 00 00 54 7d 23 ff 44 01 00 00 20 3c 00 00 D...T}#.D... <.. 00 00 00 00 d4 00 00 00 ff ff ff ff ff ff ff ff ................ 14 00 14 00 00 00 00 00 30 00 04 00 01 00 00 00 ........0....... Sorting index $SII in file 9. Unable to locate the file name attribute of index entry Then using VE - Drive_CD checked.png of index $I30 with parent 0x34 in file 0x19cb. Deleting index entry Then using VE - Drive_CD checked.png in index $I30 of file 52. Unable to locate the file name attribute of index entry THENUS~2.PNG of index $I30 with parent 0x34 in file 0x19cb. Deleting index entry THENUS~2.PNG in index $I30 of file 52. The index bitmap $I30 in file 0x46 is incorrect. Correcting error in index $I30 for file 70. The file reference 0xf56000000000f55 of index entry 0x6DEC0471FF0A7A4A of index $I30 with parent 0xc4 is not the same as 0x19000000000f55. Deleting index entry 0x6DEC0471FF0A7A4A in index $I30 of file 196. The file reference 0xf56000000000f55 of index entry 0X6DEC~1 of index $I30 with parent 0xc4 is not the same as 0x19000000000f55. Deleting index entry 0X6DEC~1 in index $I30 of file 196. Unable to locate the file name attribute of index entry T2886E~1.MRI of index $I30 with parent 0xc0a in file 0x19c7. [...] CHKDSK is scanning unindexed files for reconnect to their original directory. Recovering orphaned file Chkdsk20171030081425.log (49) into directory file 18. Recovering orphaned file MANIFE~1 (3922) into directory file 3861. Recovering orphaned file Manifests (3922) into directory file 3861. Recovering orphaned file 670006~2.BIN (3924) into directory file 7424. Recovering orphaned file 6700069d9d4e5c7145e1aa8fc78892f0_fce8395c8fd8a98f_c96174849e9e4520_0_0.bin (3924) into directory file 7424. Recovering orphaned file $IBLNG~1.MRI (3926) into directory file 2878. Recovering orphaned file $IBLNGCR.mrimg (3926) into directory file 2878. Recovering orphaned file CHROME~1.LOG (3927) into directory file 70. Recovering orphaned file chrome_installer.log (3927) into directory file 70. Recovering orphaned file DRIVE_~1.PNG (6603) into directory file 52. Recovering orphaned file Drive_CD using VE.png (6603) into directory file 52. Recovering orphaned file X86_FS~1.0 (6605) into directory file 3861. Recovering orphaned file x86_fsplugin07.dll@1.0.0.0 (6605) into directory file 3861. Recovering orphaned file X86_FS~2.0 (6608) into directory file 3861. Recovering orphaned file x86_FSViewer.exe@1.0.0.0 (6608) into directory file 3861. Recovering orphaned file X86_NU~1.0 (6611) into directory file 3861. Recovering orphaned file X86_Nullsoft.NSIS.exehead@1.0.0.0 (6611) into directory file 3861. Recovering orphaned file X86_YO~1.0 (6614) into directory file 3861. Recovering orphaned file x86_Your.Application.Name.Here@1.0.0.0 (6614) into directory file 3861. 12 unindexed files scanned. Recovering orphaned file !WINDO~1 (7587) into directory file 7588. Recovering orphaned file !Windows 10 - Test (7587) into directory file 7588. CHKDSK is recovering remaining unindexed files. 1 unindexed files recovered. CHKDSK is verifying security descriptors (stage 3 of 3)... Creating index $SDH for file 9. Inserting an index entry with Id 256 into index $SII of file 9. Inserting an index entry with Id 257 into index $SII of file 9. Inserting an index entry with Id 258 into index $SII of file 9. Inserting an index entry with Id 260 into index $SII of file 9. Inserting an index entry with Id 261 into index $SII of file 9. Inserting an index entry with Id 262 into index $SII of file 9. Inserting an index entry with Id 263 into index $SII of file 9. Inserting an index entry with Id 264 into index $SII of file 9. Inserting an index entry with Id 265 into index $SII of file 9. Inserting an index entry with Id 266 into index $SII of file 9. Inserting an index entry with Id 269 into index $SII of file 9. Inserting an index entry with Id 270 into index $SII of file 9. Inserting an index entry with Id 271 into index $SII of file 9. Inserting an index entry with Id 272 into index $SII of file 9. Inserting an index entry with Id 273 into index $SII of file 9. Inserting an index entry with Id 275 into index $SII of file 9. Inserting an index entry with Id 282 into index $SII of file 9. Inserting an index entry with Id 283 into index $SII of file 9. Inserting an index entry with Id 284 into index $SII of file 9. I have not put any data on any of the other data drives in the computer to see what happens when I switch back and forth between Win7 and Win10. But it looks like at this point the problem may be due to the either one of the Creator Updates to Win10.
I dual boot 7 and 10 and only the first time windows 7 booted up it did a chkdisk, after that it never did it again.
I dual boot 7 and 10 LTSB on Dell E5430s and D630s with multiple partitions and never experienced an issue ...T
Not knowing what to do I started poking around. I noticed that the files that were being identified in the the forced chkdsk scans were recent files. So I created a new file on Drives E (a hard disk where most of the problems have been), G: (an SSD) and R: (an LSI RAID array). I also renamed a file on Drive F: (an SSD). I did this running Win7 Pro SP1. I then replaced Win7 with the Win10 mobile rack and the event log showed errors again such as "corruption was discovered in the file system structure" on Drive E: And the files I created on all the drives mentioned above were not visible. And the file I renamed still showed the original name, not the new name. So I went back and forth like this from Win7 to Win10 to Win7 a few times. I found errors using sfc /scannow on the Win7 disk, but not Win10. Eventually I saw the new files when running Win10 on Drives E: and G:, but not the RAID array R: And the file I changed the name was never updated. Under Win10 it shows the original name before I renamed it under Win7. The corruption is still happening between the two operating systems, but I am beginning to think Win7 Pro may be the problem. Obviously there is a problem writing and reading across the operating systems to a common disk, but I don't know where the problem lies. I was really hoping scannow would fix it.
Yes, fast boot is disabled in BIOS. To clarify something I said earlier: the reason I thought the problem was due to Win10 was because I had been using both Win7 and Win10 on this machine six months ago. I never ran into the file structure corruption errors. Then the machine sat unused for months. Last week I thought I would use the machine again, so I updated Win10 from v1607 Build 10.0.14393.693 to Build 10.0.14393.1770, and then v1703 and the latest version of 1709. I did nothing to the Win7 disk, although clearly it had problems with corrupted files which became clear when I ran sfc /scannow.
You hit the nail on the head, I think. Yesterday I thought I would give up on Win7 on this machine; I didn't really need it. Some of the software I want to run on this machine requires Win10. So it is time, I thought, to look forward and embrace Win10, at least on this machine. I reformatted the SSD that had Win7 on it. Then in the afternoon while I was cleaning up the Win10 drive, I noticed the file hiberfil.sys on the c: drive. I usually disable this routinely using the powercfg command, but I must have missed it when I was setting up the OS. Then I read your followup. I never really heard of fast startup, but it must have been enabled before I manually got rid of hiberfil.sys. I searched around and I did find reports of people complaining that fast start messed up files when dual booting. Thanks!