Beware of Fast Startup in multi-boot scenarios!

This isn't really new advice, and it's in fact quite well known, but this should be a sticky in this forum:

Do not, ever, have WinX's Fast Startup option enabled if through whatever means you anticipate booting your system into an OS other than the one you just hibernated via a "shutdown" with Fast Startup enabled. This applies to multi-boot configurations with other operating systems as well as booting into various kinds of rescue environments and such via external media (USB stick, external HD, etc.). If for whatever reason you feel you absolutely need to boot into another OS environment of any kind while Windows 10 has been "shut down" with Fast Startup enabled, you must make sure the partitions that were in use when Windows 10 was running are not written to, ever.

The reason for this mandate is that Microsoft, as usual, has completely disregarded scenarios like the above. In this case it means that when you perform a "shutdown" with Fast Startup enabled, the system will save its state in the hibernation file, including all of its internal file system tables. Moreover, when you "boot" such a system, Windows will not check if any of the mounted file systems have been modified between the previous "shutdown" and the following startup. Thus it will not remount any of its file systems and instead will blithely continue under the assumption that nothing has changed.
As a consequence, if any of the mounted file systems have been modified while Windows 10 was suspended, the OS will be unaware of these changes, which means your file system will be corrupted as soon as Windows 10 performs any write operations on such a system. Let me repeat this is a "will be", not a "may be": File system damage is guaranteed in these kinds of scenarios. Finally, in many cases the resulting damage cannot be repaired, and your only recourse is either restore from a complete system backup if you have one, or re-install from scratch.

You have been warned. Hope this helps someone.

Hi,
I believe it gets a little more interesting in 1709 current fall creators update
MS did I noticed if landing back on the sign in page added a popup message saying restarting now you'll loose any work you were working on
Sort of an annoying message to me seeing I had closed everything before choosing to restart
Then chose to restart again because I missed the bios flash screen

So but yes it is well know fast start just makes recovery... more difficult especially if 10 is acting up boot wise it will just loop.....
cmd as admin and powercfg -h off is about the only way to go I've found :)
Plus to make my life really easier I use one of these to keep os's completely separate :)
http://www.amazon.com/gp/product/B00...?ie=UTF8&psc=1

They are aware of it; this behavior is by design. Microsoft doesn't care, that's all. You're not supposed to run more than one OS on one piece of hardware. That's how Microsoft feels, anyway. Otherwise it would have been trivial for them to check the volumes for changes, and remount them if necessary. Like I said, they don't give a rat's behind.

It caused me a few headaches until I disabled it.

Pirx said:

This isn't really new advice, and it's in fact quite well known, but this should be a sticky in this forum:

Do not, ever, have WinX's Fast Startup option enabled if through whatever means you anticipate booting your system into an OS other than the one you just hibernated via a "shutdown" with Fast Startup enabled. This applies to multi-boot configurations with other operating systems as well as booting into various kinds of rescue environments and such via external media (USB stick, external HD, etc.). If for whatever reason you feel you absolutely need to boot into another OS environment of any kind while Windows 10 has been "shut down" with Fast Startup enabled, you must make sure the partitions that were in use when Windows 10 was running are not written to, ever.

The reason for this mandate is that Microsoft, as usual, has completely disregarded scenarios like the above. In this case it means that when you perform a "shutdown" with Fast Startup enabled, the system will save its state in the hibernation file, including all of its internal file system tables. Moreover, when you "boot" such a system, Windows will not check if any of the mounted file systems have been modified between the previous "shutdown" and the following startup. Thus it will not remount any of its file systems and instead will blithely continue under the assumption that nothing has changed.
As a consequence, if any of the mounted file systems have been modified while Windows 10 was suspended, the OS will be unaware of these changes, which means your file system will be corrupted as soon as Windows 10 performs any write operations on such a system. Let me repeat this is a "will be", not a "may be": File system damage is guaranteed in these kinds of scenarios. Finally, in many cases the resulting damage cannot be repaired, and your only recourse is either restore from a complete system backup if you have one, or re-install from scratch.

You have been warned. Hope this helps someone.

Detecting changes to a file system while the OS is not running is not a simple thing. I doubt it could be done reliably. If possible at all it would take considerable time which would compromise the benefits of Fast Startup and Shutdown. Considering that most people don't dual boot it is reasonable to assume that no changes have occurred.

Maybe Microsoft should have a warning about this. But few people would read it and many would ignore it.

LMiller7 said:

Detecting changes to a file system while the OS is not running is not a simple thing.

Huh? You would of course check the volumes during system initialization; all you need to do is check if the volume has seen any writes after the time of "shutdown". On an NTFS volume that's trivial to do and will only take microseconds, literally. All they need to do is do it...

I've wondered about this often.
So, I boot to Insider Preview on a spinner by default with Fast Startup turned off,
I Shift/Restart to the SSD with FCU with Fast Startup enabled;
don't know if it makes a difference but I see no side effects.