Windows 10: 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.

:)

 

No startup sound in Windows 10

I have an SSD drive. My computer takes 8 seconds to boot when I untick Fast Start Up. It takes 12 seconds WITH Fast Start Up.

NO - THE STARTUP SOUND DOES NOT WORK in either scenario.

 

Is there a way to keep Windows 10 from altering MBR on other drives in my sytem?

If the repair you got at restart was a Disk Check, this is common for WIndows 10 in multi-boots. Only if it becomes chronic do you need to take steps to troubleshoot turning off Fast Start but not necessarily the popular Hibernate feature.
Even then it is symptomatic of other problems which need to be repaired and not caused merely by Fast Start.


I think in that you may be mistaken. The problem with Fast Startup has been known to the Linux community since Windows 8 came out. Having experienced it first hand, with catastrophic data loss on a perfectly good drive, I wouldn't suggest to anyone that
it was worth taking the risk to leave Fast Startup activated. Any drive can become defective but as you said, Disk Checks are
common in Windows 10 multi-boots. That's a fairly clear indication that the problem centers on the presence of Windows 10 in the boot mix. Further evidence implicating Fast Startup is that warm booting between OS's, which does not invoke Fast Startup
functionality, also does not generate Disk Check errors. If other problems requiring repair
were the actual cause of the Disk Check errors then those errors would continue to appear regardless of whether or not the computer is booted into a different OS. To put it another way, if
other problems caused the Disk Check errors they wouldn't suddenly stop happening altogether after Fast Startup was disabled.

 

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 *Smile
Plus to make my life really easier I use one of these to keep os's completely separate *Smile
http://www.amazon.com/gp/product/B00...?ie=UTF8&psc=1

 

If MS is aware of this why do not they fix iit?

 

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.

 

Fast Startup is overrated IMHO. It causes more issues than it fixes, IMHO. Not needed if your running an SSD anyway, again IMHO. It's one of the first things I disable/turn off.

 

*Ditto

 

It caused me a few headaches until I disabled it.

 

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.

 

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.

 

Details please. My statements came from experience as an amateur programmer.

 

Well-known problem starting at Windows 8. "Fast Startup" is modified hibernation (without user session) so it leaves disk volumes/filesystems in Dirty Shutdown state (does not dismount them) after "shutdown". Much worse, FCU re-enables this "feature" without notifying users.

 

You access the USN change journal using functionality analogous to fsutil's USN journal query functions.
See here for a brief overview of the architecture of Change Journal records on NTFS volumes. More details on how to work with Change Journal records are here.

Do you have experience with Windows systems-level programming if I may ask?