OK, so that's the 16299 Upgrade from Nov 2017 or so.
The release is 1709 (September) but the release date
is mid-October, and I think I installed that in
early November (no problems to report). My Insider Editions
also received it - the Insider and the Release version
cross paths on Upgrades like that, and then the Insider
diverges again, to higher Release numbers.
In your case, your 16299 must have been gated by something, that
prevented it from being installed in the first place. In some cases,
it's as simple a thing as a missing video driver. If you install
from a DVD, it will actually run with the Microsoft Basic Display
Adapter (a.k.a. VESA in-box driver). Whereas that cute little stub
downloader method, it wouldn't go unless it had a real video
driver to use.
Some devices (tablets) are "harder to install" than other
computing devices. and the install recipe takes more time
to figure out and deploy. The 32GB eMMC flash equipped
tablets, are a little to short on storage space for
Upgrades to be entered easily.
When the install starts, Windows is copied to Windows.old.
Some (but not all) Program Files content is also copied to
Windows.old. This would include programs that MS wants to
delete because they're "not compatible" with the new OS.
The user is supposed to run off and download new Win32
style versions of the removed EXEs and friends.
A lot of the install process does "migration". This seems to
include reinstalling applications, using .msi files archived
on C: .
At the current time, the installer is designed to do as much
staging of the install as possible, before the machine starts
with the multiple reboot cycles. This is to reduce the time
the machine is unavailable to the user.
There are two log files. One log file covers the "copy files"
phase of installation and that's all. The second log file is
stored in a different place, and it keeps the results of the
multitude or reboots. The time stamps on the files are
also different, with one file using local time, and the
other file using UTC or something. I think my files have
a five hour difference or something, which complicates
relating what happened later.
I've never heard of the OS installer doing CHKDSK before
starting the install. It would generally be a good idea to
do that. The reason it doesn't normally happen, is Microsoft
invented a "background CHKDSK" process, that keeps track
of system state. (They released some P.R. material claiming
to have made the file system "more robust", but I've never
seen actual technical details.) And it should be removing
simple latent faults. It there is a fault in the file
system, it's not supposed to fester, and it should
be getting corrected. That's why the scan dialog claims
"you don't need to scan this partition, but suit yourself"
kind of message. It's bragging on their part.
However, my recent experience suggests that system is
switched off. I could see no evidence anything was
working to repair obvious problems. Which means the
checking it does, must be limited to journal style
checks and balances. "Did file A get installed, go check."
And done with journal logic. When I had file system problems,
they weren't repaired on a reboot. If a simple check is
being done on the partition at boot time, it didn't
do anything.
If you have latent faults in a file system, then you
do 20GB of writes to the drive, who knows what could
happen.
You seem convinced the drive is healthy today, and all
I can recommend, is keep track of C: health with CHKDSK
from now on. You don't have to run it every day, but you
also don't want another OS upgrade coming in, without
checking things out. There is another OS upgrade coming
soon, which is why they were in a hurry to shovel that
one into your machine.
Paul