I had Win 10 Enterprise running in a VM and decided to install it on a dedicated hard disk. The system is a Dell 3847 i5, 8GB Ram, 2-1TB drives. I cloned my daily Driver Win-7 Enterprise 64-Bit to the spare hard drive, so I would have all my files and disk structure on the new drive. Then formatted the cloned copy of Win-7 C:\ for installation of Win-10. Booted of Easy2Boot and installed Win-10 Enterprise 64-Bit, no problem. Installed Office and some other software. So far so good. At this point I decided to make an image of Win-10 installation so far. And that went fine. After the image was made I booted back to the Win-7 hard disk and check eMail and did some other stuff, and thought since the Win-10 disk was off line, I could run Chkdsk on it without having to do the re-boot thing. Big mistake. It got to 10% and then ticked off one error after another. Reparse points, and many others. I figured I'd let it run. After 30 minutes I tried to Ctrl-C out of Chkdsk. No response. I didn't want to close the window, so I just let it run. After about an hour it finished, with thousands of errors. Somewhat annoyed, I restored the Win-10 image and re-booted back into the Win-10 system, and ran Chkdsk /f /v from the Win-10 elevated Cmd prompt. It said it would run on the next re-boot, and I let it, and it didn't find any errors. So it looks like the Win-10 image was ok. One thing I notice throughout this whole episode, was that when I started up the Win-10 system there was heavy access to the Win-7 disk, even though it wasn't active, just a slave. Seemed a bit weird, but I didn't think anything of it. When I re-booted into the Win-7 system, I was greeted with "Windows has found errors on your hard disk, and needs to run Chkdsk to fix them" So I let it run, and everything seemed to come up OK, but I figured the Win-7 installation might have been hosed, so I restored it from an image just in case. As near as I can figure out, Win-7 Chkdsk isn't compatible with Win-10, and for some reason Win-10 will alter or somewhat hose up a Win-7 hard drive if is connected at the same time. Although this makes no sense because the secondary hard drive shouldn't have anything to do with anything. I guess the next step would be to set up a dual boot system as others have done. But I thought it would be less hassle, just to plug in a separate drive, and then boot from that drive if I wanted to run Win-10 and then just re-boot back to the Win-7 hard disk. Guess not. That way I could keep my Win-7 Enterprise Daily Driver system separate from the Win-10 setup. But it looks like the only way to do that is to physically disconnect the Win-7 drive, boot to Win-10 without the Win-7 disk connected. Not hard to do, but makes copying files between the two systems impossible. Anybody else have problems with Win-7 Chkdsk on Win-10 systems? .
thanks for the info, I had to do the shut down with shift key pressed to completely shutdown and do the press shift key then restart to restart and enter uefi/bios settings
It's pretty obvious that NTFS evolves over time and is better to avoid, if possible, to check a newer NTFS disk with an older OS. The point of the tip is to avoid that win 7 thinks that the FS is corrupt each time you dual boot from from w10 to win 7. Just disable the fast startup and check your disks once for all with w10. Then, if you want to scan MANUALLY, either use w10 chkdsk or scan with win7's chkdsk the w7 partitions alone. Aside the fast startup thing which is a w8+ behavior, the chkdsk rule is more or less valid with any couple of windows. Nt4 was even unable to chkdsk its own partition, after that partition was seen once by win2k (win2k upgraded silently the NTFS version of partitons created by older OSes)
i got both 7 and 10 for 4 days now and no major issues.. did have one when i plugged in a 2nd old win 7 hdd and it wanted to add boot entry of old mbr style disk on my GPT win 7 efi/10 partitioned
I would imagine that you are correct, and I'll follow your advice. I'll report back if any other weird things pop up, but I'm pretty sure the problem is solved. Thanks for everybody's input.
I'd just like to follow up after all the changes discussed above were made to the Win-10 setup. After turning of Fast Start and Hibernation and starting up the Win-10 hard drive with the Win-7 hard drive, there was no more excessive activity on the Win-7 hard drive. Running Chkdsk from the Win-10 drive on the 3 partitions showed no errors, and running Chkdsk on the Win-7 hard disk showed no errors either. So it's confirmed. Win-10 Chkdsk to Win-7 disk, OK. Win-7 Chkdsk to a Win-10 disk whether configured Fast Start or not, isn't compatible. Win-10 wanted to do some updates, and I let it, and then ran Daz' evil update batch file to see if any bad stuff was installed, and none showed up, although I think it was more Win-7 oriented. The Win-10 system is stable and runs all my programs with no problems. I'm pretty happy to be honest. Now all I have to do is to see what telemetry comes with Win-10 Enterprise and see if I can eradicate it. I'll run both systems for a while, and who knows, I might make Win-10 my daily driver. .
I don't think so. I faced some files, especially in W10 directory, that are unreadable even from w8.1, although perfectly accessible from W10 itself.
i know people who use win7 and win10 together with dual boot. i didnt hear anything like this from him.
Indeed is nothing of evident or easy to spot. Because hardly affects the data partitons/disks shared between different OSes, but try to copy the w10 windows.old folder using w7 somewhere else. And no, I'm not talking about permissions or about too long paths. I'm talking about dome files impossible to read/copy, just like happen when you have some FS errors. In short I think that MS made some subtle changes, leaving the W10 NTFS mostly backward compatible, but mostly is not 100%
Even if it was the case (and I think is not) a new kind permission not understood by an older OS, makes it not 100% compatible
Have them boot into Windows 7 and then run Chkdsk on the Windows 10 partition. When I did it I got over 2000 errors. Don't use the /F switch when you run Chkdsk.
I was thinking the same thing, although I believe that Xpress4k/8k/16k/lzx stores the files and they appear essentially as an archive file on older NTFS. NTFS has its own file compression method which is slower and less efficient, that is build into the OS right from boot. Xpress4k (default and for OS)/8k/16k (seemingly best for most systems)/lzx only become readable as intended after the Windows kernel is loaded. In other words, in theory at least it should be backwards compatible. That said though, ideally you only use the chkdsk from the same verson of Windows you are using.
anyone have a setup available to try ntfsfix with a linux live cd? run that and then let windows boot and it should do an NTFS consistency check on reboot. More of a curious thing than anything.